Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)
Extracted elements (23)
IS-IS encoding of application-specific link information differs from OSPF and requires additional procedures: the presence of the L-flag and the need to collate information from two IS-IS encoding types (ASLA sub-TLV and Application-Specific SRLG TLV) into a single BGP-LS ASLA TLV necessitate special handling rules.
Maximum Link Bandwidth, Maximum Reservable Link Bandwidth, and Unreserved Bandwidth are forced to top-level TLVs even when received in IS-IS ASLA sub-TLVs because these attributes are either non-application-specific or RSVP-TE-specific, and the legacy encoding must be maintained for interoperability.
The ASLA TLV format mirrors the corresponding ASLA sub-TLVs defined for OSPF (RFC 8920) and IS-IS (RFC 8919), maintaining consistency across the IGP-to-BGP-LS mapping. RSVP-TE and GMPLS applications continue to use existing top-level TLVs to preserve backward compatibility with deployed implementations.
Application-specific link attributes received from an IGP node without ASLA encodings continue to be encoded using the respective BGP-LS top-level TLVs as specified in their reference documents, preserving backward compatibility.
BGP-LS consumers that do not support this specification can continue using existing top-level TLVs for link attributes for existing applications (RSVP-TE, SR Policy, LFA), but will be unable to support application-specific link attributes or newer applications encoded only using the ASLA TLV.
Application-specific link attributes received from an OSPF node using an ASLA sub-TLV, or from an IS-IS node using either an ASLA sub-TLV or an Application-Specific SRLG TLV, MUST be encoded in the BGP-LS ASLA TLV as sub-TLVs (with specified exceptions).
BGP-LS Attribute TLVs advertised in the underlying IGP as application-specific are REQUIRED to be encoded within an ASLA TLV.
BGP-LS Attribute TLVs listed in Table 1 (administrative group, TE default metric, SRLG, unidirectional delay/loss/bandwidth metrics) are REQUIRED to be advertised as top-level TLVs in the BGP-LS Attribute when carrying link attributes specific to RSVP-TE.
Both SRLG values from IS-IS Application-Specific SRLG TLVs and link attributes from IS-IS ASLA sub-TLVs with zero-length application bit masks MUST be advertised into a BGP-LS ASLA TLV with a zero-length application bit mask, independent of the collation procedure.
If collated application-specific link attributes and SRLG values are common across multiple applications, they MAY be advertised in a common BGP-LS ASLA TLV instance with bits for all such applications set in the application bit mask.
Link attributes that do not have application-specific semantics MUST NOT be advertised within the ASLA TLV.
Maximum Link Bandwidth MUST be encoded only in the top-level BGP-LS Maximum Link Bandwidth TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA TLV, even though RFC 8919 allows it in IS-IS ASLA sub-TLV.
Maximum Reservable Link Bandwidth and Unreserved Bandwidth MUST be encoded only in the respective top-level BGP-LS TLVs (1090 and 1091) and not within the BGP-LS ASLA TLV, even though RFC 8919 allows them in IS-IS ASLA sub-TLV.
SRLGs from IS-IS Application-Specific SRLG TLVs and link attributes from IS-IS ASLA sub-TLVs are REQUIRED to be collated per-application for applications meeting specific criteria: bit set in one encoding type but the other encoding has zero-length bit masks with no specific advertisement for that application.
The Reserved 2-octet field in the ASLA TLV MUST be set to zero on transmission and MUST be ignored on reception.
When IS-IS ASLA sub-TLV has the RSVP-TE application bit set, the link attributes MUST be encoded using respective BGP-LS top-level TLVs per RFC 7752, RFC 8571, and RFC 9104; similarly SRLG values with RSVP-TE bit MUST use the top-level BGP-LS SRLG TLV (1096).
When the same application-specific link attributes are advertised both within the ASLA TLV and as top-level TLVs, the attributes within the ASLA TLV take precedence for the applications indicated in the ASLA TLV encoding.
Eleven existing BGP-LS Attribute TLVs (administrative group/1088, TE Default Metric/1092, SRLG/1096, and unidirectional delay/loss/bandwidth metrics 1114-1120, Extended Administrative Group/1173) are identified as application-specific and can be carried either as top-level TLVs or as sub-TLVs within the ASLA TLV.
The ASLA TLV (code point 1122) is an optional top-level BGP-LS Attribute TLV introduced for Link NLRIs that acts as a container for existing and future link attributes requiring application-specific definition.
IANA assigned TLV code point 1122 for the Application-Specific Link Attributes TLV in the 'BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs' registry. There is no corresponding IS-IS TLV/Sub-TLV value.
Security considerations for acquiring and distributing BGP-LS information from RFC 7752 apply, particularly those related to topology information used for traffic engineering. IGP instances originating ASLA TLVs are assumed to support all required security as described in RFC 8919 and RFC 8920.
Tampering with application-specific link attribute information defined in this document may affect applications using it, including traffic engineering path computation. However, since advertisements are scoped to specific applications, the impact of tampering is similarly limited in scope and presents no significant additional risk beyond existing BGP-LS link attribute information in RFC 7752.
The Application-Specific Link Attributes (ASLA) TLV (type 1122) contains a 1-octet SABM Length, 1-octet UDABM Length, 2-octet Reserved field (zero on tx, ignored on rx), variable-length Standard Application Identifier Bit Mask (0, 4, or 8 octets), variable-length User-Defined Application Identifier Bit Mask, and Link Attribute sub-TLVs.