<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-app-specific-attr-16"ipr="trust200902">number="9294" submissionType="IETF" category="std" consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <titleabbrev="BGP-LS Extns for App Specific Attributes">Application-Specificabbrev="App-Specific Link Attributes Using BGP-LS">Application-Specific Link Attributes Advertisementwith BGP Link-State</title>Using the Border Gateway Protocol - Link State (BGP-LS)</title> <seriesInfo name="RFC" value="9294"/> <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar"> <organization>ArrcusInc</organization>Inc.</organization> <address> <postal> <street/> <city/> <code/> <country>India</country> </postal> <email>ketant.ietf@gmail.com</email> </address> </author> <author fullname="Peter Psenak" initials="P." surname="Psenak"> <organization>Cisco Systems</organization> <address> <postal> <street/> <city/> <region/> <code/> <country>Slovakia</country> </postal> <email>ppsenak@cisco.com</email> </address> </author> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <organization>Microsoft</organization> <address> <email>jefftant.ietf@gmail.com</email> </address> </author> <dateyear=""/> <area>Routing</area> <workgroup>Inter-Domain Routing</workgroup>year="2022" month="August" /> <area>rtg</area> <workgroup>idr</workgroup> <keyword>BGP-LS</keyword> <keyword>Segment Routing</keyword> <keyword>IS-IS</keyword> <keyword>OSPF</keyword> <keyword>OSPFv3</keyword> <abstract> <t>Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as SegmentRouting.Routing (SR). This document defines extensions toBGP-LSthe Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.</t> </abstract> </front> <middle> <section anchor="INTRO"title="Introduction"> <t>BGP Link-Statenumbered="true" toc="default"> <name>Introduction</name> <t>The Border Gateway Protocol - Link State (BGP-LS) <xreftarget="RFC7752"/>target="RFC7752" format="default"/> enables the distribution of the link-state topology information from link-state routing protocols (viz., IS-IS <xreftarget="RFC1195"/>,target="RFC1195" format="default"/>, OSPFv2 <xreftarget="RFC2328"/>target="RFC2328" format="default"/>, and OSPFv3 <xreftarget="RFC5340"/>)target="RFC5340" format="default"/>) to an application like a controller or Path Computation Engine (PCE) via BGP. Thecontroller/PCEcontroller or PCE gets the end-to-end topology information across IGP domains so it can perform path computations for use cases like end-to-end traffic engineering (TE).</t> <t>The link-state topology information distributed via BGP-LS includes link attributes that were originally defined for MPLSTraffic EngineeringTE (i.e., using RSVP-TE <xreftarget="RFC3209"/>)target="RFC3209" format="default"/> or GMPLS <xreftarget="RFC4202"/>) applications.target="RFC4202" format="default"/> applications). In recentyearsyears, applications, such as Segment Routing (SR) Policy <xreftarget="RFC8402"/>target="RFC8402" format="default"/> and Loop-Free Alternates (LFA) <xreftarget="RFC5286"/>,target="RFC5286" format="default"/>, which also make use of linkattributesattributes, have been introduced. <xreftarget="RFC8919"/>target="RFC8919" format="default"/> and <xreftarget="RFC8920"/>target="RFC8920" format="default"/> define extensions for IS-IS andOSPF respectivelyOSPF, respectively, that enable advertising application-specific link attributes for these and other future applications. This has resulted in the need for a similar BGP-LS extension to include this additional link-state topology information from the link-state routing protocols.</t> <t>This document defines the BGP-LS extensions for the advertisement of application-specific link attributes. It describes the advertisement of these link attributes as top-level TLVs (i.e., as TLVs of the BGP-LS Attribute) and as sub-TLVs of the (top-level)Application SpecificApplication-Specific Link Attributes (ASLA) TLV. The document also describes the procedures for the advertisement of these attributes from the underlying IGPs and discusses their deployment aspects.</t> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="ASLATLV"title="Application Specificnumbered="true" toc="default"> <name>Application-Specific Link AttributesTLV"> <t>The BGP-LSTLV</name> <t>BGP-LS <xreftarget="RFC7752"/>target="RFC7752" format="default"/> specifies the Link Network Layer Reachability Information (NLRI) for the advertisement of links and their attributes using the BGP-LS Attribute. TheApplication-Specific Link Attributes (ASLA)ASLA TLV is an optional top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It is defined such that it may act as a container for certain existing and future link attributes that require application-specific definition.</t> <t>The format of this TLV is as follows and is similar to the corresponding ASLA sub-TLVs defined for OSPF and IS-IS in <xreftarget="RFC8920"/>target="RFC8920" format="default"/> and <xreftarget="RFC8919"/>target="RFC8919" format="default"/>, respectively.</t><t><figure><figure anchor="ASLA-TLV"> <name>Application-Specific Link Attributes TLV</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SABM Length | UDABM Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Standard Application Identifier Bit Mask (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-Defined Application Identifier Bit Mask (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Attribute sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Application-Specific Link Attributes TLV where:]]></artwork></figure><list style="symbols"> <t>Type: 1122</t> <t>Length: variable.</t> <t>SABM Length : 1 octet</figure> <t>where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt> <dd>1122</dd> <dt>Length:</dt> <dd>variable</dd> <dt>SABM Length:</dt> <dd>1-octet fieldcarryingthat carries the Standard Application Identifier Bit Mask Length in octets as defined in <xreftarget="RFC8920"/>.</t> <t>UDABM Length : 1 octettarget="RFC8920" format="default"/>.</dd> <dt>UDABM Length:</dt> <dd>1-octet fieldcarryingthat carries the User-Defined Application Identifier Bit Mask Length in octets as defined in <xreftarget="RFC8920"/>.</t> <t>Reserved: 2 octettarget="RFC8920" format="default"/>.</dd> <dt>Reserved:</dt> <dd>2-octet field thatMUST<bcp14>MUST</bcp14> be set to zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> <t>Standardreception.</dd> <dt>Standard Application Identifier BitMask : AnMask:</dt> <dd>An optional set of bits (of size 0, 4, or 8 octets as indicated by the SABM Length), where each bit represents a single standard application as defined in <xreftarget="RFC8919"/>.</t> <t>User-Definedtarget="RFC8919" format="default"/>.</dd> <dt>User-Defined Application Identifier BitMask : AnMask:</dt> <dd>An optional set of bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), where each bit represents a single user-defined application as defined in <xreftarget="RFC8919"/>target="RFC8919" format="default"/> and <xreftarget="RFC8920"/>..</t> <t>Linktarget="RFC8920" format="default"/>.</dd> <dt>Link Attributesub-TLVs : BGP-LSsub-TLVs:</dt> <dd>BGP-LS Attribute TLVs corresponding to the Link NLRI that are application-specific (including existing ones as specified in <xreftarget="APPSPECATTRS"/>)target="APPSPECATTRS" format="default"/>) are included as sub-TLVs of the ASLATLV.</t> </list></t>TLV.</dd> </dl> <t>The semantics associated with the standard and user-defined bit masks as well as the encoding scheme for application-specific attributes are as specified in <xreftarget="RFC8920"/>.</t>target="RFC8920" format="default"/>.</t> <t>The ASLA TLV and its sub-TLVs can only be added to the BGP-LS Attribute associated with the Link NLRI of the node that originates the underlying IGP link attributeTLVs/sub-TLVs.TLVs and sub-TLVs. The procedures for originating link attributes in the ASLA TLV from underlying IGPs are specified in <xreftarget="PROCEDURES"/>.</t>target="PROCEDURES" format="default"/>.</t> </section> <section anchor="APPSPECATTRS"title="Application-Specificnumbered="true" toc="default"> <name>Application-Specific LinkAttributes">Attributes</name> <t>Several BGP-LS Attribute TLVs corresponding to the Link NLRI are defined in BGP-LS <xref target="RFC7752" format="default"/>, and more may be added in the future. Those attributes that have been determined to be, and advertisedasas, application-specific in the underlying IGPs are also encoded similarly in BGP-LS.</t> <t>The following table lists the currently defined BGP-LSAttributesAttribute TLVs corresponding to Link NLRI that can have application-specific semantics based on the underlying IGP specifications <xreftarget="RFC8919"/>target="RFC8919" format="default"/> <xreftarget="RFC8920"/>.target="RFC8920" format="default"/>. These were originally defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by the respective reference documents.</t><texttable<table anchor="APPSPECATTR"title="Existingalign="center"> <name>Existing BGP-LS TLVsidentifiedIdentified asApplication-Specific"> <ttcolApplication-Specific</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcolPoint</th> <th align="left">Description</th> <th align="left">ReferenceDocument</ttcol> <c>1088</c> <c>AdministrativeDocument</th> </tr> </thead> <tbody> <tr> <td align="center">1088</td> <td align="left">Administrative group(color)</c> <c><xref target="RFC7752"/></c> <c>1092</c> <c>TE(color)</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1092</td> <td align="left">TE DefaultMetric</c> <c><xref target="RFC7752"/></c> <c>1096</c> <c>SharedMetric</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1096</td> <td align="left">Shared Risk LinkGroup</c> <c><xref target="RFC7752"/></c> <c>1114</c> <c>Unidirectional Link Delay</c> <c><xref target="RFC8571"/></c> <c>1115</c> <c>Min/MaxGroup</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1114</td> <td align="left">Unidirectional Link Delay</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1115</td> <td align="left">Min/Max Unidirectional LinkDelay</c> <c><xref target="RFC8571"/></c> <c>1116</c> <c>UnidirectionalDelay</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1116</td> <td align="left">Unidirectional DelayVariation</c> <c><xref target="RFC8571"/></c> <c>1117</c> <c>Unidirectional Link Loss</c> <c><xref target="RFC8571"/></c> <c>1118</c> <c>UnidirectionalVariation</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1117</td> <td align="left">Unidirectional Link Loss</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1118</td> <td align="left">Unidirectional ResidualBandwidth</c> <c><xref target="RFC8571"/></c> <c>1119</c> <c>UnidirectionalBandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1119</td> <td align="left">Unidirectional AvailableBandwidth</c> <c><xref target="RFC8571"/></c> <c>1120</c> <c>UnidirectionalBandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1120</td> <td align="left">Unidirectional UtilizedBandwidth</c> <c><xref target="RFC8571"/></c> <c>1173</c> <c>ExtendedBandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1173</td> <td align="left">Extended AdministrativeGroup</c> <c><xref target="RFC9104"/></c> </texttable>Group</td> <td align="left"> <xref target="RFC9104" format="default"/></td> </tr> </tbody> </table> <t>All the BGP-LS Attribute TLVs listed in the table above areREQUIRED<bcp14>REQUIRED</bcp14> to be advertised as a top-level TLV in the BGP-LS Attribute when used to carry link attributes specific to RSVP-TE.</t> <t>BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised in the underlying IGP as application-specific areREQUIRED<bcp14>REQUIRED</bcp14> to be encoded within an ASLA TLV.</t> <t>Link attributes that do not have application-specific semanticsMUST NOT<bcp14>MUST NOT</bcp14> be advertised within the ASLA TLV.</t> <t>When the same application-specific link attributes are advertised both within the ASLA TLV and as top-level TLVs in the BGP-LS Attribute, the attributes advertised within the ASLA TLV take precedence for the applications indicated in the ASLA TLV encoding.</t> </section> <section anchor="PROCEDURES"title="Procedures">numbered="true" toc="default"> <name>Procedures</name> <t>The BGP-LS originator learns of the association of an application-specific attribute to one or more applications from the underlying IGP protocolLSA/LSPsLink State Advertisements (LSAs) or Link State Packets (LSPs) from which it is advertising the topology information. <xreftarget="RFC8920"/>target="RFC8920" format="default"/> and <xreftarget="RFC8919"/>target="RFC8919" format="default"/> specify the mechanisms for advertising application-specific link attributes in OSPF andIS-ISIS-IS, respectively.</t> <t>Application-specific link attributes received from an IGP node without the use of ASLA encodings continue to be encoded using the respective BGP-LS top-level TLVs listed in <xreftarget="APPSPECATTR"/>target="APPSPECATTR" format="default"/> as specified in their respective reference documents.</t> <t>While the ASLA encoding in OSPF is similar to that of BGP-LS, the encoding in IS-IS differs and requires additional procedures when conveying information into BGP-LS. One of these differences arises from the presence of the L-flag in the IS-IS encoding. Another difference arises due to the requirement to collate information from two types of IS-IS encodings for application-specific link information (i.e., the IS-IS ASLA sub-TLV and the IS-IS Application-SpecificSRLGShared Risk Link Group (SRLG) TLV) <xreftarget="RFC8919"/>target="RFC8919" format="default"/> and to carry them together in the BGP-LS ASLA TLV.</t> <t>A BGP-LS originator node that is advertising link-state information from the underlying IGP using ASLA encodings determines their BGP-LS encoding based on the followingrules:<list style="numbers"> <t>Application-specificrules:</t> <ol spacing="normal" type="1"><li>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 TLVMUST<bcp14>MUST</bcp14> be encoded in the BGP-LS ASLA TLV as sub-TLVs. Exceptions to this rule are specified in (2)(F) and (2)(G)below.</t>below.</li> <li> <t>In the case of IS-IS, thefollowingspecific procedures below are to befollowed:<list style="letters"> <t>Whenfollowed:</t> <ol spacing="normal" type="A"><li>When application-specific link attributes are received from a node with the L-flag set in the IS-IS ASLA sub-TLV and when application bitsother(other thanRSVP-TERSVP-TE) are set in the application bitmasksmasks, then the application-specific link attributes advertised in the corresponding legacy IS-ISTLVs/sub-TLVs MUSTTLVs and sub-TLVs <bcp14>MUST</bcp14> be encoded within the BGP-LS ASLA TLV as sub-TLVs with the applicationbits, otherbits (other than the RSVP-TEbit,bit) copied from the IS-IS ASLA sub-TLV. The link attributes advertised in the legacy IS-ISTLVs/sub-TLVsTLVs and sub-TLVs are also advertised in BGP-LS top-level TLVs as per <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, <xreftarget="RFC8571"/>target="RFC8571" format="default"/>, and <xreftarget="RFC9104"/>.target="RFC9104" format="default"/>. The same procedure also applies for the advertisement of the SRLG values from the IS-IS Application-Specific SRLGTLV.</t> <t>WhenTLV.</li> <li>When the IS-IS ASLA sub-TLV has the RSVP-TE application bit set, then the link attributes for the corresponding IS-IS ASLA sub-TLVsMUST<bcp14>MUST</bcp14> be encoded using the respective BGP-LS top-level TLVs as per <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, <xreftarget="RFC8571"/>target="RFC8571" format="default"/>, and <xreftarget="RFC9104"/>.target="RFC9104" format="default"/>. Similarly, when the IS-IS Application-Specific SRLG TLV has the RSVP-TE application bit set, then the SRLG values within itMUST<bcp14>MUST</bcp14> be encoded using the top-level BGP-LS SRLG TLV (1096) as per <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</li> <li> <t>The SRLGs advertised in one or more IS-IS Application-Specific SRLGTLV(s)TLVs and the other link attributes advertised in one or more IS-IS ASLAsub-TLV(s)sub-TLVs areREQUIRED<bcp14>REQUIRED</bcp14> to be collated, on a per-application basis, only for those applications that meet all the followingcriteria:<list style="symbols"> <t>theircriteria:</t> <ul spacing="normal"> <li>their bit is set in theSABM/UDABMSABM or UDABM in one of the two types of IS-IS encodings (e.g., IS-IS ASLAsub-TLV)</t> <t>thesub-TLV)</li> <li>the other encoding type (e.g., IS-IS Application Specific SRLG TLV) has an advertisement with zero-length application bitmasks</t> <t>theremasks</li> <li>there is no corresponding advertisement of that other encoding type (following the example, IS-IS Application Specific SRLG TLV) with that specific application bitset</t> </list>Forset</li> </ul> <t>For each such application, its collated informationMUST<bcp14>MUST</bcp14> be carried in a BGP-LS ASLA TLV with that application's bit set in theSABM/UDABM.SABM or UDABM. See the illustration in <xreftarget="EXAMPLE"/>.</t> <t>Iftarget="EXAMPLE" format="default"/>.</t> </li> <li>If the resulting set of collated link attributes and SRLG values is common across multiple applications, theyMAY<bcp14>MAY</bcp14> be advertised in a common BGP-LS ASLA TLV instance where the bits for all such applications would be set in the application bitmask.</t> <t>Bothmask.</li> <li>Both the SRLG values from IS-IS Application-Specific SRLG TLVs and the link attributes from IS-IS ASLA sub-TLVs, with the zero-length application bit mask,MUST<bcp14>MUST</bcp14> be advertised into a BGP-LS ASLA TLV with a zero-length application bit mask, independent of the collation describedabove.</t> <t><xref target="RFC8919"/>above.</li> <li> <xref target="RFC8919" format="default"/> allows the advertisement of the Maximum Link Bandwidth within an IS-IS ASLA sub-TLV even though it is not an application-specific attribute. However, when originating the Maximum Link Bandwidth into BGP-LS, the attributeMUST<bcp14>MUST</bcp14> be encoded only in the top-level BGP-LS Maximum Link Bandwidth TLV (1089) andMUST NOT<bcp14>MUST NOT</bcp14> be advertised within the BGP-LS ASLATLV.</t> <t><xref target="RFC8919"/>TLV.</li> <li> <xref target="RFC8919" format="default"/> also allows the advertisement of the Maximum Reservable Link Bandwidth and the Unreserved Bandwidth within an IS-IS ASLA sub-TLV even though these attributes are specific to RSVP-TE application. However, when originating the Maximum Reservable Link Bandwidth and Unreserved Bandwidth into BGP-LS, these attributesMUST<bcp14>MUST</bcp14> be encoded only in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV (1090) and Unreserved Bandwidth TLV(1091) respectively(1091), respectively, and not within the BGP-LS ASLATLV.</t> </list></t> </list></t>TLV.</li> </ol> </li> </ol> <t>These rules ensure that a BGP-LS originator performs the advertisement for all application-specific link attributes from the IGP nodes that support the ASLA extension. Furthermore, it also ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS applications continue to be used for advertisement of their application-specific attributes.</t> <t>A BGP-LS speaker would normally advertise all the application-specific link attributes corresponding to RSVP-TE and GMPLS applications as existing top-level BGP-LS TLVs while for other applications they are encoded in the ASLA TLV(s) with appropriate applicable bit mask setting. An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV.</t> <section anchor="EXAMPLE"title="Illustrationnumbered="true" toc="default"> <name>Illustration forIS-IS">IS-IS</name> <t>This section illustrates the procedure for the advertisement of application-specific link attributes from IS-IS into BGP-LS.</t> <t>Consider the following advertisements for a link in IS-IS. We start with thisset:<list style="letters"> <t>An IS-ISset:</t> <ol spacing="normal" type="a"><li>IS-IS ASLA sub-TLV with the S, F, and X bits set on itcarryingthat carries certain application-specific linkattributes</t> <t>An IS-ISattributes</li> <li>IS-IS Application-Specific SRLG TLV with zero-length bit masks with a set of application-specificSRLGs</t> <t>An IS-ISSRLGs</li> <li>IS-IS Application-Specific SRLG TLV with the X bit set on it with a set of application-specificSRLGs</t> </list></t>SRLGs</li> </ol> <t>The corresponding BGP-LS advertisements for that link are determined as follows:</t> <t>First, based on rule (1), the advertisements are conveyed to BGP-LS to get the following "updatedset":<list style="numbers"> <t>ASLAset":</t> <ol spacing="normal" type="1"><li>ASLA with the S, F, and X bits set on itcarryingthat carries link attributes from IS-IS advertisement(a)</t> <t>ASLA(a)</li> <li>ASLA SRLG with zero-length bit masks with a set of SRLGs from IS-IS advertisement(b)</t> <t>ASLA(b)</li> <li>ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS advertisement(c)</t> </list></t>(c)</li> </ol> <t>Next, we apply the rules from (2) to this "updated set", because all of them were sourced from IS-IS, to derive a new set.</t> <t>The next rule that applies is(2)(c)(2)(c), and it is determined that collation is required for applications S and F; therefore, we get the following "finalset":<list style="numbers"> <t>ASLAset":</t> <ol spacing="normal" type="1"><li>ASLA with the S bit set on itcarryingthat carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application S based on(2)(c))</t> <t>ASLA(2)(c))</li> <li>ASLA with the F bit set on itcarryingthat carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application F based on(2)(c))</t> <t>ASLA(2)(c))</li> <li>ASLA with the X bit set on itcarryingthat carries link attributes from IS-IS advertisement (a) (remaining application not affected by collation based on(2)(c))</t> <t>ASLA(2)(c))</li> <li>ASLA with zero-length bit masks with SRLGs from IS-IS advertisement (b) (not affected by (2)(c) and therefore carried forward unchanged from the "updatedset")</t> <t>ASLAset")</li> <li>ASLA with the X bit set on it with SRLGs from IS-IS advertisement (c) (not affected by (2)(c) and therefore carried forward unchanged from the "updatedset")</t> </list></t>set")</li> </ol> <t>Implementations may optionally perform further consolidation by processing the "final set" above based on (2)(d) to determine the following "consolidated finalset":<list style="numbers"> <t>ASLAset":</t> <ol spacing="normal" type="1"><li>ASLA with the S and F bits set on itcarryingthat carries application-specific link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is the consolidation of items 1 and 2 of the "final set" based on(2)(d))</t> <t>ASLA(2)(d))</li> <li>ASLA with the X bit set on itcarryingthat carries certain application-specific link attributes from IS-IS advertisement (a) (it is unaffected by thisconsolidation)</t> <t>ASLAconsolidation)</li> <li>ASLA with zero-length bit masks with a set of application-specific SRLGs from IS-IS advertisement (b) (this is retained based on (2)(e) and is unaffected by any furtherconsolidation)</t> <t>ASLAconsolidation)</li> <li>ASLA with the X bit set on it with a set of application-specific SRLGs from IS-IS advertisement (c) (it is unaffected by thisconsolidation)</t> </list></t>consolidation)</li> </ol> <t>Further optimization (e.g., combining (2) and (4) from the "consolidated final set" above into a single BGP-LS ASLA TLV) may be possible while ensuring that the semantics are preserved between the IS-IS and BGP-LS advertisements. Such optimizations are outside the scope of this document.</t> </section> </section> <section anchor="DEPLOY"title="Deployment Considerations">numbered="true" toc="default"> <name>Deployment Considerations</name> <t>BGP-LS sources the link-state topology information (including the extensions introduced by this document) from the underlying link-state IGP protocols. The various deployment aspects related to the advertisement and use of application-specific link attributes are discussed in the Deployment Considerations sections of <xreftarget="RFC8920"/>target="RFC8920" format="default"/> and <xreftarget="RFC8919"/>.target="RFC8919" format="default"/>. The IGPbackward compatibilitybackward-compatibility aspects described in those documents associated with application-specific link attributes along with the BGP-LS procedures specified in this document enable backward compatibility in deployments of existing implementations of <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, <xreftarget="RFC8571"/>target="RFC8571" format="default"/>, and <xreftarget="RFC9104"/>target="RFC9104" format="default"/> for applications such as RSVP-TE, SR Policy, and LFA.</t> <t>It is recommended that only nodes supporting this specification are selected as originators of BGP-LS information when advertising the link-state information from the IGPs in deployments supporting application-specific link attributes.</t> <t>BGP-LS consumers that do not support this specification can continue to use the existing top-level TLVs for link attributes for existing applications as discussed above.They would, however,However, they would be able to support neither the application-specific link attributes nor newer applications that may be encoded only using the ASLA TLV.</t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA hasassigned, through the early allocation process, the following code-pointassigned a code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"registry. This document requests thatregistry as described in theallocation be made permanent. The columnfollowing table. There is no "IS-IS TLV/Sub-TLV"defined in the registry does not require anyvalueand should be left empty.</t> <figure> <artwork align="center"><![CDATA[ +------------+--------------------------------------+---------------+ | Code Point | Description | Reference | +------------+--------------------------------------+---------------+ | 1122 | Application-Specific Link Attributes |for thisdocument | +------------+--------------------------------------+---------------+ Table 2: ASLAentry.</t> <table anchor="code-point" align="center"> <name>ASLA TLVCode-Point Allocation ]]></artwork> </figure>Code Point Allocation</name> <thead> <tr> <th rowspan="1" colspan="1">TLV Code Point</th> <th rowspan="1" colspan="1">Description</th> <th rowspan="1" colspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td>1122</td> <td>Application-Specific Link Attributes</td> <td>RFC 9294</td> </tr> </tbody> </table> </section> <section anchor="Manageability"title="Manageability Considerations">numbered="true" toc="default"> <name>Manageability Considerations</name> <t>The protocol extensions introduced in this document augment the existing IGP topology information defined in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Specifically, the malformedNLRIsNLRI attribute tests in the Fault Management section of <xreftarget="RFC7752"/>target="RFC7752" format="default"/> nowencompassesencompass the BGP-LS TLVs defined in this document.</t> <t>The extensions specified in this document do not specify any new configuration or monitoring aspects in BGP or BGP-LS. The specification of BGP models is an ongoing work based on <xreftarget="I-D.ietf-idr-bgp-model"/>.</t>target="I-D.ietf-idr-bgp-model" format="default"/>.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>Security considerations for acquiring and distributing BGP-LS information are discussed in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Specifically, the considerations related to topologyinformationinformation, which are related to trafficengineeringengineering, apply.</t> <t>The TLVs introduced in this document are used to propagate the application-specific link attributes IGP extensions defined in <xreftarget="RFC8919"/>target="RFC8919" format="default"/> and <xreftarget="RFC8920"/>.target="RFC8920" format="default"/>. It is assumed that the IGP instances originating these TLVs will support all the required security (as described in <xreftarget="RFC8919"/>target="RFC8919" format="default"/> and <xreftarget="RFC8920"/>).</t>target="RFC8920" format="default"/>).</t> <t>This document defines a new way to advertise link attributes. Tampering with the information defined in this document may affect applications using it, including impacting traffic engineering, which uses various link attributes for its path computation. As the advertisements defined in this document limit the scope to specific applications, the impact of tampering is similarly limited in scope. The advertisement of the link attribute information defined in this document presents no significant additional risk beyond that associated with the existing link attribute information already supported in <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</t> </section> </middle> <back> <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8919.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8920.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9104.xml"/> </references> <references> <name>Informative References</name> <reference anchor='RFC1195' target='https://www.rfc-editor.org/info/rfc1195'> <front> <title>Use of OSI IS-IS for routing in TCP/IP and dual environments</title> <author initials='R.' surname='Callon' fullname='R. Callon'><organization /></author> <date year='1990' month='December' /> <abstract><t>This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='1195'/> <seriesInfo name='DOI' value='10.17487/RFC1195'/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <!-- [I-D.ietf-idr-bgp-model] IESG state I-D Exists as of 8/17/22 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"/> </references> </references> <section anchor="ACK"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thankLes Ginsberg, Baalajee S, Amalesh Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, Kristy Paine, and Shraddha Hegde<contact fullname="Les Ginsberg"/>, <contact fullname="Baalajee S."/>, <contact fullname="Amalesh Maity"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Keyur Patel"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Rudy Selderslaghs"/>, <contact fullname="Kristy Paine"/>, and <contact fullname="Shraddha Hegde"/> for their review and feedback on this document. The authors would like to thankAlvaro Retana<contact fullname="Alvaro Retana"/> for his very detailed AD review and commentsfor improvingthat improved this document. The authors would also like to thankJohn Scudder<contact fullname="John Scudder"/> for his detailed review and feedback on clarifying the procedures along with the example in <xreftarget="PROCEDURES"/>.</t>target="PROCEDURES" format="default"/>.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include='reference.RFC.7752'?> <?rfc include="reference.RFC.8174"?> <?rfc include='reference.RFC.8919'?> <?rfc include='reference.RFC.8920'?> <?rfc include='reference.RFC.8571'?> <?rfc include='reference.RFC.9104'?> </references> <references title="Informative References"> <?rfc include="reference.RFC.1195"?> <?rfc include="reference.RFC.2328"?> <?rfc include="reference.RFC.4202"?> <?rfc include="reference.RFC.5340"?> <?rfc include="reference.RFC.5286"?> <?rfc include="reference.RFC.3209"?> <?rfc include='reference.RFC.8402'?> <?rfc include='reference.I-D.ietf-idr-bgp-model'?> </references></back> </rfc>