rfc9294xml2.original.xml   rfc9294.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "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"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-app-specific-attr-16"
ipr="trust200902">
<front>
<title
abbrev="BGP-LS Extns for App Specific Attributes">Application-Specific
Attributes Advertisement with BGP Link-State</title>
<author fullname="Ketan Talaulikar" initials="K." role="editor" <!DOCTYPE rfc [
surname="Talaulikar"> <!ENTITY nbsp "&#160;">
<organization>Arrcus Inc</organization> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-a
pp-specific-attr-16" number="9294" submissionType="IETF" category="std" consensu
s="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="tru
e" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="App-Specific Link Attributes Using BGP-LS">Application-Specif
ic Link
Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP
-LS)</title>
<seriesInfo name="RFC" value="9294"/>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
aulikar">
<organization>Arrcus Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P." surname="Psenak"> <author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="August" />
<date year=""/> <area>rtg</area>
<workgroup>idr</workgroup>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>OSPFv3</keyword> <keyword>OSPFv3</keyword>
<abstract> <abstract>
<t>Extensions have been defined for link-state routing protocols that <t>Extensions have been defined for link-state routing protocols that
enable distribution of application-specific link attributes for existing enable distribution of application-specific link attributes for existing
as well as newer applications such as Segment Routing. This document as well as newer applications such as Segment Routing (SR). This document
defines extensions to BGP-LS to enable the advertisement of these defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to
enable the advertisement of these
application-specific attributes as a part of the topology information application-specific attributes as a part of the topology information
from the network.</t> from the network.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>BGP Link-State <xref target="RFC7752"/> enables the distribution of <name>Introduction</name>
<t>The Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC7752
" format="default"/> enables the distribution of
the link-state topology information from link-state routing protocols the link-state topology information from link-state routing protocols
(viz., IS-IS <xref target="RFC1195"/>, OSPFv2 <xref target="RFC2328"/> (viz., IS-IS <xref target="RFC1195" format="default"/>, OSPFv2 <xref targe
and OSPFv3 <xref target="RFC5340"/>) to an application like a controller t="RFC2328" format="default"/>,
or Path Computation Engine (PCE) via BGP. The controller/PCE gets the and OSPFv3 <xref target="RFC5340" format="default"/>) to an application li
ke a controller
or Path Computation Engine (PCE) via BGP. The controller or PCE gets the
end-to-end topology information across IGP domains so it can perform end-to-end topology information across IGP domains so it can perform
path computations for use cases like end-to-end traffic engineering path computations for use cases like end-to-end traffic engineering
(TE).</t> (TE).</t>
<t>The link-state topology information distributed via BGP-LS includes <t>The link-state topology information distributed via BGP-LS includes
link attributes that were originally defined for MPLS Traffic link attributes that were originally defined for MPLS TE (i.e., using RSVP
Engineering (i.e., using RSVP-TE <xref target="RFC3209"/>) or GMPLS -TE <xref target="RFC3209" format="default"/> or GMPLS <xref target="RFC4202" fo
<xref target="RFC4202"/>) applications. In recent years applications, rmat="default"/> applications). In recent years, applications,
such as Segment Routing (SR) Policy <xref target="RFC8402"/> and such as Segment Routing (SR) Policy <xref target="RFC8402" format="default
Loop-Free Alternates (LFA) <xref target="RFC5286"/>, which also make use "/> and
of link attributes have been introduced. <xref target="RFC8919"/> and Loop-Free Alternates (LFA) <xref target="RFC5286" format="default"/>, whic
<xref target="RFC8920"/> define extensions for IS-IS and OSPF h also make use
respectively that enable advertising application-specific link of link attributes, have been introduced. <xref target="RFC8919" format="d
efault"/> and
<xref target="RFC8920" format="default"/> define extensions for IS-IS and
OSPF,
respectively, that enable advertising application-specific link
attributes for these and other future applications. This has resulted in attributes for these and other future applications. This has resulted in
the need for a similar BGP-LS extension to include this additional the need for a similar BGP-LS extension to include this additional
link-state topology information from the link-state routing link-state topology information from the link-state routing
protocols.</t> protocols.</t>
<t>This document defines the BGP-LS extensions for the advertisement of <t>This document defines the BGP-LS extensions for the advertisement of
application-specific link attributes. It describes 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 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 Specific Link Attribute) and as sub-TLVs of the (top-level) Application-Specific Link
Attributes TLV. The document also describes the procedures for the Attributes (ASLA) TLV. The document also describes the procedures for the
advertisement of these attributes from the underlying IGPs and discusses advertisement of these attributes from the underlying IGPs and discusses
their deployment aspects.</t> their deployment aspects.</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
"OPTIONAL" in this document are to be interpreted as described in BCP >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<b
when, they appear in all capitals, as shown here.</t> cp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document ar
e to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174
"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="ASLATLV" numbered="true" toc="default">
<section anchor="ASLATLV" title="Application Specific Link Attributes TLV"> <name>Application-Specific Link Attributes TLV</name>
<t>The BGP-LS <xref target="RFC7752"/> specifies the Link Network Layer <t>BGP-LS <xref target="RFC7752" format="default"/> specifies the Link Net
work Layer
Reachability Information (NLRI) for the advertisement of links and their Reachability Information (NLRI) for the advertisement of links and their
attributes using the BGP-LS Attribute. The Application-Specific Link attributes using the BGP-LS Attribute. The ASLA TLV is an optional top-lev
Attributes (ASLA) TLV is an optional top-level BGP-LS Attribute TLV that el BGP-LS Attribute TLV that
is introduced for Link NLRIs. It is defined such that it may act as a 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 container for certain existing and future link attributes that require
application-specific definition.</t> application-specific definition.</t>
<t>The format of this TLV is as follows and is similar to the <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 <xref corresponding ASLA sub-TLVs defined for OSPF and IS-IS in <xref target="RF
target="RFC8920"/> and <xref target="RFC8919"/> respectively.</t> C8920" format="default"/> and <xref target="RFC8919" format="default"/>, respect
ively.</t>
<t><figure> <figure anchor="ASLA-TLV">
<artwork align="center"><![CDATA[ 0 1 <name>Application-Specific Link Attributes TLV</name>
2 3 <artwork 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABM Length | UDABM Length | Reserved | | SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Identifier Bit Mask (variable) // | Standard Application Identifier Bit Mask (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Defined Application Identifier Bit Mask (variable) // | User-Defined Application Identifier Bit Mask (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute sub-TLVs // | Link Attribute sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Application-Specific Link Attributes TLV
where:
]]></artwork> ]]></artwork>
</figure><list style="symbols"> </figure>
<t>Type: 1122</t>
<t>Length: variable.</t>
<t>SABM Length : 1 octet field carrying the Standard Application
Identifier Bit Mask Length in octets as defined in <xref
target="RFC8920"/>.</t>
<t>UDABM Length : 1 octet field carrying the User-Defined
Application Identifier Bit Mask Length in octets as defined in <xref
target="RFC8920"/>.</t>
<t>Reserved: 2 octet field that MUST be set to zero on transmission
and MUST be ignored on reception.</t>
<t>Standard Application Identifier Bit Mask : An optional set of <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 field that carries the Standard Applic
ation
Identifier Bit Mask Length in octets as defined in <xref target="RFC89
20" format="default"/>.</dd>
<dt>UDABM Length:</dt> <dd>1-octet field that carries the User-Defined
Application Identifier Bit Mask Length in octets as defined in <xref t
arget="RFC8920" format="default"/>.</dd>
<dt>Reserved:</dt> <dd>2-octet field that <bcp14>MUST</bcp14> be set to
zero on transmission
and <bcp14>MUST</bcp14> be ignored on reception.</dd>
<dt>Standard Application Identifier Bit Mask:</dt> <dd>An optional set o
f
bits (of size 0, 4, or 8 octets as indicated by the SABM Length), bits (of size 0, 4, or 8 octets as indicated by the SABM Length),
where each bit represents a single standard application as defined where each bit represents a single standard application as defined
in <xref target="RFC8919"/>.</t> in <xref target="RFC8919" format="default"/>.</dd>
<dt>User-Defined Application Identifier Bit Mask:</dt> <dd>An optional s
<t>User-Defined Application Identifier Bit Mask : An optional set of et of
bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), bits (of size 0, 4, or 8 octets as indicated by the UDABM Length),
where each bit represents a single user-defined application as where each bit represents a single user-defined application as
defined in <xref target="RFC8919"/> <xref target="RFC8920"/>..</t> defined in <xref target="RFC8919" format="default"/> and <xref target=
"RFC8920" format="default"/>.</dd>
<t>Link Attribute sub-TLVs : BGP-LS Attribute TLVs corresponding to <dt>Link Attribute sub-TLVs:</dt> <dd>BGP-LS Attribute TLVs correspondin
g to
the Link NLRI that are application-specific (including existing ones the Link NLRI that are application-specific (including existing ones
as specified in <xref target="APPSPECATTRS"/>) are included as as specified in <xref target="APPSPECATTRS" format="default"/>) are in
sub-TLVs of the ASLA TLV.</t> cluded as
</list></t> sub-TLVs of the ASLA TLV.</dd>
</dl>
<t>The semantics associated with the standard and user-defined bit masks <t>The semantics associated with the standard and user-defined bit masks
as well as the encoding scheme for application-specific attributes are as well as the encoding scheme for application-specific attributes are
as specified in <xref target="RFC8920"/>.</t> as specified in <xref target="RFC8920" format="default"/>.</t>
<t>The ASLA TLV and its sub-TLVs can only be added to the BGP-LS <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 Attribute associated with the Link NLRI of the node that originates the
underlying IGP link attribute TLVs/sub-TLVs. The procedures for underlying IGP link attribute TLVs and sub-TLVs. The procedures for
originating link attributes in the ASLA TLV from underlying IGPs are originating link attributes in the ASLA TLV from underlying IGPs are
specified in <xref target="PROCEDURES"/>.</t> specified in <xref target="PROCEDURES" format="default"/>.</t>
</section> </section>
<section anchor="APPSPECATTRS" numbered="true" toc="default">
<section anchor="APPSPECATTRS" <name>Application-Specific Link Attributes</name>
title="Application-Specific Link Attributes">
<t>Several BGP-LS Attribute TLVs corresponding to the Link NLRI are <t>Several BGP-LS Attribute TLVs corresponding to the Link NLRI are
defined in BGP-LS and more may be added in the future. Those attributes defined in BGP-LS <xref target="RFC7752" format="default"/>, and more may
that have been determined to be, and advertised as application-specific be added in the future. Those attributes
that have been determined to be, and advertised as, application-specific
in the underlying IGPs are also encoded similarly in BGP-LS.</t> in the underlying IGPs are also encoded similarly in BGP-LS.</t>
<t>The following table lists the currently defined BGP-LS Attribute
<t>The following table lists the currently defined BGP-LS Attributes
TLVs corresponding to Link NLRI that can have application-specific TLVs corresponding to Link NLRI that can have application-specific
semantics based on the underlying IGP specifications <xref semantics based on the underlying IGP specifications <xref target="RFC8919
target="RFC8919"/> <xref target="RFC8920"/>. These were originally " format="default"/> <xref target="RFC8920" format="default"/>. These were origi
nally
defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by
the respective reference documents.</t> the respective reference documents.</t>
<table anchor="APPSPECATTR" align="center">
<texttable anchor="APPSPECATTR" <name>Existing BGP-LS TLVs Identified as Application-Specific</name>
title="Existing BGP-LS TLVs identified as Application-Specific" <thead>
> <tr>
<ttcol align="center">TLV Code Point</ttcol> <th align="center">TLV Code Point</th>
<th align="left">Description</th>
<ttcol align="left">Description</ttcol> <th align="left">Reference Document</th>
</tr>
<ttcol align="left">Reference Document</ttcol> </thead>
<tbody>
<c>1088</c> <tr>
<td align="center">1088</td>
<c>Administrative group (color)</c> <td align="left">Administrative group (color)</td>
<td align="left">
<c><xref target="RFC7752"/></c> <xref target="RFC7752" format="default"/></td>
</tr>
<c>1092</c> <tr>
<td align="center">1092</td>
<c>TE Default Metric</c> <td align="left">TE Default Metric</td>
<td align="left">
<c><xref target="RFC7752"/></c> <xref target="RFC7752" format="default"/></td>
</tr>
<c>1096</c> <tr>
<td align="center">1096</td>
<c>Shared Risk Link Group</c> <td align="left">Shared Risk Link Group</td>
<td align="left">
<c><xref target="RFC7752"/></c> <xref target="RFC7752" format="default"/></td>
</tr>
<c>1114</c> <tr>
<td align="center">1114</td>
<c>Unidirectional Link Delay</c> <td align="left">Unidirectional Link Delay</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1115</c> <tr>
<td align="center">1115</td>
<c>Min/Max Unidirectional Link Delay</c> <td align="left">Min/Max Unidirectional Link Delay</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1116</c> <tr>
<td align="center">1116</td>
<c>Unidirectional Delay Variation</c> <td align="left">Unidirectional Delay Variation</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1117</c> <tr>
<td align="center">1117</td>
<c>Unidirectional Link Loss</c> <td align="left">Unidirectional Link Loss</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1118</c> <tr>
<td align="center">1118</td>
<c>Unidirectional Residual Bandwidth</c> <td align="left">Unidirectional Residual Bandwidth</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1119</c> <tr>
<td align="center">1119</td>
<c>Unidirectional Available Bandwidth</c> <td align="left">Unidirectional Available Bandwidth</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1120</c> <tr>
<td align="center">1120</td>
<c>Unidirectional Utilized Bandwidth</c> <td align="left">Unidirectional Utilized Bandwidth</td>
<td align="left">
<c><xref target="RFC8571"/></c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>1173</c> <tr>
<td align="center">1173</td>
<c>Extended Administrative Group</c> <td align="left">Extended Administrative Group</td>
<td align="left">
<c><xref target="RFC9104"/></c> <xref target="RFC9104" format="default"/></td>
</texttable> </tr>
</tbody>
<t>All the BGP-LS Attribute TLVs listed in the table above are REQUIRED </table>
<t>All the BGP-LS Attribute TLVs listed in the table above are <bcp14>REQU
IRED</bcp14>
to be advertised as a top-level TLV in the BGP-LS Attribute when used to to be advertised as a top-level TLV in the BGP-LS Attribute when used to
carry link attributes specific to RSVP-TE.</t> carry link attributes specific to RSVP-TE.</t>
<t>BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised <t>BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised
in the underlying IGP as application-specific are REQUIRED to be encoded in the underlying IGP as application-specific are <bcp14>REQUIRED</bcp14> to be encoded
within an ASLA TLV.</t> within an ASLA TLV.</t>
<t>Link attributes that do not have application-specific semantics <bcp14>
<t>Link attributes that do not have application-specific semantics MUST MUST
NOT be advertised within the ASLA TLV.</t> NOT</bcp14> be advertised within the ASLA TLV.</t>
<t>When the same application-specific link attributes are advertised <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, 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 the attributes advertised within the ASLA TLV take precedence for the
applications indicated in the ASLA TLV encoding.</t> applications indicated in the ASLA TLV encoding.</t>
</section> </section>
<section anchor="PROCEDURES" numbered="true" toc="default">
<name>Procedures</name>
<section anchor="PROCEDURES" title="Procedures">
<t>The BGP-LS originator learns of the association of an <t>The BGP-LS originator learns of the association of an
application-specific attribute to one or more applications from the application-specific attribute to one or more applications from the
underlying IGP protocol LSA/LSPs from which it is advertising the underlying IGP protocol Link State Advertisements (LSAs) or Link State Pac
topology information. <xref target="RFC8920"/> and <xref kets (LSPs) from which it is advertising the
target="RFC8919"/> specify the mechanisms for advertising topology information. <xref target="RFC8920" format="default"/> and <xref
application-specific link attributes in OSPF and IS-IS respectively.</t> target="RFC8919" format="default"/> specify the mechanisms for advertising
application-specific link attributes in OSPF and IS-IS, respectively.</t>
<t>Application-specific link attributes received from an IGP node <t>Application-specific link attributes received from an IGP node
without the use of ASLA encodings continue to be encoded using the without the use of ASLA encodings continue to be encoded using the
respective BGP-LS top-level TLVs listed in <xref target="APPSPECATTR"/> respective BGP-LS top-level TLVs listed in <xref target="APPSPECATTR" form at="default"/>
as specified in their respective reference documents.</t> as specified in their respective reference documents.</t>
<t>While the ASLA encoding in OSPF is similar to that of BGP-LS, the <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 encoding in IS-IS differs and requires additional procedures when
conveying information into BGP-LS. One of these differences arises from conveying information into BGP-LS. One of these differences arises from
the presence of the L-flag in the IS-IS encoding. Another difference 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 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 encodings for application-specific link information (i.e., the
IS-IS ASLA sub-TLV and the IS-IS Application-Specific SRLG TLV) <xref IS-IS ASLA sub-TLV and the IS-IS Application-Specific Shared Risk Link Gro
target="RFC8919"/> and to carry them together in the BGP-LS ASLA up (SRLG) TLV) <xref target="RFC8919" format="default"/> and to carry them toget
her in the BGP-LS ASLA
TLV.</t> TLV.</t>
<t>A BGP-LS originator node that is advertising link-state information <t>A BGP-LS originator node that is advertising link-state information
from the underlying IGP using ASLA encodings determines their BGP-LS from the underlying IGP using ASLA encodings determines their BGP-LS
encoding based on the following rules:<list style="numbers"> encoding based on the following rules:</t>
<t>Application-specific link attributes received from an OSPF node <ol spacing="normal" type="1"><li>Application-specific link attributes rec
using ASLA sub-TLV or from an IS-IS node using either ASLA sub-TLV eived from an OSPF node
or Application-Specific SRLG TLV MUST be encoded in the BGP-LS ASLA using an ASLA sub-TLV or from an IS-IS node using either an ASLA sub-T
LV
or an Application-Specific SRLG TLV <bcp14>MUST</bcp14> be encoded in
the BGP-LS ASLA
TLV as sub-TLVs. Exceptions to this rule are specified in (2)(F) and TLV as sub-TLVs. Exceptions to this rule are specified in (2)(F) and
(2)(G) below.</t> (2)(G) below.</li>
<li>
<t>In the case of IS-IS, the following specific procedures are to be <t>In the case of IS-IS, the specific procedures below are to be
followed:<list style="letters"> followed:</t>
<t>When application-specific link attributes are received from a <ol spacing="normal" type="A"><li>When application-specific link attri
node with the L-flag set in the IS-IS ASLA sub-TLV and butes are received from a
application bits other than RSVP-TE are set in the application node with the L-flag set in the IS-IS ASLA sub-TLV and when
bit masks then the application-specific link attributes application bits (other than RSVP-TE) are set in the application
advertised in the corresponding legacy IS-IS TLVs/sub-TLVs MUST bit masks, then the application-specific link attributes
advertised in the corresponding legacy IS-IS TLVs and sub-TLVs <bc
p14>MUST</bcp14>
be encoded within the BGP-LS ASLA TLV as sub-TLVs with the be encoded within the BGP-LS ASLA TLV as sub-TLVs with the
application bits, other than the RSVP-TE bit, copied from the application bits (other than the RSVP-TE bit) copied from the
IS-IS ASLA sub-TLV. The link attributes advertised in the legacy IS-IS ASLA sub-TLV. The link attributes advertised in the legacy
IS-IS TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs IS-IS TLVs and sub-TLVs are also advertised in BGP-LS top-level TL
as per <xref target="RFC7752"/> <xref target="RFC8571"/> <xref Vs
target="RFC9104"/>. The same procedure also applies for the as per <xref target="RFC7752" format="default"/>, <xref target="RF
C8571" format="default"/>, and <xref target="RFC9104" format="default"/>. The sa
me procedure also applies for the
advertisement of the SRLG values from the IS-IS advertisement of the SRLG values from the IS-IS
Application-Specific SRLG TLV.</t> Application-Specific SRLG TLV.</li>
<li>When the IS-IS ASLA sub-TLV has the RSVP-TE application bit
<t>When the IS-IS ASLA sub-TLV has the RSVP-TE application bit
set, then the link attributes for the corresponding IS-IS ASLA set, then the link attributes for the corresponding IS-IS ASLA
sub-TLVs MUST be encoded using the respective BGP-LS top-level sub-TLVs <bcp14>MUST</bcp14> be encoded using the respective BGP-L
TLVs as per <xref target="RFC7752"/> <xref target="RFC8571"/> S top-level
<xref target="RFC9104"/>. Similarly, when the IS-IS TLVs as per <xref target="RFC7752" format="default"/>, <xref targe
t="RFC8571" format="default"/>, and
<xref target="RFC9104" format="default"/>. Similarly, when the IS-
IS
Application-Specific SRLG TLV has the RSVP-TE application bit Application-Specific SRLG TLV has the RSVP-TE application bit
set, then the SRLG values within it MUST be encoded using the set, then the SRLG values within it <bcp14>MUST</bcp14> be encoded
top-level BGP-LS SRLG TLV (1096) as per <xref using the
target="RFC7752"/>.</t> top-level BGP-LS SRLG TLV (1096) as per <xref target="RFC7752" for
mat="default"/>.</li>
<t>The SRLGs advertised in IS-IS Application-Specific SRLG <li>
TLV(s) and the other link attributes advertised in IS-IS ASLA <t>The SRLGs advertised in one or more IS-IS Application-Specific
sub-TLV(s) are REQUIRED to be collated, on a per-application SRLG
TLVs and the other link attributes advertised in one or more IS-IS
ASLA
sub-TLVs are <bcp14>REQUIRED</bcp14> to be collated, on a per-appl
ication
basis, only for those applications that meet all the following basis, only for those applications that meet all the following
criteria:<list style="symbols"> criteria:</t>
<t>their bit is set in the SABM/UDABM in one of the two <ul spacing="normal">
types of IS-IS encodings (e.g., IS-IS ASLA sub-TLV)</t> <li>their bit is set in the SABM or UDABM in one of the two
types of IS-IS encodings (e.g., IS-IS ASLA sub-TLV)</li>
<t>the other encoding type (e.g., IS-IS Application Specific <li>the other encoding type (e.g., IS-IS Application Specific
SRLG TLV) has an advertisement with zero-length application SRLG TLV) has an advertisement with zero-length application
bit masks</t> bit masks</li>
<li>there is no corresponding advertisement of that other
<t>there is no corresponding advertisement of that other
encoding type (following the example, IS-IS Application encoding type (following the example, IS-IS Application
Specific SRLG TLV) with that specific application bit Specific SRLG TLV) with that specific application bit
set</t> set</li>
</list>For each such application, its collated information </ul>
MUST be carried in a BGP-LS ASLA TLV with that application's bit <t>For each such application, its collated information
set in the SABM/UDABM. See illustration in <xref <bcp14>MUST</bcp14> be carried in a BGP-LS ASLA TLV with that appl
target="EXAMPLE"/>.</t> ication's bit
set in the SABM or UDABM. See the illustration in <xref target="EX
<t>If the resulting set of collated link attributes and SRLG AMPLE" format="default"/>.</t>
values is common across multiple applications, they MAY be </li>
<li>If the resulting set of collated link attributes and SRLG
values is common across multiple applications, they <bcp14>MAY</bc
p14> be
advertised in a common BGP-LS ASLA TLV instance where the bits advertised in a common BGP-LS ASLA TLV instance where the bits
for all such applications would be set in the application bit for all such applications would be set in the application bit
mask.</t> mask.</li>
<li>Both the SRLG values from IS-IS Application-Specific SRLG
<t>Both the SRLG values from IS-IS Application-Specific SRLG
TLVs and the link attributes from IS-IS ASLA sub-TLVs, with the TLVs and the link attributes from IS-IS ASLA sub-TLVs, with the
zero-length application bit mask, MUST be advertised into a zero-length application bit mask, <bcp14>MUST</bcp14> be advertise d into a
BGP-LS ASLA TLV with a zero-length application bit mask, BGP-LS ASLA TLV with a zero-length application bit mask,
independent of the collation described above.</t> independent of the collation described above.</li>
<li>
<t><xref target="RFC8919"/> allows the advertisement of the <xref target="RFC8919" format="default"/> allows the advertisement
of the
Maximum Link Bandwidth within an IS-IS ASLA sub-TLV even though Maximum Link Bandwidth within an IS-IS ASLA sub-TLV even though
it is not an application-specific attribute. However, when it is not an application-specific attribute. However, when
originating the Maximum Link Bandwidth into BGP-LS, the originating the Maximum Link Bandwidth into BGP-LS, the
attribute MUST be encoded only in the top-level BGP-LS Maximum attribute <bcp14>MUST</bcp14> be encoded only in the top-level BGP
Link Bandwidth TLV (1089) and MUST NOT be advertised within the -LS Maximum
BGP-LS ASLA TLV.</t> Link Bandwidth TLV (1089) and <bcp14>MUST NOT</bcp14> be advertise
d within the
<t><xref target="RFC8919"/> also allows the advertisement of the BGP-LS ASLA TLV.</li>
<li>
<xref target="RFC8919" format="default"/> also allows the advertis
ement of the
Maximum Reservable Link Bandwidth and the Unreserved Bandwidth Maximum Reservable Link Bandwidth and the Unreserved Bandwidth
within an IS-IS ASLA sub-TLV even though these attributes are within an IS-IS ASLA sub-TLV even though these attributes are
specific to RSVP-TE application. However, when originating the specific to RSVP-TE application. However, when originating the
Maximum Reservable Link Bandwidth and Unreserved Bandwidth into Maximum Reservable Link Bandwidth and Unreserved Bandwidth into
BGP-LS, these attributes MUST be encoded only in the BGP-LS BGP-LS, these attributes <bcp14>MUST</bcp14> be encoded only in th e BGP-LS
top-level Maximum Reservable Link Bandwidth TLV (1090) and top-level Maximum Reservable Link Bandwidth TLV (1090) and
Unreserved Bandwidth TLV (1091) respectively and not within the Unreserved Bandwidth TLV (1091), respectively, and not within the
BGP-LS ASLA TLV.</t> BGP-LS ASLA TLV.</li>
</list></t> </ol>
</list></t> </li>
</ol>
<t>These rules ensure that a BGP-LS originator performs the <t>These rules ensure that a BGP-LS originator performs the
advertisement for all application-specific link attributes from the IGP advertisement for all application-specific link attributes from the IGP
nodes that support the ASLA extension. Furthermore, it also ensures that nodes that support the ASLA extension. Furthermore, it also ensures that
the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS applications the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS applications
continue to be used for advertisement of their application-specific continue to be used for advertisement of their application-specific
attributes.</t> attributes.</t>
<t>A BGP-LS speaker would normally advertise all the <t>A BGP-LS speaker would normally advertise all the
application-specific link attributes corresponding to RSVP-TE and GMPLS application-specific link attributes corresponding to RSVP-TE and GMPLS
applications as existing top-level BGP-LS TLVs while for other applications as existing top-level BGP-LS TLVs while for other
applications they are encoded in ASLA TLV(s) with appropriate applicable applications they are encoded in the ASLA TLV(s) with appropriate applicab le
bit mask setting. An application-specific attribute value received via a 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 sub-TLV within the ASLA TLV has precedence over the value received via a
top-level TLV.</t> top-level TLV.</t>
<section anchor="EXAMPLE" numbered="true" toc="default">
<section anchor="EXAMPLE" title="Illustration for IS-IS"> <name>Illustration for IS-IS</name>
<t>This section illustrates the procedure for the advertisement of <t>This section illustrates the procedure for the advertisement of
application-specific link attributes from IS-IS into BGP-LS.</t> application-specific link attributes from IS-IS into BGP-LS.</t>
<t>Consider the following advertisements for a link in IS-IS. We start <t>Consider the following advertisements for a link in IS-IS. We start
with this set:<list style="letters"> with this set:</t>
<t>An IS-IS ASLA sub-TLV with S, F, and X bits set on it carrying <ol spacing="normal" type="a"><li>IS-IS ASLA sub-TLV with the S, F, and
certain application-specific link attributes</t> X bits set on it that carries
certain application-specific link attributes</li>
<t>An IS-IS Application-Specific SRLG TLV with zero-length bit <li>IS-IS Application-Specific SRLG TLV with zero-length bit
masks with a set of application-specific SRLGs</t> masks with a set of application-specific SRLGs</li>
<li>IS-IS Application-Specific SRLG TLV with the X bit set on it
<t>An IS-IS Application-Specific SRLG TLV with the X bit set on it with a set of application-specific SRLGs</li>
with a set of application-specific SRLGs</t> </ol>
</list></t>
<t>The corresponding BGP-LS advertisements for that link are <t>The corresponding BGP-LS advertisements for that link are
determined as follows:</t> determined as follows:</t>
<t>First, based on rule (1), the advertisements are conveyed to BGP-LS <t>First, based on rule (1), the advertisements are conveyed to BGP-LS
to get the following "updated set":<list style="numbers"> to get the following "updated set":</t>
<t>ASLA with S, F, and X bits set on it carrying link attributes <ol spacing="normal" type="1"><li>ASLA with the S, F, and X bits set on
from IS-IS advertisement (a)</t> it that carries link attributes
from IS-IS advertisement (a)</li>
<t>ASLA SRLG with zero-length bit masks with a set of SRLGs from <li>ASLA SRLG with zero-length bit masks with a set of SRLGs from
IS-IS advertisement (b)</t> IS-IS advertisement (b)</li>
<li>ASLA SRLG with the X bit set on it with a set of SRLGs from
<t>ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS advertisement (c)</li>
IS-IS advertisement (c)</t> </ol>
</list></t>
<t>Next, we apply the rules from (2) to this "updated set", because <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> all of them were sourced from IS-IS, to derive a new set.</t>
<t>The next rule that applies is (2)(c), and it is determined that
<t>The next rule that applies is (2)(c) and it is determined that
collation is required for applications S and F; therefore, we get the collation is required for applications S and F; therefore, we get the
following "final set":<list style="numbers"> following "final set":</t>
<t>ASLA with the S bit set on it carrying link attributes from <ol spacing="normal" type="1"><li>ASLA with the S bit set on it that car
ries link attributes from
IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b)
(this is collation for application S based on (2)(c))</t> (this is collation for application S based on (2)(c))</li>
<li>ASLA with the F bit set on it that carries link attributes from
<t>ASLA with the F bit set on it carrying link attributes from
IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b)
(this is collation for application F based on (2)(c))</t> (this is collation for application F based on (2)(c))</li>
<li>ASLA with the X bit set on it that carries link attributes from
<t>ASLA with the X bit set on it carrying link attributes from
IS-IS advertisement (a) (remaining application not affected by IS-IS advertisement (a) (remaining application not affected by
collation based on (2)(c))</t> collation based on (2)(c))</li>
<li>ASLA with zero-length bit masks with SRLGs from IS-IS
<t>ASLA with zero-length bit masks with SRLGs from IS-IS
advertisement (b) (not affected by (2)(c) and therefore carried advertisement (b) (not affected by (2)(c) and therefore carried
forward unchanged from the "updated set")</t> forward unchanged from the "updated set")</li>
<li>ASLA with the X bit set on it with SRLGs from IS-IS
<t>ASLA with the X bit set on it with SRLGs from IS-IS
advertisement (c) (not affected by (2)(c) and therefore carried advertisement (c) (not affected by (2)(c) and therefore carried
forward unchanged from the "updated set")</t> forward unchanged from the "updated set")</li>
</list></t> </ol>
<t>Implementations may optionally perform further consolidation by <t>Implementations may optionally perform further consolidation by
processing the "final set" above based on (2)(d) to determine the processing the "final set" above based on (2)(d) to determine the
following "consolidated final set":<list style="numbers"> following "consolidated final set":</t>
<t>ASLA with S and F bits set on it carrying application-specific <ol spacing="normal" type="1"><li>ASLA with the S and F bits set on it t
hat carries application-specific
link attributes from IS-IS advertisement (a) and SRLGs from IS-IS link attributes from IS-IS advertisement (a) and SRLGs from IS-IS
advertisement (b) (this is the consolidation of items 1 and 2 of advertisement (b) (this is the consolidation of items 1 and 2 of
the "final set" based on (2)(d))</t> the "final set" based on (2)(d))</li>
<li>ASLA with the X bit set on it that carries certain
<t>ASLA with the X bit set on it carrying certain
application-specific link attributes from IS-IS advertisement (a) application-specific link attributes from IS-IS advertisement (a)
(it is unaffected by this consolidation)</t> (it is unaffected by this consolidation)</li>
<li>ASLA with zero-length bit masks with a set of
<t>ASLA with zero-length bit masks with a set of
application-specific SRLGs from IS-IS advertisement (b) (this is application-specific SRLGs from IS-IS advertisement (b) (this is
retained based on (2)(e) and is unaffected by any further retained based on (2)(e) and is unaffected by any further
consolidation)</t> consolidation)</li>
<li>ASLA with the X bit set on it with a set of
<t>ASLA with the X bit set on it with a set of
application-specific SRLGs from IS-IS advertisement (c) (it is application-specific SRLGs from IS-IS advertisement (c) (it is
unaffected by this consolidation)</t> unaffected by this consolidation)</li>
</list></t> </ol>
<t>Further optimization (e.g., combining (2) and (4) from the <t>Further optimization (e.g., combining (2) and (4) from the
"consolidated final set" above into a single BGP-LS ASLA TLV) may be "consolidated final set" above into a single BGP-LS ASLA TLV) may be
possible while ensuring that the semantics are preserved between the possible while ensuring that the semantics are preserved between the
IS-IS and BGP-LS advertisements. Such optimizations are outside the IS-IS and BGP-LS advertisements. Such optimizations are outside the
scope of this document.</t> scope of this document.</t>
</section> </section>
</section> </section>
<section anchor="DEPLOY" numbered="true" toc="default">
<section anchor="DEPLOY" title="Deployment Considerations"> <name>Deployment Considerations</name>
<t>BGP-LS sources the link-state topology information (including the <t>BGP-LS sources the link-state topology information (including the
extensions introduced by this document) from the underlying link-state extensions introduced by this document) from the underlying link-state
IGP protocols. The various deployment aspects related to the IGP protocols. The various deployment aspects related to the
advertisement and use of application-specific link attributes are advertisement and use of application-specific link attributes are
discussed in the Deployment Considerations sections of <xref discussed in the Deployment Considerations sections of <xref target="RFC89
target="RFC8920"/> and <xref target="RFC8919"/>. The IGP backward 20" format="default"/> and <xref target="RFC8919" format="default"/>. The IGP ba
compatibility aspects described in those documents associated with ckward-compatibility aspects
described in those documents associated with
application-specific link attributes along with the BGP-LS procedures application-specific link attributes along with the BGP-LS procedures
specified in this document enable backward compatibility in deployments specified in this document enable backward compatibility in deployments
of existing implementations of <xref target="RFC7752"/> <xref of existing implementations of <xref target="RFC7752" format="default"/>,
target="RFC8571"/> <xref target="RFC9104"/> for applications such as <xref target="RFC8571" format="default"/>, and <xref target="RFC9104" format="de
fault"/> for applications such as
RSVP-TE, SR Policy, and LFA.</t> RSVP-TE, SR Policy, and LFA.</t>
<t>It is recommended that only nodes supporting this specification are <t>It is recommended that only nodes supporting this specification are
selected as originators of BGP-LS information when advertising the selected as originators of BGP-LS information when advertising the
link-state information from the IGPs in deployments supporting link-state information from the IGPs in deployments supporting
application-specific link attributes.</t> application-specific link attributes.</t>
<t>BGP-LS consumers that do not support this specification can continue <t>BGP-LS consumers that do not support this specification can continue
to use the existing top-level TLVs for link attributes for existing to use the existing top-level TLVs for link attributes for existing
applications as discussed above. They would, however, be able to support applications as discussed above. However, they would be able to support
neither the application-specific link attributes nor newer applications neither the application-specific link attributes nor newer applications
that may be encoded only using the ASLA TLV.</t> that may be encoded only using the ASLA TLV.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has assigned a
code point from the "BGP-LS Node Descriptor, Link Descriptor,
Prefix Descriptor, and Attribute TLVs" registry as described in the follow
ing table. There is no "IS-IS TLV/Sub-TLV" value for this entry.</t>
<section anchor="IANA" title="IANA Considerations"> <table anchor="code-point" align="center">
<t>IANA has assigned, through the early allocation process, the <name>ASLA TLV Code Point Allocation</name>
following code-point from the "BGP-LS Node Descriptor, Link Descriptor, <thead>
Prefix Descriptor, and Attribute TLVs" registry. This document requests <tr>
that the allocation be made permanent. The column "IS-IS TLV/Sub-TLV" <th rowspan="1" colspan="1">TLV Code Point</th>
defined in the registry does not require any value and should be left <th rowspan="1" colspan="1">Description</th>
empty.</t> <th rowspan="1" colspan="1">Reference</th>
</tr>
<figure> </thead>
<artwork align="center"><![CDATA[ <tbody>
+------------+--------------------------------------+---------------+ <tr>
| Code Point | Description | Reference | <td>1122</td>
+------------+--------------------------------------+---------------+ <td>Application-Specific Link Attributes</td>
| 1122 | Application-Specific Link Attributes | this document | <td>RFC 9294</td>
+------------+--------------------------------------+---------------+ </tr>
</tbody>
Table 2: ASLA TLV Code-Point Allocation </table>
]]></artwork>
</figure>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>The protocol extensions introduced in this document augment the <t>The protocol extensions introduced in this document augment the
existing IGP topology information defined in <xref target="RFC7752"/>. existing IGP topology information defined in <xref target="RFC7752" format ="default"/>.
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP protocol operations and management other than as affect the BGP protocol operations and management other than as
discussed in the Manageability Considerations section of <xref discussed in the Manageability Considerations section of <xref target="RFC
target="RFC7752"/>. Specifically, the malformed NLRIs attribute tests in 7752" format="default"/>. Specifically, the malformed NLRI attribute tests in
the Fault Management section of <xref target="RFC7752"/> now encompasses the Fault Management section of <xref target="RFC7752" format="default"/>
now encompass
the BGP-LS TLVs defined in this document.</t> the BGP-LS TLVs defined in this document.</t>
<t>The extensions specified in this document do not specify any new <t>The extensions specified in this document do not specify any new
configuration or monitoring aspects in BGP or BGP-LS. The specification configuration or monitoring aspects in BGP or BGP-LS. The specification
of BGP models is an ongoing work based on <xref of BGP models is an ongoing work based on <xref target="I-D.ietf-idr-bgp-m
target="I-D.ietf-idr-bgp-model"/>.</t> odel" format="default"/>.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations for acquiring and distributing BGP-LS <t>Security considerations for acquiring and distributing BGP-LS
information are discussed in <xref target="RFC7752"/>. Specifically, the information are discussed in <xref target="RFC7752" format="default"/>. Sp
considerations related to topology information related to traffic ecifically, the
engineering apply.</t> considerations related to topology information, which are related to traff
ic engineering, apply.</t>
<t>The TLVs introduced in this document are used to propagate the <t>The TLVs introduced in this document are used to propagate the
application-specific link attributes IGP extensions defined in <xref application-specific link attributes IGP extensions defined in <xref targe
target="RFC8919"/> and <xref target="RFC8920"/>. It is assumed that the t="RFC8919" format="default"/> and <xref target="RFC8920" format="default"/>. It
is assumed that the
IGP instances originating these TLVs will support all the required IGP instances originating these TLVs will support all the required
security (as described in <xref target="RFC8919"/> and <xref security (as described in <xref target="RFC8919" format="default"/> and <x
target="RFC8920"/>).</t> ref target="RFC8920" format="default"/>).</t>
<t>This document defines a new way to advertise link attributes. <t>This document defines a new way to advertise link attributes.
Tampering with the information defined in this document may affect Tampering with the information defined in this document may affect
applications using it, including impacting traffic engineering, which applications using it, including impacting traffic engineering, which
uses various link attributes for its path computation. As the uses various link attributes for its path computation. As the
advertisements defined in this document limit the scope to specific advertisements defined in this document limit the scope to specific
applications, the impact of tampering is similarly limited in scope. The applications, the impact of tampering is similarly limited in scope. The
advertisement of the link attribute information defined in this document advertisement of the link attribute information defined in this document
presents no significant additional risk beyond that associated with the presents no significant additional risk beyond that associated with the
existing link attribute information already supported in <xref existing link attribute information already supported in <xref target="RFC
target="RFC7752"/>.</t> 7752" format="default"/>.</t>
</section>
<section anchor="ACK" title="Acknowledgements">
<t>The authors would like to thank Les Ginsberg, Baalajee S, Amalesh
Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, Kristy
Paine, and Shraddha Hegde for their review and feedback on this
document. The authors would like to thank Alvaro Retana for his very
detailed AD review and comments for improving this document. The authors
would also like to thank John Scudder for his detailed review and
feedback on clarifying the procedures along with the example in <xref
target="PROCEDURES"/>.</t>
</section> </section>
</middle> </middle>
<back> <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"?> <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
<?rfc include="reference.RFC.3209"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
752.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
919.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
920.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
571.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
104.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 /></au
thor>
<date year='1990' month='December' />
<abstract><t>This memo specifies an integrated routing protocol, based on the OS
I 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 p
rotocol to be used to support pure IP environments, pure OSI environments, and d
ual environments. This specification was developed by the IS-IS working group o
f the Internet Engineering Task Force. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1195'/>
<seriesInfo name='DOI' value='10.17487/RFC1195'/>
</reference>
<?rfc include='reference.RFC.8402'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
202.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<?rfc include='reference.I-D.ietf-idr-bgp-model'?> <!-- [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> </references>
<section anchor="ACK" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Les Ginsberg"/>, <co
ntact fullname="Baalajee S."/>, <contact fullname="Amalesh
Maity"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Keyur Pate
l"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Rudy Selderslaghs"/
>, <contact fullname="Kristy
Paine"/>, and <contact fullname="Shraddha Hegde"/> for their review and fe
edback on this
document. The authors would like to thank <contact fullname="Alvaro Retana
"/> for his very
detailed AD review and comments that improved this document. The authors
would also like to thank <contact fullname="John Scudder"/> for his detail
ed review and
feedback on clarifying the procedures along with the example in <xref targ
et="PROCEDURES" format="default"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 119 change blocks. 
435 lines changed or deleted 465 lines changed or added

This html diff was produced by rfcdiff 1.48.