<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF"
category="std" consensus="true" docName="draft-ietf-lsr-rfc8919bis-04" indexInclude="true" number="9479"
ipr="trust200902" updates="" obsoletes="8919" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3"
tocInclude="true" xml:lang="en">

  <front>
    <title abbrev="IS-IS App-Specific Link Attributes">IS-IS Application-Specific Link Attributes</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-rfc8919bis-04" stream="IETF"/> name="RFC" value="9479"/>
    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
      <organization showOnFrontPage="true">Cisco
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>ginsberg@cisco.com</email>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P" surname="Psenak">
      <organization showOnFrontPage="true">Cisco
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Stefano Previdi" initials="S" surname="Previdi">
      <organization showOnFrontPage="true">Huawei
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <country/>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
      <organization showOnFrontPage="true">Nokia</organization>
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>Copernicuslaan 50</street>
          <city>Antwerp</city>
          <code>2018 94089</code>
          <country>Belgium</country>
        </postal>
        <email>wim.henderickx@nokia.com</email>
      </address>
    </author>
    <author fullname="John Drake" initials="J" surname="Drake">
      <organization showOnFrontPage="true">Juniper
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <code/>
          <country/>
        </postal>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <date year="2023"/>
    <area>Routing Area</area>
    <workgroup>Networking Working Group</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Existing year="2023" month="October"/>
    <area>rtg</area>
    <workgroup>lsr</workgroup>

    <abstract>
      <t>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 an 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>
      <t indent="0" pn="section-abstract-2">This
      <t>This document obsoletes RFC 8919.</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/rfc8919" 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) 2020 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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-requirements-discussion">Requirements Discussion</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-legacy-advertisements">Legacy Advertisements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-legacy-sub-tlvs">Legacy Sub-TLVs</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-legacy-srlg-advertisements">Legacy SRLG Advertisements</xref></t>
              </li>
            </ul>
          </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-advertising-application-spe">Advertising Application-Specific Link Attributes</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-application-identifier-bit-">Application Identifier Bit Mask</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-link-a">Application-Specific Link Attributes Sub-TLV</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-special-considerations-for-">Special Considerations for Maximum Link Bandwidth</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-special-considerations-for-r">Special Considerations for Reservable/Unreserved Bandwidth</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-extended">Considerations for Extended TE Metrics</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-srlg-t">Application-Specific SRLG TLV</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-attribute-advertisements-an">Attribute Advertisements and Enablement</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-deployment-considerations">Deployment Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-legacy-advertisement">Use of Legacy Advertisements</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-zero-length-applicat">Use of Zero-Length Application Identifier Bit Masks</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interoperability-backwards-">Interoperability, Backwards Compatibility, and Migration Concerns</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2">
                  <li pn="section-toc.1-1.6.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derivedContent="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-applications-commo">Multiple Applications: Common Attributes with RSVP-TE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derivedContent="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-applications-all-a">Multiple Applications: All Attributes Not Shared with RSVP-TE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.3.1"><xref derivedContent="6.3.3" format="counter" sectionFormat="of" target="section-6.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interoperability-with-legac">Interoperability with Legacy Routers</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.4.1"><xref derivedContent="6.3.4" format="counter" sectionFormat="of" target="section-6.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-application-specific">Use of Application-Specific Advertisements for RSVP-TE</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </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-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-link-at">Application-Specific Link Attributes Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-srlg-tl">Application-Specific SRLG TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sub-sub-tlv-codepoints-for-">Sub-sub-TLV Codepoints for Application-Specific Link Attributes Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-link-attribute-application-">Link Attribute Application Identifiers Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sub-tlvs-for-tlv-238-regist">Sub-TLVs for TLV 238 Registry</xref></t>
              </li>
            </ul>
          </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-10.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-10.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 numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"> NOTE: This document makes modest editorial
      changes to the content of RFC 8919 which it obsoletes. A detailed description
      of the changes is provided in <xref target="changes-to-rfc8919" format="default" sectionFormat="of" derivedContent="Section 9"/>.
      This note was added for the benefit of IESG reviewers and SHOULD be
      removed by the RFC Editor prior to publication.</t>
      <t indent="0" pn="section-1-2">Advertisement
    <section>
      <name>Introduction</name>
      <t>Advertisement of link attributes by the
      Intermediate System to Intermediate System (IS-IS) protocol in support
      of traffic engineering Traffic Engineering (TE) was introduced by <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/> target="RFC5305"/> and extended by
      <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/>, <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/>, <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/>, and <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>. Use target="RFC5307"/>, <xref target="RFC6119"/>, <xref target="RFC7308"/>, and <xref target="RFC8570"/>. The use of these extensions
      has been associated with deployments supporting Traffic Engineering TE over
      Multiprotocol Label Switching (MPLS) in the presence of the Resource
      Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE
      <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>.</t>
      <t indent="0" pn="section-1-3">For target="RFC3209"/>.</t>
      <t>For the purposes of this document, an application is a technology that
      makes use of link attribute advertisements, examples of which are
      listed in <xref target="LEGADV" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      <t indent="0" pn="section-1-4">In target="LEGADV"/>.</t>
      <t>In recent years, new applications that have use cases for many of the
      link attributes historically used by RSVP-TE have been introduced. Such
      applications include Segment Routing (SR) Policy <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="SEGMENT-ROUTING"/> target="RFC9256"/> and Loop-Free
      Alternates (LFAs) <xref target="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/>. target="RFC5286"/>. This has introduced ambiguity
      in that if a deployment includes a mix of RSVP-TE support and SR Policy
      support, for example, it is not possible to unambiguously indicate which
      advertisements are to be used by RSVP-TE and which advertisements are to
      be used by SR Policy. If the topologies are fully congruent, this may not
      be an issue, but any incongruence leads to ambiguity.</t>
      <t indent="0" pn="section-1-5">An
      <t>An example of where this ambiguity causes a problem is a network where
      RSVP-TE is enabled only on a subset of its links. A link attribute is
      advertised for the purpose of another application (e.g., SR Policy) for a
      link that is not enabled for RSVP-TE. As soon as the router that is an
      RSVP-TE head end sees the link attribute being advertised for that link,
      it assumes that RSVP-TE is enabled on that link, even though it is not. If
      such an RSVP-TE head-end router tries to set up an RSVP-TE path via that
      link, it will result in a path setup failure.</t>
      <t indent="0" pn="section-1-6">An failure for the path.</t>
      <t>An additional issue arises in cases where both applications are
      supported on a link but the link attribute values associated with each
      application differ. Current advertisements do not support advertising
      application-specific values for the same attribute on a specific
      link.</t>
      <t indent="0" pn="section-1-7">This
      <t>This document defines extensions that address these issues. Also, as
      evolution of use cases for link attributes can be expected to continue
      in the years to come, this document defines a solution that is easily
      extensible to the introduction of new applications and new use
      cases.</t>
      <section anchor="req-lang" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements anchor="req-lang">
        <name>Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    The
        <t>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 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.
        </t> here.</t>
      </section>
    </section>
    <section anchor="REQDIS" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-discussion">Requirements anchor="REQDIS">
      <name>Requirements Discussion</name>
      <t indent="0" pn="section-2-1">As
      <t>As stated previously, evolution of use cases for link attributes can
      be expected to continue. Therefore, any discussion of existing use cases
      is limited to requirements that are known at the time of this writing.
      However, in order to determine the functionality required beyond what
      already exists in IS-IS, it is only necessary to discuss use cases that
      justify the key points identified in the introduction, Introduction, which are:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-2">
        <li pn="section-2-2.1" derivedCounter="1.">Support
      <ol>
        <li>Support for indicating which applications are using the link
          attribute advertisements on a link</li>
        <li pn="section-2-2.2" derivedCounter="2.">Support link.</li>
        <li>Support for advertising application-specific values for the same
          attribute on a link</li> link.</li>
      </ol>
      <t indent="0" pn="section-2-3"><xref target="RFC7855" format="default" sectionFormat="of" derivedContent="RFC7855"/>
      <t><xref target="RFC7855"/> discusses use cases and requirements for Segment Routing
      (SR). SR. Included among these use cases is SR Policy, which is defined in
      <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="SEGMENT-ROUTING"/>. target="RFC9256"/>. If both RSVP-TE
      and SR Policy are deployed in a network, link attribute advertisements
      can be used by one or both of these applications.
