Advertising Node Administrative Tags in IS-ISIndividual Contributorpushpasis.ietf@gmail.comRtBrick Inc.hannes@rtbrick.comJuniper Networks, Inc.Electra, Exora Business ParkBangaloreKA560103Indiashraddha@juniper.netOrangestephane.litkowski@orange.comOrangebruno.decraene@orange.comIGPIS-ISAdmin-TagTraffic EngineeringThis document describes an extension to the IS-IS routing protocol
to advertise node administrative tags. This optional capability allows
tagging and grouping of the nodes in an IS-IS domain. The node
administrative tags can be used to express and apply locally defined
network policies, thereby providing a very useful operational
capability. Node administrative tags may be used by either IS-IS itself
or other applications consuming information propagated via IS-IS.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:
Traffic-engineering applications to provide different
path&nbhy;selection criteria.Preference for, or pruning of, certain paths in Loop-Free Alternate
(LFA) backup selection via local policies as
defined in .This document provides mechanisms to advertise node administrative
tags in IS-IS for various applications, including (but not limited to)
route and path selection. Route and path selection functionality applies
to both Traffic Engineering (TE) and non-TE applications. Hence, the
new sub-TLV for carrying node administrative tags is included in the
Router CAPABILITY TLV .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 RFC 2119.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 in the specific IS-IS level the set of groups of which
it is a part.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.The new sub-TLV defined in this document is carried within an IS-IS
Router CAPABILITY TLV (IS-IS TLV type 242) in
the Link State PDUs originated by the device. Router CAPABILITY TLVs
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 operator's usage needs. An operator
MAY choose to advertise a set of node administrative tags across levels
and another different set of node administrative tags within the specific
level. Alternatively, the operator may use the same node administrative
tags within both the "domain-wide" flooding scope and one or more
"level&nbhy;wide" flooding scopes.The format of the Node Administrative Tag (Node-Admin-Tag) sub-TLV (see ) 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&nbhy;topology routing , advertising a
separate set of node administrative tags for each topology
SHOULD NOT be supported. defines the 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.The new Node-Admin-Tag sub-TLV, like other IS-IS sub-TLVs, is
formatted as TLV triplets. below shows
the format of the new sub-TLV.The meaning of node administrative tags is generally opaque to IS-IS.
A router advertising one or more node administrative tags may be
configured to do so without knowing (or even explicitly supporting) the
functionality implied by the tag. This section describes general
rules, regulations, and guidelines for using and interpreting a node
administrative tag; these rules, regulations, and guidelines will
facilitate interoperable implementations between vendors.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 .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.Each tag SHOULD be treated as an independent identifier that may be
used in a policy to perform a policy action. Each tag carried by the
Node-Admin-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 instance or another instance of a
Node-Admin-Tag sub-TLV. The list of node administrative tags carried in
a Node-Admin-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).The node administrative tags are not meant to be extended by future
IS-IS standards. New IS-IS extensions are not expected to require the
use of node administrative tags or define well-known tag values. Node
administrative tags are for generic use and do not require IANA
registration. Future IS-IS extensions requiring well-known values MAY
define their own data signaling tailored to the needs of the feature or
MAY use the Router CAPABILITY TLV as defined in
.Node administrative tags are expected to be associated with a stable
attribute. In particular, node administrative tags MUST NOT be associated
with something whose state can oscillate frequently, e.g., the reachability
of a specific destination.While no specific limit on the number of node administrative
tags that may be advertised has been defined, it is expected that only a
modest number of tags will be required in any deployment.Multiple Node-Admin-Tag sub-TLVs MAY appear in a Router CAPABILITY TLV,
or Node-Admin-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.When there is a change to, 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-Admin-Tag sub-TLV(s) or the addition of new Node&nbhy;Admin-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 will vary, depending on
what features are associated with node administrative tags; this topic is
outside the scope of this specification. lists several non-normative examples of how
implementations might use node administrative tags. These examples are
given only to demonstrate the generic usefulness of the router tagging
mechanism. An implementation supporting this specification is not required
to implement any of the use cases. The following is a brief list of
non-normative use cases listed in . Please refer
to Section 3 of for more details.
Auto-discovery of servicesPolicy-based Fast Reroute (FRR)
Administrative limitation of LFA scopeOptimizing LFA calculationsControlling remote LFA tunnel terminationMobile backhaul network service deploymentPolicy-based explicit routingThis document does not introduce any new security issues.
Node administrative tags, like link administrative tags
(a.k.a. administrative groups) , 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.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.Security concerns for IS-IS are already addressed in , , and and are applicable to the mechanisms described in this
document. Extended authentication mechanisms described in or SHOULD be used in
deployments where attackers have access to the physical networks,
because nodes included in the IS-IS domain are vulnerable.Operators can assign a meaning to the node administrative tags that is
local to the operator's administrative domain. The operational use of node
administrative tags is analogical to the IS-IS prefix tags and BGP communities .
Operational discipline and procedures followed in configuring and
using BGP communities and IS-IS prefix tags are also applicable to the
usage of node administrative tags.Defining a language for local policies is outside the scope of this
document. As is the case with other policy applications, the pruning
policies can cause the path to be completely removed from the forwarding
plane and hence have the potential for a more severe impact on
operations (e.g., node unreachability due to path removal) as compared to
preference policies that only affect path selection.Node administrative tags are configured and managed using routing
policy enhancements. YANG is a data modeling
language used to specify configuration data models. The IS-IS YANG data
model is described in , and the routing
policy configuration model is described in . At the time of writing this document, some
work to enhance these two other documents so that they include
configurations related to node administrative tags is either already in
progress or shall be taken up soon.This specification updates one IS-IS registry: the
"Sub-TLVs for TLV 242" registry. The following
value has been registered.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)International Organization for StandardizationOperational Management of Loop-Free AlternatesRouting Policy Configuration Model for Service Provider NetworksYANG Data Model for IS-IS protocolMany thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri, and Chris Bowers for providing useful inputs.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 draft versions of the
document as well. Finally, many thanks to Zhenbin Li for providing some
valuable use cases.