<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-idr-bgp-ls-app-specific-attr-16" indexInclude="true" ipr="trust200902" number="9294" prepTime="2022-08-19T22:17:32" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-app-specific-attr-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9294" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="App-Specific Link Attributes Using BGP-LS">Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP‑LS)</title>
    <seriesInfo name="RFC" value="9294" stream="IETF"/>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization showOnFrontPage="true">Arrcus 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 showOnFrontPage="true">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 showOnFrontPage="true">Microsoft</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <date month="08" year="2022"/>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 Segment Routing (SR). This document
      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
      from the network.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9294" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-link-a">Application-Specific Link Attributes TLV</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-link-att">Application-Specific Link Attributes</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-procedures">Procedures</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-illustration-for-is-is">Illustration for IS-IS</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-considerations">Deployment Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="INTRO" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> enables the distribution of
      the link-state topology information from link-state routing protocols
      (viz., IS-IS <xref target="RFC1195" format="default" sectionFormat="of" derivedContent="RFC1195"/>, OSPFv2 <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>,
      and OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>) to an application like 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
      path computations for use cases like end-to-end traffic engineering
      (TE).</t>
      <t indent="0" pn="section-1-2">The link-state topology information distributed via BGP-LS includes
      link attributes that were originally defined for MPLS TE (i.e., using RSVP-TE <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/> or GMPLS <xref target="RFC4202" format="default" sectionFormat="of" derivedContent="RFC4202"/> applications). In recent years, applications,
      such as Segment Routing (SR) Policy <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> and
      Loop-Free Alternates (LFA) <xref target="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/>, which also make use
      of link attributes, have been introduced. <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and
      <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> 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
      the need for a similar BGP-LS extension to include this additional
      link-state topology information from the link-state routing
      protocols.</t>
      <t indent="0" pn="section-1-3">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-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>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
	  The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
	  described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
	  when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="ASLATLV" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-application-specific-link-a">Application-Specific Link Attributes TLV</name>
      <t indent="0" pn="section-2-1">BGP-LS <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> specifies the Link Network Layer
      Reachability Information (NLRI) for the advertisement of links and their
      attributes using the BGP-LS Attribute. The 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 indent="0" pn="section-2-2">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 target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> and <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/>, respectively.</t>
      <figure anchor="ASLA-TLV" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-application-specific-link-at">Application-Specific Link Attributes TLV</name>
        <artwork align="center" name="" type="" alt="" pn="section-2-3.1">    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                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <t indent="0" pn="section-2-4">where:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-5">
        <dt pn="section-2-5.1">Type:</dt>
        <dd pn="section-2-5.2">1122</dd>
        <dt pn="section-2-5.3">Length:</dt>
        <dd pn="section-2-5.4">variable</dd>
        <dt pn="section-2-5.5">SABM Length:</dt>
        <dd pn="section-2-5.6">1-octet field that carries the Standard Application
          Identifier Bit Mask Length in octets as defined in <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>.</dd>
        <dt pn="section-2-5.7">UDABM Length:</dt>
        <dd pn="section-2-5.8">1-octet field that carries the User-Defined
          Application Identifier Bit Mask Length in octets as defined in <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>.</dd>
        <dt pn="section-2-5.9">Reserved:</dt>
        <dd pn="section-2-5.10">2-octet field that <bcp14>MUST</bcp14> be set to zero on transmission
          and <bcp14>MUST</bcp14> be ignored on reception.</dd>
        <dt pn="section-2-5.11">Standard Application Identifier Bit Mask:</dt>
        <dd pn="section-2-5.12">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 <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/>.</dd>
        <dt pn="section-2-5.13">User-Defined Application Identifier Bit Mask:</dt>
        <dd pn="section-2-5.14">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 <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>.</dd>
        <dt pn="section-2-5.15">Link Attribute sub-TLVs:</dt>
        <dd pn="section-2-5.16">BGP-LS Attribute TLVs corresponding to
          the Link NLRI that are application-specific (including existing ones
          as specified in <xref target="APPSPECATTRS" format="default" sectionFormat="of" derivedContent="Section 3"/>) are included as
          sub-TLVs of the ASLA TLV.</dd>
      </dl>
      <t indent="0" pn="section-2-6">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 <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>.</t>
      <t indent="0" pn="section-2-7">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 attribute TLVs and sub-TLVs. The procedures for
      originating link attributes in the ASLA TLV from underlying IGPs are
      specified in <xref target="PROCEDURES" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
    </section>
    <section anchor="APPSPECATTRS" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-application-specific-link-att">Application-Specific Link Attributes</name>
      <t indent="0" pn="section-3-1">Several BGP-LS Attribute TLVs corresponding to the Link NLRI are
      defined in BGP-LS <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>, and more may 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>
      <t indent="0" pn="section-3-2">The following table lists the currently defined BGP-LS Attribute
      TLVs corresponding to Link NLRI that can have application-specific
      semantics based on the underlying IGP specifications <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>. These were originally
      defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by
      the respective reference documents.</t>
      <table anchor="APPSPECATTR" align="center" pn="table-1">
        <name slugifiedName="name-existing-bgp-ls-tlvs-identi">Existing BGP-LS TLVs Identified as Application-Specific</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">TLV Code Point</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference Document</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">1088</td>
            <td align="left" colspan="1" rowspan="1">Administrative group (color)</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1092</td>
            <td align="left" colspan="1" rowspan="1">TE Default Metric</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1096</td>
            <td align="left" colspan="1" rowspan="1">Shared Risk Link Group</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1114</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Link Delay</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1115</td>
            <td align="left" colspan="1" rowspan="1">Min/Max Unidirectional Link Delay</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1116</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Delay Variation</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1117</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Link Loss</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1118</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Residual Bandwidth</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1119</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Available Bandwidth</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1120</td>
            <td align="left" colspan="1" rowspan="1">Unidirectional Utilized Bandwidth</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/></td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1173</td>
            <td align="left" colspan="1" rowspan="1">Extended Administrative Group</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9104" format="default" sectionFormat="of" derivedContent="RFC9104"/></td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-3-4">All the BGP-LS Attribute TLVs listed in the table above are <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 indent="0" pn="section-3-5">BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised
      in the underlying IGP as application-specific are <bcp14>REQUIRED</bcp14> to be encoded
      within an ASLA TLV.</t>
      <t indent="0" pn="section-3-6">Link attributes that do not have application-specific semantics <bcp14>MUST NOT</bcp14> be advertised within the ASLA TLV.</t>
      <t indent="0" pn="section-3-7">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" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-procedures">Procedures</name>
      <t indent="0" pn="section-4-1">The BGP-LS originator learns of the association of an
      application-specific attribute to one or more applications from the
      underlying IGP protocol Link State Advertisements (LSAs) or Link State Packets (LSPs) from which it is advertising the
      topology information. <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> and <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> specify the mechanisms for advertising
      application-specific link attributes in OSPF and IS-IS, respectively.</t>
      <t indent="0" pn="section-4-2">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 <xref target="APPSPECATTR" format="default" sectionFormat="of" derivedContent="Table 1"/>
      as specified in their respective reference documents.</t>
      <t indent="0" pn="section-4-3">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-Specific Shared Risk Link Group (SRLG) TLV) <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and to carry them together in the BGP-LS ASLA
      TLV.</t>
      <t indent="0" pn="section-4-4">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 following rules:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-5"><li pn="section-4-5.1" derivedCounter="1.">Application-specific link attributes received from an OSPF node
          using an ASLA sub-TLV or from an IS-IS node using either an ASLA sub-TLV
          or an Application-Specific SRLG TLV <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.</li>
        <li pn="section-4-5.2" derivedCounter="2.">
          <t indent="0" pn="section-4-5.2.1">In the case of IS-IS, the specific procedures below are to be
          followed:</t>
          <ol spacing="normal" type="A" indent="adaptive" start="1" pn="section-4-5.2.2"><li pn="section-4-5.2.2.1" derivedCounter="A.">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 bits (other than RSVP-TE) are set in the application
              bit masks, then the application-specific link attributes
              advertised in the corresponding legacy IS-IS TLVs and sub-TLVs <bcp14>MUST</bcp14>
              be encoded within the BGP-LS ASLA TLV as sub-TLVs with 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 TLVs and sub-TLVs are also advertised in BGP-LS top-level TLVs
              as per <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>, <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, and <xref target="RFC9104" format="default" sectionFormat="of" derivedContent="RFC9104"/>. The same procedure also applies for the
              advertisement of the SRLG values from the IS-IS
              Application-Specific SRLG TLV.</li>
            <li pn="section-4-5.2.2.2" derivedCounter="B.">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-TLVs <bcp14>MUST</bcp14> be encoded using the respective BGP-LS top-level
              TLVs as per <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>, <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, and
              <xref target="RFC9104" format="default" sectionFormat="of" derivedContent="RFC9104"/>. Similarly, when the IS-IS
              Application-Specific SRLG TLV has the RSVP-TE application bit
              set, then the SRLG values within it <bcp14>MUST</bcp14> be encoded using the
              top-level BGP-LS SRLG TLV (1096) as per <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.</li>
            <li pn="section-4-5.2.2.3" derivedCounter="C.">
              <t indent="0" pn="section-4-5.2.2.3.1">The SRLGs advertised in one or more IS-IS Application-Specific 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-application
              basis, only for those applications that meet all the following
              criteria:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5.2.2.3.2">
                <li pn="section-4-5.2.2.3.2.1">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>
                <li pn="section-4-5.2.2.3.2.2">the other encoding type (e.g., IS-IS Application Specific
                  SRLG TLV) has an advertisement with zero-length application
                  bit masks</li>
                <li pn="section-4-5.2.2.3.2.3">there is no corresponding advertisement of that other
                  encoding type (following the example, IS-IS Application
                  Specific SRLG TLV) with that specific application bit
                  set</li>
              </ul>
              <t indent="0" pn="section-4-5.2.2.3.3">For each such application, its collated information
              <bcp14>MUST</bcp14> be carried in a BGP-LS ASLA TLV with that application's bit
              set in the SABM or UDABM. See the illustration in <xref target="EXAMPLE" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</t>
            </li>
            <li pn="section-4-5.2.2.4" derivedCounter="D.">If the resulting set of collated link attributes and SRLG
              values is common across multiple applications, they <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 bit
              mask.</li>
            <li pn="section-4-5.2.2.5" derivedCounter="E.">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, <bcp14>MUST</bcp14> be advertised into a
              BGP-LS ASLA TLV with a zero-length application bit mask,
              independent of the collation described above.</li>
            <li pn="section-4-5.2.2.6" derivedCounter="F.">
              <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> 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
              attribute <bcp14>MUST</bcp14> be encoded only in the top-level BGP-LS Maximum
              Link Bandwidth TLV (1089) and <bcp14>MUST NOT</bcp14> be advertised within the
              BGP-LS ASLA TLV.</li>
            <li pn="section-4-5.2.2.7" derivedCounter="G.">
              <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> 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 attributes <bcp14>MUST</bcp14> be encoded only in the BGP-LS
              top-level Maximum Reservable Link Bandwidth TLV (1090) and
              Unreserved Bandwidth TLV (1091), respectively, and not within the
              BGP-LS ASLA TLV.</li>
          </ol>
        </li>
      </ol>
      <t indent="0" pn="section-4-6">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 indent="0" pn="section-4-7">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" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-illustration-for-is-is">Illustration for IS-IS</name>
        <t indent="0" pn="section-4.1-1">This section illustrates the procedure for the advertisement of
        application-specific link attributes from IS-IS into BGP-LS.</t>
        <t indent="0" pn="section-4.1-2">Consider the following advertisements for a link in IS-IS. We start
        with this set:</t>
        <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-4.1-3"><li pn="section-4.1-3.1" derivedCounter="a.">IS-IS ASLA sub-TLV with the S, F, and X bits set on it that carries
            certain application-specific link attributes</li>
          <li pn="section-4.1-3.2" derivedCounter="b.">IS-IS Application-Specific SRLG TLV with zero-length bit
            masks with a set of application-specific SRLGs</li>
          <li pn="section-4.1-3.3" derivedCounter="c.">IS-IS Application-Specific SRLG TLV with the X bit set on it
            with a set of application-specific SRLGs</li>
        </ol>
        <t indent="0" pn="section-4.1-4">The corresponding BGP-LS advertisements for that link are
        determined as follows:</t>
        <t indent="0" pn="section-4.1-5">First, based on rule (1), the advertisements are conveyed to BGP-LS
        to get the following "updated set":</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-6"><li pn="section-4.1-6.1" derivedCounter="1.">ASLA with the S, F, and X bits set on it that carries link attributes
            from IS-IS advertisement (a)</li>
          <li pn="section-4.1-6.2" derivedCounter="2.">ASLA SRLG with zero-length bit masks with a set of SRLGs from
            IS-IS advertisement (b)</li>
          <li pn="section-4.1-6.3" derivedCounter="3.">ASLA SRLG with the X bit set on it with a set of SRLGs from
            IS-IS advertisement (c)</li>
        </ol>
        <t indent="0" pn="section-4.1-7">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 indent="0" pn="section-4.1-8">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
        following "final set":</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-9"><li pn="section-4.1-9.1" derivedCounter="1.">ASLA with the S bit set on it that 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))</li>
          <li pn="section-4.1-9.2" derivedCounter="2.">ASLA with the F bit set on it that 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))</li>
          <li pn="section-4.1-9.3" derivedCounter="3.">ASLA with the X bit set on it that carries link attributes from
            IS-IS advertisement (a) (remaining application not affected by
            collation based on (2)(c))</li>
          <li pn="section-4.1-9.4" derivedCounter="4.">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 "updated set")</li>
          <li pn="section-4.1-9.5" derivedCounter="5.">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 "updated set")</li>
        </ol>
        <t indent="0" pn="section-4.1-10">Implementations may optionally perform further consolidation by
        processing the "final set" above based on (2)(d) to determine the
        following "consolidated final set":</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-11"><li pn="section-4.1-11.1" derivedCounter="1.">ASLA with the S and F bits set on it that 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))</li>
          <li pn="section-4.1-11.2" derivedCounter="2.">ASLA with the X bit set on it that carries certain
            application-specific link attributes from IS-IS advertisement (a)
            (it is unaffected by this consolidation)</li>
          <li pn="section-4.1-11.3" derivedCounter="3.">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 further
            consolidation)</li>
          <li pn="section-4.1-11.4" derivedCounter="4.">ASLA with the X bit set on it with a set of
            application-specific SRLGs from IS-IS advertisement (c) (it is
            unaffected by this consolidation)</li>
        </ol>
        <t indent="0" pn="section-4.1-12">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" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-deployment-considerations">Deployment Considerations</name>
      <t indent="0" pn="section-5-1">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 <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> and <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/>. The IGP backward-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 <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>, <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, and <xref target="RFC9104" format="default" sectionFormat="of" derivedContent="RFC9104"/> for applications such as
      RSVP-TE, SR Policy, and LFA.</t>
      <t indent="0" pn="section-5-2">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 indent="0" pn="section-5-3">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. 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" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA has assigned a
      code point from the "BGP-LS Node Descriptor, Link Descriptor,
      Prefix Descriptor, and Attribute TLVs" registry as described in the following table. There is no "IS-IS TLV/Sub-TLV" value for this entry.</t>
      <table anchor="code-point" align="center" pn="table-2">
        <name slugifiedName="name-asla-tlv-code-point-allocat">ASLA TLV Code Point Allocation</name>
        <thead>
          <tr>
            <th rowspan="1" colspan="1" align="left">TLV Code Point</th>
            <th rowspan="1" colspan="1" align="left">Description</th>
            <th rowspan="1" colspan="1" align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">1122</td>
            <td align="left" colspan="1" rowspan="1">Application-Specific Link Attributes</td>
            <td align="left" colspan="1" rowspan="1">RFC 9294</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Manageability" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-7-1">The protocol extensions introduced in this document augment the
      existing IGP topology information defined in <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.
      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 <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Specifically, the malformed NLRI attribute tests in
      the Fault Management section of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> now encompass
      the BGP-LS TLVs defined in this document.</t>
      <t indent="0" pn="section-7-2">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 <xref target="I-D.ietf-idr-bgp-model" format="default" sectionFormat="of" derivedContent="IDR-BGP-MODEL"/>.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">Security considerations for acquiring and distributing BGP-LS
      information are discussed in <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Specifically, the
      considerations related to topology information, which are related to traffic engineering, apply.</t>
      <t indent="0" pn="section-8-2">The TLVs introduced in this document are used to propagate the
      application-specific link attributes IGP extensions defined in <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>. It is assumed that the
      IGP instances originating these TLVs will support all the required
      security (as described in <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and <xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/>).</t>
      <t indent="0" pn="section-8-3">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 <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S" surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7752" target="https://www.rfc-editor.org/info/rfc7752" quoteTitle="true" derivedAnchor="RFC7752">
          <front>
            <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
            <author fullname="H. Gredler" initials="H" role="editor" surname="Gredler"/>
            <author fullname="J. Medved" initials="J" surname="Medved"/>
            <author fullname="S. Previdi" initials="S" surname="Previdi"/>
            <author fullname="A. Farrel" initials="A" surname="Farrel"/>
            <author fullname="S. Ray" initials="S" surname="Ray"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</t>
              <t indent="0">This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.</t>
              <t indent="0">Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7752"/>
          <seriesInfo name="DOI" value="10.17487/RFC7752"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B" surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8571" target="https://www.rfc-editor.org/info/rfc8571" quoteTitle="true" derivedAnchor="RFC8571">
          <front>
            <title>BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L" role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S" surname="Previdi"/>
            <author fullname="Q. Wu" initials="Q" surname="Wu"/>
            <author fullname="J. Tantsura" initials="J" surname="Tantsura"/>
            <author fullname="C. Filsfils" initials="C" surname="Filsfils"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8571"/>
          <seriesInfo name="DOI" value="10.17487/RFC8571"/>
        </reference>
        <reference anchor="RFC8919" target="https://www.rfc-editor.org/info/rfc8919" quoteTitle="true" derivedAnchor="RFC8919">
          <front>
            <title>IS-IS Application-Specific Link Attributes</title>
            <author fullname="L. Ginsberg" initials="L" surname="Ginsberg"/>
            <author fullname="P. Psenak" initials="P" surname="Psenak"/>
            <author fullname="S. Previdi" initials="S" surname="Previdi"/>
            <author fullname="W. Henderickx" initials="W" surname="Henderickx"/>
            <author fullname="J. Drake" initials="J" surname="Drake"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8919"/>
          <seriesInfo name="DOI" value="10.17487/RFC8919"/>
        </reference>
        <reference anchor="RFC8920" target="https://www.rfc-editor.org/info/rfc8920" quoteTitle="true" derivedAnchor="RFC8920">
          <front>
            <title>OSPF Application-Specific Link Attributes</title>
            <author fullname="P. Psenak" initials="P" role="editor" surname="Psenak"/>
            <author fullname="L. Ginsberg" initials="L" surname="Ginsberg"/>
            <author fullname="W. Henderickx" initials="W" surname="Henderickx"/>
            <author fullname="J. Tantsura" initials="J" surname="Tantsura"/>
            <author fullname="J. Drake" initials="J" surname="Drake"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8920"/>
          <seriesInfo name="DOI" value="10.17487/RFC8920"/>
        </reference>
        <reference anchor="RFC9104" target="https://www.rfc-editor.org/info/rfc9104" quoteTitle="true" derivedAnchor="RFC9104">
          <front>
            <title>Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)</title>
            <author fullname="J. Tantsura" initials="J" surname="Tantsura"/>
            <author fullname="Z. Wang" initials="Z" surname="Wang"/>
            <author fullname="Q. Wu" initials="Q" surname="Wu"/>
            <author fullname="K. Talaulikar" initials="K" surname="Talaulikar"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">Administrative groups are link attributes used for traffic engineering.  This document defines an extension to the Border Gateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9104"/>
          <seriesInfo name="DOI" value="10.17487/RFC9104"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-idr-bgp-model" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14" derivedAnchor="IDR-BGP-MODEL">
          <front>
            <title>BGP YANG Model for Service Provider Networks</title>
            <author fullname="Mahesh Jethanandani">
              <organization showOnFrontPage="true">Kloud Services</organization>
            </author>
            <author fullname="Keyur Patel">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author fullname="Susan Hares">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author fullname="Jeffrey Haas">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date month="July" day="3" year="2022"/>
            <abstract>
              <t indent="0">   This document defines a YANG data model for configuring and managing
   BGP, including protocol, policy, and operational aspects, such as
   RIB, based on data center, carrier, and content provider operational
   requirements.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-model-14"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-14.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC1195" target="https://www.rfc-editor.org/info/rfc1195" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true"/>
            </author>
            <date year="1990" month="December"/>
            <abstract>
              <t indent="0">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>
        <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328">
          <front>
            <title>OSPF Version 2</title>
            <author fullname="J. Moy" initials="J" surname="Moy"/>
            <date month="April" year="1998"/>
            <abstract>
              <t indent="0">This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="54"/>
          <seriesInfo name="RFC" value="2328"/>
          <seriesInfo name="DOI" value="10.17487/RFC2328"/>
        </reference>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D" surname="Awduche"/>
            <author fullname="L. Berger" initials="L" surname="Berger"/>
            <author fullname="D. Gan" initials="D" surname="Gan"/>
            <author fullname="T. Li" initials="T" surname="Li"/>
            <author fullname="V. Srinivasan" initials="V" surname="Srinivasan"/>
            <author fullname="G. Swallow" initials="G" surname="Swallow"/>
            <date month="December" year="2001"/>
            <abstract>
              <t indent="0">This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202" quoteTitle="true" derivedAnchor="RFC4202">
          <front>
            <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author fullname="K. Kompella" initials="K" role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y" role="editor" surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS).  This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4202"/>
          <seriesInfo name="DOI" value="10.17487/RFC4202"/>
        </reference>
        <reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5286" quoteTitle="true" derivedAnchor="RFC5286">
          <front>
            <title>Basic Specification for IP Fast Reroute: Loop-Free Alternates</title>
            <author fullname="A. Atlas" initials="A" role="editor" surname="Atlas"/>
            <author fullname="A. Zinin" initials="A" role="editor" surname="Zinin"/>
            <date month="September" year="2008"/>
            <abstract>
              <t indent="0">This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG).  The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure.  Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.  This simple approach does not require any support from other routers.  The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5286"/>
          <seriesInfo name="DOI" value="10.17487/RFC5286"/>
        </reference>
        <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340" quoteTitle="true" derivedAnchor="RFC5340">
          <front>
            <title>OSPF for IPv6</title>
            <author fullname="R. Coltun" initials="R" surname="Coltun"/>
            <author fullname="D. Ferguson" initials="D" surname="Ferguson"/>
            <author fullname="J. Moy" initials="J" surname="Moy"/>
            <author fullname="A. Lindem" initials="A" surname="Lindem"/>
            <date month="July" year="2008"/>
            <abstract>
              <t indent="0">This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
              <t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</t>
              <t indent="0">Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.</t>
              <t indent="0">All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5340"/>
          <seriesInfo name="DOI" value="10.17487/RFC5340"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C" role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S" role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L" surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B" surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S" surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R" surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
      </references>
    </references>
    <section anchor="ACK" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <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 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 detailed review and
      feedback on clarifying the procedures along with the example in <xref target="PROCEDURES" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
        <organization showOnFrontPage="true">Arrcus 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 showOnFrontPage="true">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 showOnFrontPage="true">Microsoft</organization>
        <address>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