There is no requirement for the link attributes advertised on a given link
used by SR Policy to be identical to the link attributes advertised on that
same link used by RSVP-TE; thus, there is a clear requirement to indicate
independently which link attribute advertisements are to be used by each
application.</t>
      <t indent="0" pn="section-2-4">As
      <t>As the number of applications that may wish to utilize link
      attributes may grow in the future, an additional requirement is that the
      extensions defined allow the association of additional applications to
      link attributes without altering the format of the advertisements or
      introducing new backwards-compatibility issues.</t>
      <t indent="0" pn="section-2-5">Finally,
      <t>Finally, there may still be many cases where a single attribute value
      can be shared among multiple applications, so the solution must minimize
      advertising duplicate link/attribute pairs whenever possible.</t>
    </section>
    <section anchor="LEGADV" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-legacy-advertisements">Legacy anchor="LEGADV">
      <name>Legacy Advertisements</name>
      <t indent="0" pn="section-3-1">Existing
      <t>Existing advertisements used in support of RSVP-TE include sub-TLVs for
      TLVs Advertising Neighbor Information and TLVs for Shared Risk Link Group (SRLG) advertisement.</t>
      <t indent="0" pn="section-3-2">Sub-TLV advertisements.</t>
      <t>Sub-TLV values are defined in the "IS-IS sub-TLVs Sub-TLVs for TLVs Advertising Neighbor Information" registry.</t>
      <t indent="0" pn="section-3-3">TLVs
      <t>TLVs are defined in the "TLV Codepoints Registry".</t> "IS-IS TLV Codepoints" registry.</t>
      <section anchor="LEGSUB" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-legacy-sub-tlvs">Legacy anchor="LEGSUB">
        <name>Legacy Sub-TLVs</name>
        <table anchor="legacysub" align="left" pn="table-1">
          <name slugifiedName="name-sub-tlvs-for-tlvs-22-23-25-">Sub-TLVs for TLVs Advertising Neighbor Information</name> anchor="legacysub">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">
              <th> Type </th>
              <th align="left" colspan="1" rowspan="1">
              <th> Description </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 3 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Administrative group (color) </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 9 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Maximum link bandwidth</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 10 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Maximum reservable link bandwidth </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 11 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unreserved bandwidth </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 14 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Extended Administrative Group </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 18 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> TE Default Metric metric </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 33 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Link Delay </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 34 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>  Min/Max Unidirectional Link Delay </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 35 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Delay Variation </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 36 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Link Loss </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 37 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Residual Bandwidth </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 38 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Available Bandwidth</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 39 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>  Unidirectional Utilized Bandwidth </td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="LEGSRLG" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-legacy-srlg-advertisements">Legacy anchor="LEGSRLG">
        <name>Legacy SRLG Advertisements</name>
        <dl newline="true" indent="3" spacing="normal" pn="section-3.2-1">
          <dt pn="section-3.2-1.1">TLV newline="true">
          <dt>TLV 138 (GMPLS-SRLG):</dt>
          <dd pn="section-3.2-1.2">Supports
          <dd>Supports links identified by IPv4 addresses and
  unnumbered links.</dd>
          <dt pn="section-3.2-1.3">TLV
          <dt>TLV 139 (IPv6 SRLG):</dt>
          <dd pn="section-3.2-1.4">
          <dd> Supports links identified by IPv6 addresses.</dd>
        </dl>
        <t indent="0" pn="section-3.2-2">Note
        <t>Note that <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/> target="RFC6119"/> prohibits the
        use of TLV 139 when it is possible to use TLV 138.</t>
      </section>
    </section>
    <section anchor="ASLA" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-advertising-application-spe">Advertising anchor="ASLA">
      <name>Advertising Application-Specific Link Attributes</name>
      <t indent="0" pn="section-4-1">Two new
      <t>Two codepoints are defined to support Application-Specific
      Link Attribute (ASLA) advertisements:</t>
      <ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="section-4-2">
      <li pn="section-4-2.1" derivedCounter="1)">Application-Specific
      <ol>
      <li>Application-Specific Link Attributes sub-TLV for TLVs Advertising Neighbor Information (defined in <xref target="ASLASUB" format="default" sectionFormat="of" derivedContent="Section 4.2"/>).</li>
        <li pn="section-4-2.2" derivedCounter="2)">Application-Specific Shared Risk Link Group (SRLG) target="ASLASUB"/>).</li>
        <li>Application-Specific SRLG TLV (defined in
      <xref target="ASSRLGTLV" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).</li> target="ASSRLGTLV"/>).</li>
      </ol>
      <t indent="0" pn="section-4-3">To
      <t>To support these new advertisements, an
      application identifier bit mask is defined to identify the application(s)
      associated with a given advertisement (defined in <xref target="AIBM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).</t>
      <t indent="0" pn="section-4-4">In target="AIBM"/>).</t>
      <t>In addition to supporting the advertisement of link attributes used
      by standardized applications, link attributes can also be advertised for
      use by user-defined applications. User-Defined Applications (UDAs). Such applications are not subject to
      standardization and are outside the scope of this document.</t>
      <t indent="0" pn="section-4-5">The
      <t>The following sections define the format of these new
      advertisements.</t>
      <section anchor="AIBM" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-application-identifier-bit-">Application anchor="AIBM">
        <name>Application Identifier Bit Mask</name>
        <t indent="0" pn="section-4.1-1">Identification
        <t>Identification of the set of applications associated with link
        attribute advertisements utilizes two bit masks. One bit mask is for
        standard applications where the definition of each bit is defined in a
        new an
        IANA-controlled registry (see <xref target="IANA4" format="default" sectionFormat="of" derivedContent="Section 7.4"/>). target="IANA4"/>). A second
        bit mask is for non-standard user-defined applications (UDAs).</t>
        <t indent="0" pn="section-4.1-2">The UDAs.</t>
        <t>The encoding defined below is used by both the Application-Specific
        Link Attributes sub-TLV and the Application-Specific SRLG TLV.</t>
        <artwork name="" type="" align="left" alt="" pn="section-4.1-3"> alt="">
          0  1  2  3  4  5  6  7
         +--+--+--+--+--+--+--+--+
         | SABM Length + Flag    |  1 octet
         +--+--+--+--+--+--+--+--+
         | UDABM Length + Flag   |  1 octet
         +--+--+--+--+--+--+--+--+
         |   SABM         ...       0 - 8       0-8 octets
         +--+--+--+--+--+--+--+--+
         |   UDABM        ...       0 - 8       0-8 octets
         +--+--+--+--+--+--+--+--+
</artwork>
        <dl newline="false" indent="3" spacing="normal" pn="section-4.1-4">
          <dt pn="section-4.1-4.1">SABM newline="true">
          <dt>SABM Length + Flag (1 octet):</dt>
          <dd pn="section-4.1-4.2">
            <t indent="0" pn="section-4.1-4.2.1">
          <dd>
            <t> Standard Application Identifier Bit Mask Length + Flag</t>
            <artwork align="left" pn="section-4.1-4.2.2">
            <artwork>
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |L| SABM Length |
         +-+-+-+-+-+-+-+-+
</artwork>
            <dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.2.3">
              <dt pn="section-4.1-4.2.3.1">L-flag:</dt>
              <dd pn="section-4.1-4.2.3.2">Legacy newline="true">
              <dt>L-flag:</dt>
              <dd>Legacy Flag.
    See <xref target="ASLASUB" format="default" sectionFormat="of" derivedContent="Section 4.2"/> target="ASLASUB"/> for a description of how
    this flag is used.</dd>
              <dt pn="section-4.1-4.2.3.3">SABM
              <dt>SABM Length:</dt>
              <dd pn="section-4.1-4.2.3.4">Indicates
              <dd>This field indicates the length in octets (0-8) of the
    Standard Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp14>
    be the minimum required to send all bits that are set.</dd>
            </dl>
          </dd>
          <dt pn="section-4.1-4.3">UDABM
          <dt>UDABM Length + Flag (1 octet):</dt>
          <dd pn="section-4.1-4.4">
            <t indent="0" pn="section-4.1-4.4.1">
          <dd>
            <t> User-Defined Application Identifier Bit Mask Length + Flag</t>
            <artwork align="left" pn="section-4.1-4.4.2">
            <artwork>
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |R| UDABM Length|
         +-+-+-+-+-+-+-+-+
