IS-IS Application-Specific Link Attributes
obsoletes
- rfc-8919 — IS-IS Application-Specific Link Attributes
Extracted elements (29)
Existing link attribute advertisements do not support application-specific values for a given attribute on a link, nor do they indicate which applications are using a given advertised value. When RSVP-TE and SR Policy coexist, a link advertised for SR Policy could be incorrectly interpreted by an RSVP-TE head-end as RSVP-TE-enabled, causing path setup failures.
SABM and UDABM lengths are each arbitrarily limited to 8 octets to ensure sufficient space remains within the sub-TLV for link attribute sub-sub-TLVs without exceeding the maximum sub-TLV length.
The Application-Specific SRLG TLV (Type 238) uses sub-TLVs for link identifiers rather than fixed fields, allowing it to support IPv4, IPv6, and unnumbered links in a single TLV unlike legacy TLVs 138 and 139, which each support only a subset of link identifier types.
Whether presence of ASLA advertisements implies application enablement depends on the application: RSVP-TE presence implies enablement; SR Policy and LFA advertisements do not imply enablement since SR Policy is implicitly enabled on all SR-topology links and LFA enablement is controlled by local configuration.
Zero-length Application Identifier Bit Masks serve as a wildcard, associating link attributes with any application. This allows shared attribute values to be advertised once rather than repeated for every application, minimizing duplicate link/attribute pairs.
Migration from legacy to ASLA advertisements requires three steps: (1) advertise both ASLA and legacy advertisements simultaneously, (2) enable use of ASLA advertisements on all routers, then (3) remove legacy advertisements. The L-flag provides no value in this migration sequence.
So long as any legacy router in the network has any standard application enabled, all routers MUST continue to advertise link attributes for those applications using only legacy advertisements, and ASLA advertisements for those applications MUST NOT be sent.
When multiple applications share a link and all attributes are common with RSVP-TE, interoperability with legacy routers is achieved by retaining legacy advertisements and sending ASLA advertisements with the L-flag set and no link attribute values, avoiding duplication.
When SR Policy or LFA attributes differ from RSVP-TE on a given link, attributes for those applications MUST be advertised using ASLA advertisements with the L-flag clear, even if some attributes are shared with RSVP-TE (requiring duplicate advertisement of shared attributes).
For a given application, the L-flag setting MUST be the same in all ASLA sub-TLVs for a given link. If this constraint is violated, the L-flag MUST be treated as set for that application.
If the SABM Length or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire ASLA sub-TLV or ASLA SRLG TLV MUST be ignored.
In the Application-Specific SRLG TLV, at least one set of link identifiers (IPv4, IPv6, or Link Local/Remote) MUST be present. Multiple occurrences of the same identifier type MUST NOT be present. TLVs that do not meet these requirements MUST be ignored.
Link attribute advertisements with zero-length Application Identifier Bit Masks MUST be used by applications when no advertisement with a non-zero-length bit mask and a matching application bit exists for a given link. Otherwise, such advertisements MUST NOT be used.
Maximum link bandwidth is application-independent; if different values for this attribute are advertised for a given link, all values MUST be ignored. Multiple advertisements for this attribute MUST NOT advertise different values for the same link.
Maximum reservable link bandwidth and unreserved bandwidth are RSVP-TE-specific; when advertised via ASLA, bits other than the R-bit MUST NOT be set in the Application Identifier Bit Mask. Advertisements with other bits set MUST be ignored.
New applications defined to use ASLA advertisements MUST NOT make use of legacy advertisements. This eliminates the need to support multiple advertisement modes for newly defined applications.
Undefined bits in SABM and UDABM MUST be transmitted as 0 and MUST be ignored on receipt. Bits not transmitted MUST be treated as 0 on receipt. Bits not supported by an implementation MUST be ignored on receipt.
When multiple ASLA sub-TLVs for the same link advertise conflicting values for the same application/attribute pair, the first advertisement received in the lowest-numbered LSP MUST be used and subsequent conflicting advertisements MUST be ignored.
When the L-flag is set in the Application-Specific SRLG TLV, SRLG values MUST NOT be included; any SRLG values advertised MUST be ignored, and the corresponding legacy TLV's SRLG values MUST be used by the specified applications.
The Application Identifier Bit Mask consists of a Standard Application Bit Mask (SABM) and a User-Defined Application Bit Mask (UDABM), each preceded by a one-octet length+flag field. The SABM defines R-bit (RSVP-TE), S-bit (SR Policy), and F-bit (LFA); the UDABM is unmanaged by IANA. Both are used in the ASLA sub-TLV and ASLA SRLG TLV.
The Application-Specific Link Attributes (ASLA) sub-TLV (Type 16) is defined for TLVs Advertising Neighbor Information. Its value contains an Application Identifier Bit Mask followed by link attribute sub-sub-TLVs whose formats match those of legacy sub-TLVs defined in RFC 5305, RFC 7308, and RFC 8570.
The Application-Specific SRLG TLV (Type 238) unifies SRLG advertisement for IPv4, IPv6, and unnumbered links in a single TLV. Its value contains Neighbor System-ID+pseudonode (7 octets), Application Identifier Bit Mask, length of sub-TLVs (1 octet), Link Identifier sub-TLVs, and zero or more 4-octet SRLG values.
IANA created the 'IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes' registry under 'IS-IS TLV Codepoints' with Expert Review policy. Initial entries (Types 3, 9–11, 14, 18, 33–39) mirror legacy sub-TLV assignments from RFC 5305, RFC 7308, and RFC 8570.
IANA created the 'IS-IS Sub-TLVs for Application-Specific SRLG TLV' registry under 'IS-IS TLV Codepoints' with Expert Review policy. Initial entries: Type 4 (Link Local/Remote Identifiers), 6 (IPv4 interface address), 8 (IPv4 neighbor address), 12 (IPv6 Interface Address), 13 (IPv6 Neighbor Address).
IANA created the 'Link Attribute Application Identifiers' registry within the 'IGP Parameters' group with Expert Review policy. Initial assignments: bit 0 = RSVP-TE (R-bit), bit 1 = Segment Routing Policy (S-bit), bit 2 = Loop-Free Alternate (F-bit); bits 3–63 unassigned.
IANA registered Application-Specific SRLG TLV Type 238 in the 'IS-IS Top-Level TLV Codepoints' registry; applicable in LSPs only (not IIH, SNP, or Purge).
IANA registered ASLA sub-TLV Type 16 in the 'IS-IS Sub-TLVs for TLVs Advertising Neighbor Information' registry, applicable to TLVs 22, 23, 25, 141, 222, and 223.
Tampering with ASLA advertisements can affect all applications using them, including TE as discussed in RFC 8570. Because ASLA advertisements scope impact to specific applications, the blast radius of tampering is limited compared to unscoped legacy advertisements. Deployments with potential attackers SHOULD use the stronger authentication mechanisms defined in RFC 5304 and RFC 5310.
The Application Identifier Bit Mask encoding is: SABM Length+Flag (1 octet, bit 7 = L-flag, bits 0-6 = SABM length in octets 0-8), UDABM Length+Flag (1 octet, bit 7 = reserved, bits 0-6 = UDABM length 0-8), SABM (variable, omitted if length 0), UDABM (variable, omitted if length 0). SABM/UDABM are each limited to 8 octets.