Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
obsoleted by
- rfc-7981 — IS-IS Extensions for Advertising Router Information
Extracted elements (16)
Receiving systems can minimize disruption from capability TLV updates by employing a holddown time prior to processing, allowing receipt of multiple LSP fragments associated with the same update before beginning processing.
The CAPABILITY TLV is intentionally generic and not limited to MPLS Traffic Engineering; it provides a reusable mechanism for routers to announce capabilities within an IS-IS level or the entire routing domain, with sub-TLV definitions left to application-specific documents.
The procedure to choose between two copies of a capabilities TLV from the same system with different attribute settings is explicitly left undefined, acknowledging this is an edge case without a specified resolution.
For Router CAPABILITY TLVs with domain-wide scope originated by L1 routers to be flooded across the entire domain, at least one L1/L2 router in every area of the domain MUST support the Router CAPABILITY TLV.
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level even though it may contain unsupported sub-TLVs, preserving forward compatibility.
Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs MUST silently ignore unsupported sub-TLVs and continue processing supported ones.
A router that generates a CAPABILITY TLV MUST have a Router ID that is a 32-bit number, unique within the IS-IS area. If any capability TLVs with domain flooding scope are generated, the ID MUST also be unique within the IS-IS routing domain.
A system MUST NOT use a Capability TLV present in an LSP of a system that is not currently reachable via Level-x paths, where x is the level in which the sending system advertised the TLV. This applies regardless of whether the sending system is the originator.
An implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisement it replaces. Where not possible, the two affected LSP fragments should be flooded as an atomic action.
If the S bit is set, the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set, the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during TLV leaking.
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each carrying sub-TLVs with the same flooding scope.
When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set; otherwise it MUST be clear. TLVs with the D bit set MUST NOT be leaked from level-1 to level-2, preventing looping.
The IS-IS Router CAPABILITY TLV (type 242) consists of 1 octet type, 1 octet length (5 to 255), a 4-octet Router ID indicating the TLV source, a 1-octet flags field, and 0-250 octets of optional sub-TLVs.
IANA assigned TLV code-point 242 for the IS-IS Router CAPABILITY TLV defined in this document.
LSPs may now contain additional router capability information, making this data available to an attacker who can snoop or modify LSPs. Specifications based on this mechanism must describe security considerations around disclosure and modification of their information. An integrity mechanism such as RFC 3567 or IS-IS-HMAC SHOULD be applied if there is high risk from modification of capability information.
The Flags field is 1 octet with two defined bits: S bit (0x01) controls domain-wide flooding scope, and D bit (0x02) is set when the TLV is leaked from level-2 to level-1. Remaining 6 bits are reserved.