</artwork>
            <dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.4.3">
              <dt pn="section-4.1-4.4.3.1">R:</dt>
              <dd pn="section-4.1-4.4.3.2"> newline="true">
              <dt>R:</dt>
              <dd> Reserved. <bcp14>SHOULD</bcp14> be transmitted as 0 and
    <bcp14>MUST</bcp14> be ignored on receipt.</dd>
              <dt pn="section-4.1-4.4.3.3">UDABM
              <dt>UDABM Length:</dt>
              <dd pn="section-4.1-4.4.3.4">
              <dd> Indicates the length in octets (0-8) of the
    User-Defined Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp14>
    be the minimum required to send all bits that are set.</dd>
            </dl>
          </dd>
          <dt pn="section-4.1-4.5">SABM
          <dt>SABM  (variable length):</dt>
          <dd pn="section-4.1-4.6">
            <t indent="0" pn="section-4.1-4.6.1">
          <dd>
            <t> Standard Application Identifier Bit Mask</t>
            <t indent="0" pn="section-4.1-4.6.2">
            <t> (SABM Length * 8) bits</t>
            <t indent="0" pn="section-4.1-4.6.3">This
            <t>This field is omitted if SABM Length is 0.</t>
            <artwork align="left" pn="section-4.1-4.6.4">
            <artwork>
          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |R|S|F|          ...
         +-+-+-+-+-+-+-+-+...
