One document matched: draft-ietf-isis-node-admin-tag-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-isis-node-admin-tag-10" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev='Node Admin Tags in IS-IS'>
Advertising Node Administrative Tags in IS-IS</title>
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
<organization>Individual Contributor</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>pushpasis.ietf@gmail.com</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Individual Contributor</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>hannes@gredler.at</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>stephane.litkowski@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>bruno.decraene@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<date day="3" month="May" year="2016" />
<area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup>
<keyword>IGP</keyword>
<keyword>IS-IS</keyword>
<keyword>Admin-Tag</keyword>
<keyword>Traffic Engineering</keyword>
<abstract>
<t> This document describes an extension to the IS-IS routing protocol
to add an optional capability that allows tagging and grouping
of the nodes in an IS-IS domain. This allows simple management and easy
control over route and path selection, based on local configured policies.
This document describes an extension to the IS-IS protocol to advertise
node administrative tags. The node administrative tags can be used
to express and apply locally defined network policies which is a very useful
operational capability. Node administrative tags may be used either by
IS-IS itself or by other applications consuming information propagated via
IS-IS.</t>
<t>This document describes the protocol extensions to disseminate
node administrative tags in IS-IS protocols.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t> It is useful to assign a node administrative tag to a router in the IS-IS
domain and use it as an attribute associated with the node. The node
administrative tag can be used in variety of applications, for example:
<list style="format (%c) ">
<t>Traffic-engineering applications to provide different path-selection criteria. </t>
<t>Prefer or prune certain paths in Loop Free Alternate (LFA) backup selection via
local policies as defined in <xref target="I-D.ietf-rtgwg-lfa-manageability"/>.</t>
</list></t>
<t> This document provides mechanisms to advertise node administrative
tags in IS-IS for route and path selection. Route and path selection functionality
applies to both Traffic Engineering (TE) and non-TE applications. Hence the new TLV
for carrying node administrative tags is included in the Router CAPABILITY TLV
<xref target="RFC4971"/>.</t>
</section>
<section title='Node Administrative Tags'>
<t> An administrative tag is a 32-bit unsigned integer value that can be used to identify
a group of nodes in the IS-IS domain. An IS-IS router SHOULD advertise the set of
groups it is part of in the specific IS-IS level.</t>
<t>As an example, all edge network devices in a given network may be configured
with a certain tag value, whereas all core network devices may be configured with
another different tag value.</t>
</section>
<section title='Node Administrative Tag Sub-TLV'>
<t> The new sub-TLV defined is carried within a IS-IS Router CAPABILITY TLV (IS-IS TLV type 242)
<xref target="RFC4971"/> in the Link State PDUs originated by the device.
Router Capablity TLVs <xref target="RFC4971"/> can have 'level-wide'
or 'domain-wide' flooding scope. The choice of flooding scope in which a specific
node administrative tag shall be flooded, is purely a matter of local policy, and is
defined by the needs of the operator's usage. Operator MAY choose to advertise a
set of node administrative tags across levels and another diiferent set of node
administrative tags within the specific level. Alternatively, the operator
may use the same node administrative tags both within the 'domain-wide' flooding
scope as well as within one or more 'level-wide' flooding scope.</t>
<t> The format of Node Administrative Tag sub-TLV (see <xref target='tlvformat'/>) does not
include a topology identifier. Therefore it is not possible to indicate a topology specific
context when advertising node administrative tags. Hence, in deployments using multi-topology routing
<xref target="RFC5120"/>, advertising a separate set of node administrative tags for
each topology SHOULD NOT be supported.</t>
<section title='TLV format' anchor='tlvformat'>
<t><xref target="RFC4971"/>, defines Router CAPABILITY TLV which may be
used to advertise properties of the originating router. The payload of the Router
CAPABILITY TLV consists of one or more nested Type/Length/Value (TLV) triplets. </t>
<t>The new Node Administrative Tag sub-TLV, like other IS-IS sub-TLVs, is
formatted as Type/Length/Value (TLV) triplets. <xref target="isisadmintagtlv"/> below shows
the format of the new sub-TLV.</t>
<figure anchor="isisadmintagtlv" title="IS-IS Node Administrative Tag sub-TLV">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : TBA, Suggested value 21
** RFC Editor** Please replace above suggested value with the IANA-assigned value.
Length: An 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 4-octets
dependent on the number of tags advertised.
Value: A set of multiple 4-octets defining the
administrative tags.
</artwork>
</figure>
</section>
</section>
<section title='Elements of Procedure'>
<section title='Interpretation of Node Administrative Tags'>
<t> The meaning of Node administrative tags is generally opaque to IS-IS.
A router advertising one or more node administrative tag(s) may be
configured to do so without knowing (or even explicitly supporting)
functionality implied by the tag. This section describes general rules/
regulations and guidelines for using and interpreting a node administrative
tag which will facilitate interoperable implementations by vendors. </t>
<t> Interpretation of tag values is specific to the administrative domain
of a particular network operator. Hence tag values SHOULD NOT be propagated
outside the administrative domain to which they apply. The meaning of a node
administrative tag is defined by the network local policy and is controlled
via configuration. If a receiving node does not understand the tag value,
it ignores the specific tag and floods the Router CAPABILITY TLV without
any change, as defined in <xref target="RFC4971"/>.</t>
<t>The semantics of the tag order has no meaning. There is no implied
meaning to the ordering of the tags that indicates a certain operation
or set of operations that need to be performed based on the ordering.</t>
<t> Each tag SHOULD be treated as an independent identifier that MAY be
used in policy to perform a policy action. Each tag carried by the
Node Administrative Tag sub-TLVs should be used to indicate a characteristic
of a node that is independent of the characteristics indicated by other
administrative tags within the same or another instance of a Node
Administrative Tag sub-TLV. The list of Node administrative tags carried
in a Node Administrative Tag sub-TLV MUST be considered as an unordered list.
Whilst policies may be implemented based on the presence of multiple tags
(e.g., if tag A AND tag B are present) , they MUST NOT be reliant upon
the order of the tags (i.e., all policies should be considered commutative
operations, such that tag A preceding or following tag B does not change
their outcome) .</t>
</section>
<section title='Use of Node Administrative Tags'>
<t> The node administrative tags are not meant to be extended by future
IS-IS standards. New IS-IS extensions are not expected to require use of
node administrative tags or define well-known tag values. Node
administrative tags are for generic use and do not require IANA registry.
Future IS-IS extensions requiring well-known values MAY define their own
data signalling tailored to the needs of the feature or MAY use the capability
TLV as defined in <xref target="RFC4971"/>.</t>
<t> Being part of the Router CAPABILITY TLV, the node administrative tag
sub-TLV MUST be reasonably small and stable. In particular, but not
limited to, implementations supporting the node administrative tags
MUST NOT associate advertised tags to changes in the network topology (both
within and outside the IS-IS domain) or the reachability of routes.</t>
</section>
<section title='Processing Node Administrative Tag Changes'>
<t> Multiple Node Administrative Tag sub-TLVs MAY appear in a Router
CAPABILITY TLV or Node Administrative Tag sub-TLVs MAY be contained
in different instances of Router CAPABILITY TLVs. The Node administrative tags
associated with a node that originates tags for the purpose of any computation or
processing at a receiving node SHOULD be a superset of node administrative tags
from all the TLVs in all the instances of Router CAPABILITY TLVs received in the
Link-State PDU(s) advertised by the corresponding IS-IS router. When a Router
CAPABILITY TLV is received that changes the set of node administrative tags
applicable to any originating node, a receiving node MUST repeat any computation or
processing that makes use of node administrative tags.</t>
<t> When there is a change or removal of an administrative affiliation of a node,
the node MUST re-originate the Router CAPABILITY TLV(s) with the latest set of
node administrative tags. On a receiving router, on detecting a change in
contents (or removal) of existing Node Administrative Tag sub-TLV(s) or
addition of new Node Administrative Tag sub-TLV(s) in any instance of Router
CAPABILITY TLV(s) , implementations MUST take appropriate measures to update their
state according to the changed set of node administrative tags. The exact actions
needed depend on features working with node administrative tags and is outside
of scope of this specification.</t>
</section>
</section>
<section title='Applications'>
<t> <xref target="RFC7777"/> lists several non-normative examples of how implementations
might use Node administrative tags. These examples are given only to demonstrate generic
usefulness of the router tagging mechanism. An implementation supporting this specification
is not required to implement any of the use cases. Following is a brief list of non-normative
use cases listed in <xref target="RFC7777"/>. Please refer to
<eref target="http://tools.ietf.org/html/rfc7777#section-3">RFC7777 section-3</eref>
for more details.
<list style="numbers">
<t>Auto-discovery of Services</t>
<t>Policy-based Fast-Re-Route (FRR)
<list style="format (%c) " hangIndent="4">
<t>Administrative limitation of LFA scope</t>
<t>Optimizing LFA calculations</t>
</list></t>
<t>Controlling Remote LFA tunnel termination</t>
<t>Mobile back-haul network service deployment</t>
<t>Policy-based Explicit Routing</t>
</list></t>
</section>
<section title='Security Considerations' anchor='sec-con'>
<t> Node administrative tags, like link administrative tags <xref target="RFC5305"/>,
can be used by operators to indicate geographical location or other sensitive information.
The information carried in node administrative tags, like link administrative tags, can be
leaked to an IGP snooper. Hence this document does not introduce any new security issues.</t>
<t> Advertisement of tag values for one administrative domain into another involves the risk
of misinterpretation of the tag values (if the two domains have assigned different meanings to
the same values) , and may have undesirable and unanticipated side effects.</t>
<t>Security concerns for IS-IS are already addressed in <xref target="ISO10589"/>,
<xref target="RFC5304"/>, and <xref target="RFC5310"/> and are applicable to the mechanisms
described in this document. Extended authentication mechanisms described in
<xref target="RFC5304"/> or <xref target="RFC5310"/> SHOULD be used in deployments where
attackers have access to the physical networks and nodes included in the IS-IS domain are
vulnerable.</t>
</section>
<section title='Operational Considerations' anchor='op-con'>
<t>Operators can assign meaning to the node administrative tags which is local to the
operator's administrative domain. The operational use of node administrative tags is
analogical to the IS-IS prefix tags <xref target="RFC5130"/> and BGP communities <xref target="RFC1997"/>.
Operational discipline and procedures followed in configuring and using BGP communities and
IS-IS Prefix tags is also applicable to the usage of node administrative tags.</t>
<t> Defining language for local policies is outside the scope of this document. As in the case
of other policy applications, the pruning policies can cause the path to be completely
removed from the forwarding plane, and hence have the potential for more severe operational
impact (e.g., node unreachability due to path removal) by comparison to preference policies
that only affect path selection.</t>
</section>
<section title='Manageability Considerations' anchor='manage-con'>
<t>Node administrative tags are configured and managed using routing policy enhancements.
The YANG <xref target="RFC6020"/> is a data modeling language used to specify configuration
data models. The IS-IS YANG data model is described in
<xref target="I-D.ietf-isis-yang-isis-cfg"/> and the routing policy configuration model
is described in <xref target="I-D.ietf-rtgwg-policy-model"/>. These two documents need
to be enhanced to include the node administrative tag related configurations.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification updates one IS-IS registry: IS-IS Router Capabality (TLV-242) Sub-TLVs Registry
<vspace blankLines="1"/>
i) Node-Admin-Tag Sub-TLV, Type: TBD, suggested value 21
<vspace blankLines="1"/></t>
<t>** RFC Editor** Please replace above suggested value with the IANA-assigned value.</t>
</section>
<section title='Contributors'>
<t>Many many thanks to Ebben Aries and Rafael Rodriguez for their help with reviewing and improving
the text of this document. Many thanks to Harish Raguveer for his contributions to initial versions
of the draft as well. Finally, many thanks to Li Zhenbin for providing some valuable use cases.</t>
</section>
<section title='Acknowledgments'>
<t>Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris Bowers for providing useful
inputs.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor="ISO10589">
<front>
<title>Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473) , ISO/IEC 10589:2002, Second Edition.</title>
<author fullname="ISO "International Organization for Standardization""/>
<date month="Nov" year="2002"/>
</front>
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4971"?>
<?rfc include="reference.RFC.5304"?>
<?rfc include="reference.RFC.5310"?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.5305"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.RFC.5130"?>
<?rfc include="reference.RFC.5286"?>
<?rfc include="reference.RFC.6020"?>
<?rfc include="reference.RFC.7777"?>
<?rfc include="reference.I-D.ietf-rtgwg-lfa-manageability"?>
<?rfc include="reference.I-D.ietf-rtgwg-policy-model"?>
<?rfc include="reference.I-D.ietf-isis-yang-isis-cfg"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:27 |