Advertising Node Administrative Tags in IS-IS
Extracted elements (19)
Node administrative tags are intentionally opaque to IS-IS and have no well-known values requiring IANA registration. This avoids overloading the extension with protocol-specific semantics; new IS-IS extensions needing well-known values should define their own signaling.
The Node-Admin-Tag sub-TLV is placed inside the Router CAPABILITY TLV (TLV 242) rather than a new top-level TLV, because route and path selection functionality applies to both TE and non-TE applications and Router CAPABILITY TLV already provides the necessary flooding scope options.
The sub-TLV format deliberately omits a topology identifier, making it impossible to indicate topology-specific context. This simplifies the format but means per-topology tagging is not supported in multi-topology deployments.
If a receiving node does not understand a tag value, it MUST ignore the specific tag and flood the Router CAPABILITY TLV without any change, as defined in RFC 4971. This preserves backward compatibility.
Multiple Node-Admin-Tag sub-TLVs MAY appear in a single Router CAPABILITY TLV, or they MAY be distributed across different instances of Router CAPABILITY TLVs; receivers must aggregate all instances to form the complete tag set.
Extended authentication mechanisms described in RFC 5304 or RFC 5310 SHOULD be used in deployments where attackers have access to the physical networks, because nodes included in the IS-IS domain are vulnerable.
In deployments using multi-topology routing (RFC 5120), advertising a separate set of node administrative tags for each topology SHOULD NOT be supported, since the sub-TLV format does not include a topology identifier.
Node administrative tags MUST NOT be associated with something whose state can oscillate frequently, such as the reachability of a specific destination, since tags are expected to be associated with stable attributes.
On detecting a change in Node-Admin-Tag sub-TLV contents, removal, or addition in any Router CAPABILITY TLV instance, implementations MUST take appropriate measures to update their state according to the changed set of node administrative tags.
Tag values SHOULD NOT be propagated outside the administrative domain to which they apply, since their meaning is specific to the local operator's domain.
The list of node administrative tags carried in a Node-Admin-Tag sub-TLV MUST be considered as an unordered list. Policies MUST NOT be reliant upon the order of the tags; all policies should be considered commutative operations.
The node administrative tags associated with a node SHOULD be a superset of all Node-Admin-Tag sub-TLVs from all instances of Router CAPABILITY TLVs received in the LSP(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.
A node administrative tag is a 32-bit unsigned integer value used to identify a group of nodes in an IS-IS domain. Routers advertise the set of groups they belong to at the appropriate IS-IS level.
The Node-Admin-Tag sub-TLV is carried within an IS-IS Router CAPABILITY TLV (TLV type 242) in Link State PDUs. It can have either level-wide or domain-wide flooding scope, as determined by local operator policy.
IANA registered value 21 (Node-Admin-Tag) in the 'Sub-TLVs for TLV 242' registry for the IS-IS Router CAPABILITY TLV sub-TLV space.
Node administrative tags can be used to indicate geographical location or other sensitive information, and this information can be leaked to an IGP snooper, similar to link administrative tags. Advertisement of tag values across administrative domains risks misinterpretation and undesirable side effects.
The Node-Admin-Tag sub-TLV has a 1-octet Type field (value 21), a 1-octet Length field indicating the length in octets (a multiple of 4), and a Value field containing one or more 32-bit administrative tags. Multiple tags are encoded as sequential 4-octet fields.