</artwork>
            <dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.6.5">
              <dt pn="section-4.1-4.6.5.1"> newline="true">
              <dt> R-bit:</dt>
              <dd pn="section-4.1-4.6.5.2">Set
              <dd>Set to specify RSVP-TE.</dd>
              <dt pn="section-4.1-4.6.5.3">
              <dt> S-bit:</dt>
              <dd pn="section-4.1-4.6.5.4">Set
              <dd>Set to specify Segment Routing SR Policy
              (this is dataplane data plane independent).</dd>
              <dt pn="section-4.1-4.6.5.5">
              <dt> F-bit:</dt>
              <dd pn="section-4.1-4.6.5.6">Set
              <dd>Set to specify Loop-Free Alternate (LFA) an LFA
     (includes all LFA types).</dd>
            </dl>
          </dd>
          <dt pn="section-4.1-4.7">UDABM
          <dt>UDABM  (variable length):</dt>
          <dd pn="section-4.1-4.8">
            <t indent="0" pn="section-4.1-4.8.1">
          <dd>
            <t> User-Defined Application Identifier Bit Mask</t>
            <t indent="0" pn="section-4.1-4.8.2">(UDABM
            <t>(UDABM Length * 8) bits</t>
            <artwork align="left" pn="section-4.1-4.8.3">
            <artwork>
          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |                ...
         +-+-+-+-+-+-+-+-+...
</artwork>
            <t indent="0" pn="section-4.1-4.8.4">
            <t> This field is omitted if UDABM Length is 0.</t>
          </dd>
        </dl>
        <aside pn="section-4.1-5">
          <t indent="0" pn="section-4.1-5.1">
        <aside>
          <t>
        Note: SABM/UDABM Length is arbitrarily limited to 8 octets
        in order to ensure that sufficient space is left to advertise link
        attributes without overrunning the maximum length of a sub-TLV.</t>
        </aside>
        <t indent="0" pn="section-4.1-6">Standard
        <t>Standard Application Identifier Bits are defined and sent starting with
        bit 0.</t>
        <t indent="0" pn="section-4.1-7">User-Defined
        <t>User-Defined Application Identifier Bits have no relationship to
        Standard Application Identifier Bits and are not managed by IANA or
        any other standards body. It is recommended that bits be used
        starting with bit 0 so as to minimize the number of octets required to
        advertise all UDAs.</t>
        <t indent="0" pn="section-4.1-8">For
        <t>For both the SABM and UDABM, the following rules apply:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-9">
          <li pn="section-4.1-9.1">Undefined
        <ul>
          <li>Undefined bits that are transmitted <bcp14>MUST</bcp14> be transmitted as 0
            and <bcp14>MUST</bcp14> be ignored on receipt.</li>
          <li pn="section-4.1-9.2">Bits
          <li>Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if they are
            set to 0 on receipt.</li>
          <li pn="section-4.1-9.3">Bits
          <li>Bits that are not supported by an implementation <bcp14>MUST</bcp14> be
            ignored on receipt.</li>
        </ul>
      </section>
      <section anchor="ASLASUB" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-application-specific-link-a">Application-Specific anchor="ASLASUB">
        <name>Application-Specific Link Attributes Sub-TLV</name>
        <t indent="0" pn="section-4.2-1">A new
        <t>A sub-TLV for TLVs Advertising Neighbor Information is defined
        that supports specification of the applications and
        application-specific attribute values.</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.2-2">
          <dt pn="section-4.2-2.1">Type:</dt>
          <dd pn="section-4.2-2.2"> newline="true">
          <dt>Type:</dt>
          <dd> 16</dd>
          <dt pn="section-4.2-2.3">Length:</dt>
          <dd pn="section-4.2-2.4">
          <dt>Length:</dt>
          <dd> Variable (1 octet)</dd>
          <dt pn="section-4.2-2.5">Value:</dt>
          <dd pn="section-4.2-2.6">
            <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.2-2.6.1">
              <li pn="section-4.2-2.6.1.1">Application
	</dl>
        <dl newline="true">
          <dt>Value:</dt>
          <dd><t>Application Identifier Bit Mask
	  (as defined in <xref target="AIBM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>)</li>
              <li pn="section-4.2-2.6.1.2"> Link target="AIBM"/>)</t>
          <t>Link Attribute sub-sub-TLVs -- format matches the
	  existing formats defined in <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>, <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/>, target="RFC5305"/>, <xref target="RFC7308"/>,
	 and <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/></li>
            </ul> target="RFC8570"/></t>
          </dd>
        </dl>
        <t indent="0" pn="section-4.2-3">If
        <t>If the SABM Length or UDABM Length in the Application Identifier Bit Mask
        is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t>
        <t indent="0" pn="section-4.2-4">When
        <t>When the SABM Length or UDABM Length is non-zero and the L-flag is NOT set, all
	applications specified in the bit mask MUST <bcp14>MUST</bcp14> use the link attribute advertisements in the sub-TLV.</t>
        <t indent="0" pn="section-4.2-5">When
        <t>When the L-flag is set in the Application Identifier Bit Mask, all
        of the applications specified in the bit mask <bcp14>MUST</bcp14> use the legacy
        advertisements for the corresponding link found in TLVs Advertising Neighbor Information. Link attribute
        sub-sub-TLVs for the corresponding link attributes <bcp14>MUST NOT</bcp14> be
        advertised for the set of applications specified in the Standard Application Identifier Bit Mask or the User-Defined
        Application Identifier Bit Masks, Mask, and all such sub-sub-TLVs <bcp14>MUST</bcp14> be
        ignored on receipt.</t>
        <t indent="0" pn="section-4.2-6">Multiple
        <t>Multiple Application-Specific Link Attributes sub-TLVs for the same
        link <bcp14>MAY</bcp14> be advertised. When multiple sub-TLVs for the same link are
        advertised, they <bcp14>SHOULD</bcp14> advertise non-conflicting
        application/attribute pairs. A conflict exists when the same
        application is associated with two different values for the same link
        attribute for a given link. In cases where conflicting values for the
        same application/attribute/link are advertised, the first advertisement
        received in the lowest-numbered LSP Link State Protocol Data Unit (LSP) <bcp14>MUST</bcp14> be used, and subsequent
        advertisements of the same attribute <bcp14>MUST</bcp14> be ignored.</t>
        <t indent="0" pn="section-4.2-7">For
        <t>For a given application, the setting of the L-flag <bcp14>MUST</bcp14> be the same
        in all sub-TLVs for a given link. In cases where this constraint is
        violated, the L-flag <bcp14>MUST</bcp14> be considered set for this
	application.</t>
        <t indent="0" pn="section-4.2-8">The
        <t>The end result of the set of rules defined above is that for a given application either the attribute values advertised in ASLA sub-sub-TLVs are used or the attribute values advertised in Legacy legacy sub-TLVs are used, but not both.</t>
	<t indent="0" pn="section-4.2-9">Link
        <t>Link attributes <bcp14>MAY</bcp14> be advertised associated with
	zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. UDAs.
	Such link attribute advertisements <bcp14>MUST</bcp14> be used by standard applications and/or user defined
	applications
	UDAs when no link attribute advertisements with a non-zero-length Application Identifier
	Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise,
	such link attribute advertisements <bcp14>MUST NOT</bcp14> be used.</t>
        <t indent="0" pn="section-4.2-10">IANA
        <t>IANA has created a new registry of sub-sub-TLVs to define the link
        attribute sub-sub-TLV codepoints (see <xref target="IANA3" format="default" sectionFormat="of" derivedContent="Section 7.3"/>). target="IANA3"/>). This
        document defines a sub-sub-TLV for each of the existing sub-TLVs
        listed in <xref target="LEGSUB" format="default" sectionFormat="of" derivedContent="Section 3.1"/>, target="LEGSUB"/>, except as noted
        below. The format of the sub-sub-TLVs matches the format of the
        corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV
        identifier to the corresponding sub-sub-TLV.</t>
        <section anchor="SCMLB" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-special-considerations-for-">Special anchor="SCMLB">
          <name>Special Considerations for Maximum Link Bandwidth</name>
          <t indent="0" pn="section-4.2.1-1">Maximum
          <t>Maximum link bandwidth is an application-independent attribute of
          the link. When advertised using the Application-Specific Link
          Attributes sub-TLV, multiple values for the same link <bcp14>MUST NOT</bcp14> be
          advertised. This can be accomplished most efficiently by having a
          single advertisement for a given link where the Application
          Identifier Bit Mask identifies all the applications that are making
          use of the value for that link.</t>
          <t indent="0" pn="section-4.2.1-2">It
          <t>It is also possible to advertise the same value for a given link
          multiple times with disjoint sets of applications specified in the
          Application Identifier Bit Mask. This is less efficient but still
          valid.</t>
          <t indent="0" pn="section-4.2.1-3">It
          <t>It is also possible to advertise a single advertisement with a
          zero-length SABM and UDABM so long as the constraints discussed in
          Sections <xref
          Sections&nbsp;<xref target="ASLASUB" format="counter" sectionFormat="of" derivedContent="4.2"/> format="counter"/> and <xref target="DEPZERO" format="counter" sectionFormat="of" derivedContent="6.2"/> format="counter"/> are acceptable.</t>
          <t indent="0" pn="section-4.2.1-4">If satisfied.</t>
          <t>If different values for maximum link bandwidth for a given link
          are advertised, all values <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section anchor="SCUB" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-special-considerations-for-r">Special anchor="SCUB">
          <name>Special Considerations for Reservable/Unreserved Bandwidth</name>
          <t indent="0" pn="section-4.2.2-1">Maximum
          <t>Maximum reservable link bandwidth and unreserved bandwidth are
          attributes specific to RSVP-TE. When advertised using the
          Application-Specific Link Attributes sub-TLV, bits other than the
          RSVP-TE bit (R-bit) <bcp14>MUST NOT</bcp14> be set in the Application Identifier Bit
          Mask. If an advertisement of maximum reservable link bandwidth or
          unreserved bandwidth is received with bits other than the RSVP-TE
          bit R-bit
          set, the advertisement <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section anchor="EXTTE" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-considerations-for-extended">Considerations anchor="EXTTE">
          <name>Considerations for Extended TE Metrics</name>
          <t indent="0" pn="section-4.2.3-1"><xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
          <t><xref target="RFC8570"/> defines a number of dynamic performance
          metrics associated with a link. It is conceivable that such metrics
          could be measured specific to traffic associated with a specific
          application. Therefore, this document includes support for
          advertising these link attributes specific to a given application.
          However, in practice, it may well be more practical to have these
          metrics reflect the performance of all traffic on the link
          regardless of application. In such cases, advertisements for these
          attributes will be associated with all of the applications utilizing
          that link. This can be done either by either explicitly specifying the
          applications in the Application Identifier Bit Mask or by using a
          zero-length Application Identifier Bit Mask. The use of zero-length Application Identifier Bit Mask Masks is further discussed in <xref target="DEPZERO" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t> target="DEPZERO"/>.</t>
        </section>
      </section>
      <section anchor="ASSRLGTLV" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-application-specific-srlg-t">Application-Specific anchor="ASSRLGTLV">
        <name>Application-Specific SRLG TLV</name>
        <t indent="0" pn="section-4.3-1">A new
        <t>A TLV is defined to advertise application-specific SRLGs for a
        given link. Although similar in functionality to TLV 138 <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/> target="RFC5307"/> and
        TLV 139 <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/>, a target="RFC6119"/>, this single TLV provides support for IPv4, IPv6, and
        unnumbered identifiers for a link. Unlike TLVs 138 and 139, it utilizes
        sub-TLVs to encode the link identifiers in order to provide the
        flexible formatting required to support multiple link identifier
        types.</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.3-2">
          <dt pn="section-4.3-2.1">Type:</dt>
          <dd pn="section-4.3-2.2"> newline="true">
          <dt>Type:</dt>
          <dd> 238</dd>
          <dt pn="section-4.3-2.3">
          <dt> Length:</dt>
          <dd pn="section-4.3-2.4">
          <dd> Number of octets in the value field (1 octet)</dd>
          <dt pn="section-4.3-2.5">Value:</dt>
          <dd pn="section-4.3-2.6">
            <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.3-2.6.1">
              <li pn="section-4.3-2.6.1.1">Neighbor
        </dl>
        <dl newline="true">
          <dt>Value:</dt>
          <dd><t>Neighbor System-ID + pseudonode ID (7 octets)</li>
              <li pn="section-4.3-2.6.1.2"> Application octets)</t>
          <t>Application Identifier Bit Mask
       (as defined in <xref target="AIBM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>)</li>
              <li pn="section-4.3-2.6.1.3"> Length target="AIBM"/>)</t>
          <t>Length of sub-TLVs (1 octet)</li>
              <li pn="section-4.3-2.6.1.4"> Link octet)</t>
          <t>Link Identifier sub-TLVs (variable)</li>
              <li pn="section-4.3-2.6.1.5"> 0 (variable)</t>
          <t>0 or more SRLG values (each value is 4 octets)</li>
            </ul> octets)</t>
          </dd>
        </dl>
        <t indent="0" pn="section-4.3-3">If
        <t>If the SABM Length or UDABM Length in the Application Identifier Bit Mask
        is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t>        <t indent="0" pn="section-4.3-4">When
        <t>When the SABM Length or UDABM Length is non-zero and the L-flag is NOT set, all
	applications specified in the bit mask MUST <bcp14>MUST</bcp14> use SRLG advertisements in the Application-Specific SRLG TLV.</t>
        <t indent="0" pn="section-4.3-5">
        <t> The following Link Identifier sub-TLVs are defined.
    The values chosen intentionally match the equivalent
   sub-TLVs from <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>, <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/>, target="RFC5305"/>, <xref target="RFC5307"/>, and <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/>.</t>
        <table align="center" pn="table-2"> target="RFC6119"/>.</t>
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">
              <th> Type </th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th>Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">Link
              <td>4</td>
              <td>Link Local/Remote Identifiers <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/></td> target="RFC5307"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">
              <td>6</td>
              <td>  IPv4 interface address <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/></td> target="RFC5305"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">IPv4
              <td>8</td>
              <td>IPv4 neighbor address <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/></td> target="RFC5305"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">
              <td>12</td>
              <td> IPv6 Interface Address <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/></td> target="RFC6119"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">13</td>
              <td align="left" colspan="1" rowspan="1">
              <td>13</td>
              <td> IPv6 Neighbor Address <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/></td> target="RFC6119"/></td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-4.3-7">At
        <t>At least one set of link identifiers (IPv4, IPv6, or Link
        Local/Remote) <bcp14>MUST</bcp14> be present. Multiple occurrences of the same
        identifier type <bcp14>MUST NOT</bcp14> be present. TLVs that do not meet this
        requirement <bcp14>MUST</bcp14> be ignored.</t>
        <t indent="0" pn="section-4.3-8">Multiple
        <t>Multiple TLVs for the same link <bcp14>MAY</bcp14> be advertised.</t>
        <t indent="0" pn="section-4.3-9">When
        <t>When the L-flag is set in the Application Identifier Bit Mask, SRLG
        values <bcp14>MUST NOT</bcp14> be included in the TLV. Any SRLG values that are
        advertised <bcp14>MUST</bcp14> be ignored. Based on the link identifiers advertised,
        the corresponding legacy TLV (see <xref target="LEGSRLG" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) target="LEGSRLG"/>) can be
        identified, and the SRLG values advertised in the legacy TLV <bcp14>MUST</bcp14> be
        used by the set of applications specified in the Application
        Identifier Bit Mask.</t>
        <t indent="0" pn="section-4.3-10">For
        <t>For a given application, the setting of the L-flag <bcp14>MUST</bcp14> be the same
        in all TLVs for a given link. In cases where this constraint is
        violated, the L-flag <bcp14>MUST</bcp14> be considered set for this application.</t>
      </section>
    </section>
    <section anchor="AAE" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-attribute-advertisements-an">Attribute anchor="AAE">
      <name>Attribute Advertisements and Enablement</name>
      <t indent="0" pn="section-5-1">This
      <t>This document defines extensions to support the advertisement of
      application-specific link attributes.</t>
      <t indent="0" pn="section-5-2">Whether
      ASLAs.</t>
      <t>Whether the presence of link attribute advertisements for a given
      application indicates that the application is enabled on that link
      depends upon the application. Similarly, whether the absence of link
      attribute advertisements indicates that the application is not enabled
      depends upon the application.</t>
      <t indent="0" pn="section-5-3">In
      <t>In the case of RSVP-TE, the advertisement of application-specific
      link attributes ASLAs
      implies that RSVP is enabled on that link. The absence
      of RSVP-TE application-specific link attributes ASLAs in combination with the
      absence of legacy advertisements implies that RSVP is not enabled on
      that link.</t>
      <t indent="0" pn="section-5-4">In
      <t>In the case of SR Policy, the advertisement of application-specific link
      attributes ASLAs
      does not indicate enablement of SR Policy on that link. The
      advertisements are only used to support constraints that may be applied
      when specifying an explicit path. SR Policy is implicitly enabled on all
      links that are part of the SR-enabled topology independent
      of the existence of link attribute advertisements.</t>
      <t indent="0" pn="section-5-5">In
      <t>In the case of LFA, the advertisement of application-specific link
      attributes ASLAs
      does not indicate enablement of LFA on that link. Enablement
      is controlled by local configuration.</t>
      <t indent="0" pn="section-5-6">In
      <t>In the future, if additional standard applications are defined to
      use this mechanism, the specification defining this use <bcp14>MUST</bcp14> define the
      relationship between application-specific link attribute ASLA advertisements
      and enablement for that application.</t>
      <t indent="0" pn="section-5-7">This those applications.</t>
      <t>This document allows the advertisement of application-specific link
      attributes ASLAs
      with no application identifiers, i.e., both neither the Standard
      Application Identifier Bit Mask and nor the User-Defined Application
      Identifier Bit Mask are not is present (see <xref target="AIBM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>). target="AIBM"/>). This supports the
      use of the link attribute by any application. In the presence of an
      application where the advertisement of link attribute advertisements attributes is used to infer the enablement of an application on that link (e.g.,
      RSVP-TE), the absence of the application identifier leaves ambiguous
      whether that application is enabled on such a link. This needs to be
      considered when making use of the "any application" encoding.</t>
    </section>
    <section anchor="DEPCONS" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-deployment-considerations">Deployment anchor="DEPCONS">
      <name>Deployment Considerations</name>
      <t indent="0" pn="section-6-1">This
      <t>This section discusses deployment considerations associated with the
      use of application-specific link attribute ASLA advertisements.</t>
      <section anchor="DEPLEGACY" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-use-of-legacy-advertisement">Use anchor="DEPLEGACY">
        <name>Use of Legacy Advertisements</name>
        <t indent="0" pn="section-6.1-1">Bit
        <t>Bit identifiers for standard applications are defined in <xref target="AIBM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>. target="AIBM"/>. All of the identifiers defined in this document are
        associated with applications that were already deployed in some
        networks prior to the writing of this document. Therefore, such
        applications have been deployed using the legacy advertisements. The
        standard applications defined in this document may continue to use
        legacy advertisements for a given link so long as at least one of the
        following conditions is true:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2">
          <li pn="section-6.1-2.1">The
        <ul>
          <li>The application is RSVP-TE.</li>
          <li pn="section-6.1-2.2">The
          <li>The application is SR Policy or LFA, and RSVP-TE is not deployed
            anywhere in the network.</li>
          <li pn="section-6.1-2.3">The
          <li>The application is SR Policy or LFA, RSVP-TE is deployed in the
            network, and both the set of links on which SR Policy and/or LFA
            advertisements are required and the attribute values used by SR
            Policy and/or LFA on all such links are fully congruent with the
            links and attribute values used by RSVP-TE.</li>
        </ul>
        <t indent="0" pn="section-6.1-3">Under
        <t>Under the conditions defined above, implementations that support
        the extensions defined in this document have the choice of using
        legacy advertisements or application-specific advertisements in
        support of SR Policy and/or LFA.

This will require implementations to
        provide controls specifying which types of advertisements are to be
        sent and processed on receipt for these applications. Further discussion
        of the associated issues can be found in <xref target="IBCMC" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
        <t indent="0" pn="section-6.1-4">New target="IBCMC"/>.</t>
        <t>New applications that future documents define to make use of the
        advertisements defined in this document <bcp14>MUST NOT</bcp14> make use of legacy
        advertisements. This simplifies deployment of new applications by
        eliminating the need to support multiple ways to advertise attributes
        for the new applications.</t>
      </section>
      <section anchor="DEPZERO" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-use-of-zero-length-applicat">Use anchor="DEPZERO">
        <name>Use of Zero-Length Application Identifier Bit Masks</name>
	<t indent="0" pn="section-6.2-1">
        <t>
	  Link attribute advertisements associated with zero-length Application
	  Identifier Bit Masks for both standard applications and user-defined
	  applications UDAs
          are usable by any application, subject to the
	  restrictions specified in <xref target="ASLASUB" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. target="ASLASUB"/>. If support for a new
	  application is introduced on any node in a network in the presence
	  of such advertisements, the new application will use these
	  advertisements, when the aforementioned restrictions are met. If
	  this is not what is intended, then existing link attribute
	  advertisements <bcp14>MUST</bcp14> be readvertised with an explicit
	  set of applications specified before a new application is introduced.</t>
      </section>
      <section anchor="IBCMC" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-interoperability-backwards-">Interoperability, anchor="IBCMC">
        <name>Interoperability, Backwards Compatibility, and Migration Concerns</name>
        <t indent="0" pn="section-6.3-1">Existing
        <t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the
        legacy advertisements listed in <xref target="LEGADV" format="default" sectionFormat="of" derivedContent="Section 3"/>. target="LEGADV"/>. Routers that do not support
        the extensions defined in this document will only process legacy
        advertisements and are likely to infer that RSVP-TE is enabled on the
        links for which legacy advertisements exist. It is expected that
        deployments using the legacy advertisements will persist for a
        significant period of time. Therefore, deployments using the extensions
        defined in this document in the presence of routers that do not
        support these extensions need to be able to interoperate with the use
        of legacy advertisements by the legacy routers. The following
        subsections discuss interoperability and backwards-compatibility
        concerns for a number of deployment scenarios.</t>
        <section anchor="MACARSVP" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.1">
          <name slugifiedName="name-multiple-applications-commo">Multiple anchor="MACARSVP">
          <name>Multiple Applications: Common Attributes with RSVP-TE</name>
          <t indent="0" pn="section-6.3.1-1">In
          <t>In cases where multiple applications are utilizing a given link,
          one of the applications is RSVP-TE, and all link attributes for a
          given link are common to the set of applications utilizing that
          link, interoperability is achieved by using legacy advertisements
          and sending application-specific advertisements with the L-flag set and
          no link attribute values. This avoids duplication of link attribute
          advertisements.</t>
        </section>
        <section anchor="MAALLNS" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.2">
          <name slugifiedName="name-multiple-applications-all-a">Multiple anchor="MAALLNS">
          <name>Multiple Applications: All Attributes Not Shared with RSVP-TE</name>
          <t indent="0" pn="section-6.3.2-1">In
          <t>In cases where one or more applications other than RSVP-TE are
          utilizing a given link and one or more link attribute values are not
          shared with RSVP-TE, it is necessary to use application-specific
          advertisements as defined in this document. Attributes for
          applications other than RSVP-TE <bcp14>MUST</bcp14> be advertised using
          application-specific advertisements that have the L-flag clear. In
          cases where some link attributes are shared with RSVP-TE, this
          requires duplicate advertisements for those attributes.</t>
          <t indent="0" pn="section-6.3.2-2">These
          <t>These guidelines apply to cases where RSVP-TE is not using any
          advertised attributes on a link and to cases where RSVP-TE is using
          some link attribute advertisements on the link but some link
          attributes cannot be shared with RSVP-TE.</t>
        </section>
        <section anchor="LEGACY" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.3">
          <name slugifiedName="name-interoperability-with-legac">Interoperability anchor="LEGACY">
          <name>Interoperability with Legacy Routers</name>
          <t indent="0" pn="section-6.3.3-1">
          <t>
	    For the standard applications defined in this document,
	    routers that do not
	    support the extensions defined in this document will send and
	    receive only legacy link attribute advertisements. In addition,
	    the link attribute values associated with these applications
	    are always shared shared, since legacy routers have no way of advertising or
	    processing application-specific values. So long as there is any
	    legacy router in the network that has any of the standard
	    applications
	    defined in this document enabled, all routers <bcp14>MUST</bcp14>
	    continue to advertise link attributes for these applications using
	    only legacy advertisements. ASLA advertisements for these
	    applications <bcp14>MUST NOT</bcp14> be sent.  Once all legacy
	    routers have been upgraded, migration from legacy advertisements
	    to ASLA advertisements can be achieved via the following steps:
          </t>
          <ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="section-6.3.3-2">

          <li pn="section-6.3.3-2.1" derivedCounter="1)">Send
          <ol>

          <li>Send ASLA advertisements while continuing to advertise using
          legacy advertisements (all advertisements are then duplicated). Receiving routers
          continue to use legacy advertisements.</li>
            <li pn="section-6.3.3-2.2" derivedCounter="2)">Enable
            <li>Enable the use of the ASLA advertisements on all routers.</li>
            <li pn="section-6.3.3-2.3" derivedCounter="3)">Remove
            <li>Remove legacy advertisements.</li>
          </ol>
          <t indent="0" pn="section-6.3.3-3">When
          <t>When the migration is complete, it then becomes possible to
          advertise incongruent values per application on a given link.</t>
          <t indent="0" pn="section-6.3.3-4">Note
          <t>Note that the use of the L-flag is of no value in the
          migration.</t>
          <t indent="0" pn="section-6.3.3-5">Documents
          <t>Documents defining new applications that make use of the
          application-specific advertisements defined in this document <bcp14>MUST</bcp14>
          discuss interoperability and backwards-compatibility issues that
          could occur in the presence of routers that do not support the new
          application.</t>
        </section>
        <section anchor="APPRSVP" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.4">
          <name slugifiedName="name-use-of-application-specific">Use anchor="APPRSVP">
          <name>Use of Application-Specific Advertisements for RSVP-TE</name>
          <t indent="0" pn="section-6.3.4-1">The
          <t>The extensions defined in this document include RSVP-TE as one of
          the applications. It is therefore possible, in the future, for
	  implementations to migrate to the use of application-specific
	  advertisements in support of RSVP-TE. This could
          be done in the following stepwise manner:</t>
          <ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="section-6.3.4-2">
          <li pn="section-6.3.4-2.1" derivedCounter="1)">Upgrade
          <ol>
          <li>Upgrade all routers to support the extensions in this
          document.</li>
            <li pn="section-6.3.4-2.2" derivedCounter="2)">Advertise
            <li>Advertise all legacy link attributes using ASLA advertisements
          with the L-flag clear and the R-bit set. At this point, both legacy and
          application-specific advertisements are being sent.</li>
            <li pn="section-6.3.4-2.3" derivedCounter="3)">Remove
            <li>Remove legacy advertisements.</li>
          </ol>
        </section>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA anchor="IANA">
      <name>IANA Considerations</name>
      <t indent="0" pn="section-7-1">This
      <t>This section lists the protocol codepoint changes introduced by this
      document and the related updates made by IANA.</t>
      <t indent="0" pn="section-7-2">For IANA updates.</t>
      <t>For the new registries defined under the "IS-IS TLV Codepoints" registry group of registries
      with the "Expert Review" a registration procedure of "Expert Review" (see Sections <xref Sections&nbsp;<xref target="IANA3" format="counter" sectionFormat="of" derivedContent="7.3"/> format="counter"/> and
      <xref target="IANA5" format="counter" sectionFormat="of" derivedContent="7.5"/>), format="counter"/>), guidance for designated experts
      can be found in <xref target="RFC7370" format="default" sectionFormat="of" derivedContent="RFC7370"/>.</t>
      <t indent="0" pn="section-7-3">Note target="RFC7370"/>.</t>
      <t>Note that in all cases where the current registry reference is was to RFC 8919 8919, the registry should be has been updated to refer to this document.</t>
      <section anchor="IANA1" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-application-specific-link-at">Application-Specific anchor="IANA1">
        <name>Application-Specific Link Attributes Sub-TLV</name>
        <t indent="0" pn="section-7.1-1">IANA
        <t>IANA has registered the new sub-TLV defined in
        <xref target="ASLASUB" format="default" sectionFormat="of" derivedContent="Section 4.2"/> target="ASLASUB"/> in the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry.</t>
        <table align="center" pn="table-3">
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">22</th>
              <th align="left" colspan="1" rowspan="1">23</th>
              <th align="left" colspan="1" rowspan="1">25</th>
              <th align="left" colspan="1" rowspan="1">141</th>
              <th align="left" colspan="1" rowspan="1">222</th>
              <th align="left" colspan="1" rowspan="1">223
              <th>Type</th>
              <th>Description</th>
              <th>22</th>
              <th>23</th>
              <th>25</th>
              <th>141</th>
              <th>222</th>
              <th>223 </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">16</td>
              <td align="left" colspan="1" rowspan="1">Application-Specific
              <td>16</td>
              <td>Application-Specific Link Attributes</td>
              <td align="left" colspan="1" rowspan="1">y</td>
              <td align="left" colspan="1" rowspan="1">y</td>
              <td align="left" colspan="1" rowspan="1">y(s)</td>
              <td align="left" colspan="1" rowspan="1">y</td>
              <td align="left" colspan="1" rowspan="1">y</td>
              <td align="left" colspan="1" rowspan="1">y</td>
              <td>y</td>
              <td>y</td>
              <td>y(s)</td>
              <td>y</td>
              <td>y</td>
              <td>y</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.1-3"/>
      </section>
      <section anchor="IANA2" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-application-specific-srlg-tl">Application-Specific anchor="IANA2">
        <name>Application-Specific SRLG TLV</name>
        <t indent="0" pn="section-7.2-1">IANA
        <t>IANA has registered the new TLV defined in <xref target="ASSRLGTLV" format="default" sectionFormat="of" derivedContent="Section 4.3"/> target="ASSRLGTLV"/> in the "IS-IS Top-Level TLV Codepoints" registry.
        </t>
        <table align="center" pn="table-4">
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">  Description</th>
              <th align="left" colspan="1" rowspan="1">IIH</th>
              <th align="left" colspan="1" rowspan="1">LSP</th>
              <th align="left" colspan="1" rowspan="1">SNP</th>
              <th align="left" colspan="1" rowspan="1">Purge</th>
              <th>Value</th>
              <th>Description</th>
              <th>IIH</th>
              <th>LSP</th>
              <th>SNP</th>
              <th>Purge</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 238 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Application-Specific SRLG  </td>
              <td align="left" colspan="1" rowspan="1">
              <td> n </td>
              <td align="left" colspan="1" rowspan="1">
              <td> y </td>
              <td align="left" colspan="1" rowspan="1">
              <td> n </td>
              <td align="left" colspan="1" rowspan="1">
              <td> n </td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="IANA3" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-sub-sub-tlv-codepoints-for-">Sub-sub-TLV anchor="IANA3">
        <name>IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes Registry</name>
        <t indent="0" pn="section-7.3-1">IANA
        <t>IANA has created a new registry titled "IS-IS Sub-sub-TLV Sub-Sub-TLV Codepoints for
        Application-Specific Link Attributes" under the "IS-IS TLV
        Codepoints" registry to control the assignment of sub-sub-TLV
        codepoints for the Application-Specific Link Attributes sub-TLV
        defined in <xref target="IANA1" format="default" sectionFormat="of" derivedContent="Section 7.1"/>. target="IANA1"/>.  The registration
        procedure is "Expert Review" as defined in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. target="RFC8126"/>. The initial contents of this registry are as follows:
        </t>
        <table align="center" pn="table-5">
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type
              <th>Type </th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 0-2 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>  Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 3 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Administrative group (color) </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 4-8 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 9  </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Maximum link bandwidth</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 10 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Maximum reservable link bandwidth </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">11 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>11 </td>
              <td> Unreserved bandwidth   </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 12-13 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">14 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>14 </td>
              <td> Extended Administrative Group  </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC7308" format="default" sectionFormat="of" derivedContent="RFC7308"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">15-17 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>
                <xref target="RFC7308"/></td>
            </tr>
            <tr>
              <td>15-17 </td>
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">18 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>18 </td>
              <td> TE Default Metric metric  </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td>
                <xref target="RFC5305"/></td>
            </tr>
            <tr>
              <td> 19-32 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 33 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Link Delay </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 34 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Min/Max Unidirectional Link Delay </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 35 </td>
              <td align="left" colspan="1" rowspan="1">
              <td> Unidirectional Delay Variation  </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">36 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>36 </td>
              <td> Unidirectional Link Loss </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">37 </td>
              <td align="left" colspan="1" rowspan="1">Unidirectional
              <td>37 </td>
              <td>Unidirectional Residual Bandwidth </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 38 </td>
              <td align="left" colspan="1" rowspan="1">Unidirectional
              <td>Unidirectional Available Bandwidth </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>
              <td>
                <xref target="RFC8570"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">39 </td>
              <td align="left" colspan="1" rowspan="1">Unidirectional
              <td>39 </td>
              <td>Unidirectional Utilized Bandwidth </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">40-255 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>
                <xref target="RFC8570"/></td>
            </tr>
            <tr>
              <td>40-255 </td>
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.3-3">IANA
        <t>IANA has also added the following notes to this registry:</t>
        <t indent="3" pn="section-7.3-4">Note: indent="3">Note: For future codepoints, in cases where the document that defines the
encoding is different from the document that assigns the codepoint, the
encoding reference <bcp14>MUST</bcp14> be to the document that
        defines the encoding.</t>
        <t indent="3" pn="section-7.3-5">Note: indent="3">Note: If a link attribute can be advertised
        both as a sub-TLV of TLVs Advertising Neighbor Information advertising neighbor information and as a
        sub-sub-TLV of the Application-Specific Link Attributes sub-TLV
        defined in RFC 8919, 9479, then the same numerical code should be
        assigned to the link attribute whenever possible.</t>
      </section>
      <section anchor="IANA4" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-link-attribute-application-">Link anchor="IANA4">
        <name>Link Attribute Application Identifiers Registry</name>
        <t indent="0" pn="section-7.4-1">IANA
        <t>IANA has created a new registry titled "Link Attribute
        Application Identifiers" under within the "Interior Gateway Protocol (IGP) Parameters" registry group of registries
        to control the assignment of Application Identifier Bits.  The
        registration policy for this registry is "Expert Review" as defined in
        <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. target="RFC8126"/>.  Bit definitions
        <bcp14>SHOULD</bcp14> be assigned such that all bits in the lowest
        available octet are allocated before assigning bits in the next octet.
        This minimizes the number of octets that will need to be transmitted.
        The initial contents of this registry are as follows:
</t>
        <table align="center" pn="table-6">
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit #
              <th>Bit </th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th>Name</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
              <td> 0</td>
              <td align="left" colspan="1" rowspan="1">
              <td> RSVP-TE (R-bit)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">
              <td>1</td>
              <td> Segment Routing Policy (S-bit)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">
              <td>2</td>
              <td> Loop-Free Alternate (F-bit)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">3-63</td>
              <td align="left" colspan="1" rowspan="1">
              <td>3-63</td>
              <td> Unassigned</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="IANA5" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-sub-tlvs-for-tlv-238-regist">Sub-TLVs anchor="IANA5">
        <name>IS-IS Sub-TLVs for TLV 238 Registry</name>
        <t indent="0" pn="section-7.5-1">IANA Application-Specific SRLG TLV</name>
        <t>IANA has created a new registry titled "IS-IS Sub-TLVs for Application-Specific SLRG SRLG TLV" under
        the "IS-IS TLV Codepoints" registry to control the assignment of
        sub-TLV types for the Application-Specific SRLG TLV. TLV (TLV 238).  The registration
        procedure is "Expert Review" as defined in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. target="RFC8126"/>. The initial contents of this registry are as follows:
        </t>
        <table align="center" pn="table-7">
        <table>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
              <th>Value</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0-3 </td>
              <td align="left" colspan="1" rowspan="1">Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">4 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>0-3 </td>
              <td>Unassigned </td>
              <td/>
            </tr>
            <tr>
              <td>4 </td>
              <td> Link Local/Remote Identifiers </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/>
              <td>
                <xref target="RFC5307"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">5 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>5 </td>
              <td>  Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>6 </td>
              <td> IPv4 interface address </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td>7 </td>
              <td>Unassigned </td>
              <td/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">7 </td>
              <td align="left" colspan="1" rowspan="1">Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">8 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>8 </td>
              <td> IPv4 neighbor address  </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>
              <td>
                <xref target="RFC5305"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9-11 </td>
              <td align="left" colspan="1" rowspan="1">Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">12 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>9-11 </td>
              <td>Unassigned </td>
              <td/>
            </tr>
            <tr>
              <td>12 </td>
              <td> IPv6 Interface Address </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/>
              <td>
                <xref target="RFC6119"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">13 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>13 </td>
              <td> IPv6 Neighbor Address  </td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119"/>
              <td>
                <xref target="RFC6119"/> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">14-255 </td>
              <td align="left" colspan="1" rowspan="1">
              <td>14-255 </td>
              <td> Unassigned </td>
              <td align="left" colspan="1" rowspan="1"/>
              <td/>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.5-3">IANA
        <t>IANA has also added the following note to this registry:</t>
        <t indent="3" pn="section-7.5-4">Note: indent="3">Note: For future codepoints, in cases where the document that
        defines the encoding is different from the document that assigns the
        codepoint, the encoding reference <bcp14>MUST</bcp14> be to the
        document that defines the encoding.</t>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security anchor="Security">
      <name>Security Considerations</name>
      <t indent="0" pn="section-8-1">Security
      <t>Security concerns for IS-IS are addressed in <xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589"/>, <xref target="RFC5304" format="default" sectionFormat="of" derivedContent="RFC5304"/>, target="ISO10589"/>, <xref target="RFC5304"/>, and <xref target="RFC5310" format="default" sectionFormat="of" derivedContent="RFC5310"/>. target="RFC5310"/>. While IS-IS is deployed under a single
      administrative domain, there can be deployments where potential
      attackers have access to one or more networks in the IS-IS routing
      domain. In these deployments, the stronger authentication mechanisms
      defined in the aforementioned documents <bcp14>SHOULD</bcp14> be used.</t>
      <t indent="0" pn="section-8-2">This
      <t>This document defines a new an improved way to advertise link attributes.
      Tampering with the information defined in this document may have an
      effect on applications using it, including impacting traffic engineering TE
      as discussed in <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>. target="RFC8570"/>. As the advertisements defined
      in this document limit the scope to specific applications, the impact of
      tampering is similarly limited in scope.</t>
    </section>
    <section anchor="changes-to-rfc8919" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-changes-to-rfc8919">Changes anchor="changes-to-rfc8919">
      <name>Changes to RFC 8919</name>
      <t indent="0" pn="section-9-1">Discussion
      <t>Discussion within the LSR WG indicated that there was confusion regarding
      the use of ASLA advertisements that had a zero length zero-length SABM/UDABM.
      The discussion can be seen by searching the LSR WG mailing list archives
      for the thread "Proposed Errata for RFCs 8919/8920" starting on
      15 June 2021. </t>
      <t indent="0" pn="section-9-2">Changes 2021.</t>
      <t>Changes to Sections 4.2, 4.3, Sections&nbsp;<xref target="ASLASUB" format="counter"/>, <xref target="ASSRLGTLV" format="counter"/>, and 6.2 <xref target="DEPZERO" format="counter"/> have been introduced to clarify normative
      behavior in the presence of such advertisements. In particular, the text in RFC 8919 <xref target="RFC8919"/> used the word "permitted",
      suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability
      issues and is not what was intended.</t>
      <t indent="0" pn="section-9-3">The
      <t>The replacement text makes explicit the specific conditions when such
      advertisements <bcp14>MUST</bcp14> be used and the specific conditions under which they <bcp14>MUST NOT</bcp14>
      be used.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9256" to="SEGMENT-ROUTING"/>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="ISO10589" quoteTitle="true" derivedAnchor="ISO10589"> target="https://www.iso.org/standard/30932.html">
          <front>
            <title>Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title>
            <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
            <author>
              <organization abbrev="ISO" showOnFrontPage="true">International abbrev="ISO">International Organization for Standardization</organization>
            </author>
            <date month="Nov" month="November" year="2002"/>
          </front>
        </reference>
        <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 initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <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="RFC5304" target="https://www.rfc-editor.org/info/rfc5304" quoteTitle="true" derivedAnchor="RFC5304">
          <front>
            <title>IS-IS Cryptographic Authentication</title>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t indent="0">This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.  The base specification includes an authentication mechanism that allows for multiple authentication algorithms.  The base specification only specifies the algorithm for cleartext passwords.  This document replaces RFC 3567.</t>
              <t indent="0">This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5304"/>
	  <seriesInfo name="DOI" value="10.17487/RFC5304"/>
        </reference>
        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" quoteTitle="true" derivedAnchor="RFC5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Smit" fullname="H. Smit">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t indent="0">This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).  This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP).  This information describes additional details regarding the state of the network that are useful for traffic engineering computations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5305"/>
          <seriesInfo name="DOI" value="10.17487/RFC5305"/>
        </reference>
        <reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307" quoteTitle="true" derivedAnchor="RFC5307">
          <front>
            <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t indent="0">This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5307"/>
          <seriesInfo name="DOI" value="10.17487/RFC5307"/>
        </reference>
        <reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5310" quoteTitle="true" derivedAnchor="RFC5310">
          <front>
            <title>IS-IS Generic Cryptographic Authentication</title>
            <author initials="M." surname="Bhatia" fullname="M. Bhatia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Manral" fullname="V. Manral">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="White" fullname="R. White">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Fanto" fullname="M. Fanto">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="February"/>
            <abstract>
              <t indent="0">This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.</t>
              <t indent="0">Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5310"/>
          <seriesInfo name="DOI" value="10.17487/RFC5310"/>
        </reference>
        <reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6119" quoteTitle="true" derivedAnchor="RFC6119">
          <front>
            <title>IPv6 Traffic Engineering in IS-IS</title>
            <author initials="J." surname="Harrison" fullname="J. Harrison">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Berger" fullname="J. Berger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bartlett" fullname="M. Bartlett">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="February"/>
            <abstract>
              <t indent="0">This document specifies a method for exchanging IPv6 traffic  engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to  calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6119"/>
          <seriesInfo name="DOI" value="10.17487/RFC6119"/>
        </reference>
        <reference anchor="RFC7308" target="https://www.rfc-editor.org/info/rfc7308" quoteTitle="true" derivedAnchor="RFC7308">
          <front>
            <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title>
            <author initials="E." surname="Osborne" fullname="E. Osborne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="July"/>
            <abstract>
              <t indent="0">MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV.  This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).</t>
              <t indent="0">This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group".  This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7308"/>
          <seriesInfo name="DOI" value="10.17487/RFC7308"/>
        </reference>
        <reference anchor="RFC7370" target="https://www.rfc-editor.org/info/rfc7370" quoteTitle="true" derivedAnchor="RFC7370">
          <front>
            <title>Updates to the IS-IS TLV Codepoints Registry</title>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="September"/>
            <abstract>
              <t indent="0">This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol.  It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7370"/>
          <seriesInfo name="DOI" value="10.17487/RFC7370"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </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 initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <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="RFC8570" target="https://www.rfc-editor.org/info/rfc8570" quoteTitle="true" derivedAnchor="RFC8570">
          <front>
            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Giacalone" fullname="S. Giacalone">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="March"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
              <t indent="0">This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305).  These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
              <t indent="0">Note that this document only covers the mechanisms with which network-performance information is distributed.  The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
              <t indent="0">This document obsoletes RFC 7810.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8570"/>
          <seriesInfo name="DOI" value="10.17487/RFC8570"/> name="ISO/IEC" value="10589:2002"/>
         <refcontent>Second Edition</refcontent>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7370.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>

      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative
      <references>
        <name>Informative References</name>
        <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 initials="D." surname="Awduche" fullname="D. Awduche">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Gan" fullname="D. Gan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="December"/>
            <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="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 initials="A." surname="Atlas" fullname="A. Atlas" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Zinin" fullname="A. Zinin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="September"/>
            <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="RFC7855" target="https://www.rfc-editor.org/info/rfc7855" quoteTitle="true" derivedAnchor="RFC7855">
          <front>
            <title>Source Packet Routing in Networking (SPRING) Problem Statement and Requirements</title>
            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Decraene" fullname="B. Decraene">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Litkowski" fullname="S. Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Horneffer" fullname="M. Horneffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Shakir" fullname="R. Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="May"/>
            <abstract>
              <t indent="0">The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions.  Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption.  In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</t>
              <t indent="0">This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic.  Multicast use cases and requirements are out of scope for this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7855"/>
          <seriesInfo name="DOI" value="10.17487/RFC7855"/>
        </reference>
        <reference anchor="RFC9256" quoteTitle="true" derivedAnchor="SEGMENT-ROUTING">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Ketan Talaulikar">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Daniel Voyer">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author fullname="Alex Bogdanov">
              <organization showOnFrontPage="true">Google, Inc.</organization>
            </author>
            <author fullname="Paul Mattes">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8919.xml"/>

      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">RFC numbered="false">
      <name>Acknowledgements</name>
      <t>RFC 8919 included the following acknowledgements:</t>
      <t indent="0" pn="section-appendix.a-2">
      <contact
      <blockquote>
      <t><contact fullname="Eric Rosen"/> and <contact fullname="Acee Lindem"/> for their careful review and content
      suggestions.</t>
      <t indent="0" pn="section-appendix.a-3">
      </blockquote>
      <t> For the new version, version (this document), the authors would like to thank
      <contact fullname="Bruno Decraene"/>.</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="Les Ginsberg" initials="L" surname="Ginsberg">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
          </postal>
          <email>ginsberg@cisco.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="Stefano Previdi" initials="S" surname="Previdi">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street/>
            <country/>
          </postal>
          <email>stefano@previdi.net</email>
        </address>
      </author>
      <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street>Copernicuslaan 50</street>
            <city>Antwerp</city>
            <code>2018 94089</code>
            <country>Belgium</country>
          </postal>
          <email>wim.henderickx@nokia.com</email>
        </address>
      </author>
      <author fullname="John Drake" initials="J" surname="Drake">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <postal>
            <street/>
            <code/>
            <country/>
          </postal>
          <email>jdrake@juniper.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>