<?xml version="1.0" encoding="US-ASCII"?> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="true" docName="draft-ietf-isis-te-app-19"
     number="8919" ipr="trust200902"
     updates=""> updates="" obsoletes="" xml:lang="en"
     tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
     version="3">

  <front>

    <title abbrev="draft-ietf-isis-te-app">IS-IS abbrev="IS-IS App-Specific Link Attributes">IS-IS Application-Specific Link
    Attributes</title>
    <seriesInfo name="RFC" value="8919"/>
    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>821 Alder Drive</street>
          <city>Milpitas</city>
          <code>95035</code>
          <region>CA</region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>ginsberg@cisco.com</email>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P" surname="Psenak">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Apollo
	  <extaddr>Apollo Business Center Mlynske Center</extaddr>
	  <street>Mlynske nivy 43</street>
          <city>Bratislava</city>
          <code>821 09</code>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Stefano Previdi" initials="S" surname="Previdi">
      <organization>Huawei</organization>
      <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>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>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <code/>
          <country/>
        </postal>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <date year="2020"/> year="2020" month="October" />
    <area>Routing Area</area>
    <workgroup>Networking Working Group</workgroup>

    <keyword/>

    <abstract>

      <t>Existing traffic engineering related 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, Loop Free Alternate) Policy and Loop-Free Alternates) that also make use of the
      link attribute advertisements have been defined . defined. In cases where
      multiple applications wish to make use of these link attributes, the
      current advertisements do not support application-specific values for a
      given attribute, nor do they support indication of which applications
      are using the advertised value for a given link. This document
      introduces new link attribute advertisements that address both of these
      shortcomings.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
      shown here.</t>
    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Advertisement of link attributes by the
      Intermediate-System-to-Intermediate-System
      Intermediate System to Intermediate System (IS-IS) protocol in support
      of traffic engineering (TE) was introduced by [RFC5305] <xref target="RFC5305" format="default"/> and extended by
      [RFC5307], [RFC6119], [RFC7308],
      <xref target="RFC5307" format="default"/>, <xref target="RFC6119"
      format="default"/>, <xref target="RFC7308" format="default"/>, and [RFC8570]. <xref target="RFC8570"/>. Use of these extensions
      has been associated with deployments supporting Traffic Engineering over
      Multiprotocol Label Switching (MPLS) in the presence of the Resource
      Reservation Protocol (RSVP) - (RSVP), more succinctly referred to as RSVP-TE
      <xref target="RFC3209"/>.</t> target="RFC3209" format="default"/>.</t>
      <t>For the purposes of this document document, an application is a technology that
      makes use of link attribute advertisements - advertisements, examples of which are
      listed in <xref target="LEGADV"/>.</t> target="LEGADV" format="default"/>.</t>
      <t>In recent years 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 (SR Policy) <xref
      target="I-D.ietf-spring-segment-routing-policy"/> target="I-D.ietf-spring-segment-routing-policy" format="default"/> and Loop Free Loop-Free
      Alternates (LFA) (LFAs) <xref target="RFC5286"/>. target="RFC5286" format="default"/>. This has introduced ambiguity
      in that if a deployment includes a mix of RSVP-TE support and SR Policy
      support (for example)
      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 congruent, this may not
      be an issue, but any incongruence leads to ambiguity.</t>
      <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. (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 head end sees the link attribute being advertised for that link,
      it assumes RSVP-TE is enabled on that link, even though it is not. If
      such an RSVP-TE head-end router tries to setup set up an RSVP-TE path via that
      link, it will result in a path setup failure.</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>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">
<name>Requirements Language</name>
        <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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
</section>
    </section>

    <section anchor="REQDIS" title="Requirements Discussion"> numbered="true" toc="default">
      <name>Requirements Discussion</name>
      <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, which are:</t>

      <t><list style="numbers">
          <t>Support
      <ol spacing="normal" type="1">
        <li>Support for indicating which applications are using the link
          attribute advertisements on a link</t>

          <t>Support link</li>
        <li>Support for advertising application-specific values for the same
          attribute on a link</t>
        </list>[RFC7855] link</li>
      </ol>

      <t><xref target="RFC7855" format="default"/> discusses use cases/requirements cases and requirements for Segment Routing
      (SR). Included among these use cases is SR Policy Policy, which is defined in
      <xref target="I-D.ietf-spring-segment-routing-policy"/>. target="I-D.ietf-spring-segment-routing-policy" format="default"/>. 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. As there

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, RSVP-TE; thus, there is a clear requirement to indicate
independently which link attribute advertisements are to be used by each
application.</t>

      <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 backwards-compatibility issues.</t>
      <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" title="Legacy Advertisements">
      <t>There are existing numbered="true" toc="default">
      <name>Legacy Advertisements</name>
      <t>Existing advertisements used in support of RSVP-TE. These
      advertisements RSVP-TE include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
      and TLVs for Shared Risk Link Group (SRLG) advertisement.</t>
      <t>Sub-TLV values are defined in the Sub-TLVs "Sub-TLVs for TLVs 22, 23, 25, 141,
      222, and 223 223" registry.</t>
      <t>TLVs are defined in the TLV "TLV Codepoints Registry.</t> Registry".</t>
      <section anchor="LEGSUB" title="Legacy sub-TLVs">
        <t><figure>
            <artwork><![CDATA[Sub-TLVs numbered="true" toc="default">
	 <name>Legacy Sub-TLVs</name>

	<table anchor="legacysub" align="left">
	 <name>Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223

     +-------------------------------------------+
     | 223</name>
	  <thead>
	    <tr>
	      <th> Type | </th>
	      <th> Description                        |
     +-------------------------------------------+
     | </th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td> 3  | </td>
	      <td> Administrative group (color)       |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 9  | </td>
	      <td> Maximum link bandwidth             |
     +-------------------------------------------+
     | bandwidth</td>
	    </tr>
	    <tr>

	      <td> 10  | </td>
	      <td> Maximum reservable link bandwidth  |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 11  | </td>
	      <td> Unreserved bandwidth               |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 14  | </td>
	      <td> Extended Administrative Group      |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 18  | </td>
	      <td> TE Default Metric                  |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 33  | </td>
	      <td> Unidirectional Link Delay          |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 34  | </td>
	      <td>  Min/Max Unidirectional Link Delay  |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 35  | </td>
	      <td> Unidirectional Delay Variation     |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 36  | </td>
	      <td> Unidirectional Link Loss           |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>

	      <td> 37  | </td>
	      <td> Unidirectional Residual Bandwidth  |
     +-------------------------------------------+
     | </td>
	    </tr>
	    <tr>
	      <td> 38  | </td>
	      <td> Unidirectional Available Bandwidth |
     +-------------------------------------------+
     | Bandwidth</td>
	    </tr>
	    <tr>
	      <td> 39  | </td>
	      <td>  Unidirectional Utilized Bandwidth  |
     +-------------------------------------------+

]]></artwork>
          </figure></t> </td>
	    </tr>
	  	  </tbody>
	</table>

      </section>
      <section anchor="LEGSRLG" title="Legacy numbered="true" toc="default">

        <name>Legacy SRLG Advertisements">
        <t><figure>
            <artwork><![CDATA[TLV Advertisements</name>

        <dl newline="true">
	  <dt>TLV 138 GMPLS-SRLG
  Supports (GMPLS-SRLG):</dt>
  <dd>Supports links identified by IPv4 addresses and
  unnumbered links

TLV links.</dd>

<dt>TLV 139 IPv6 SRLG (IPv6 SRLG):</dt>
 <dd> Supports links identified by IPv6 addresses

]]></artwork>
          </figure>Note addresses.</dd>

	</dl>

        <t>Note that [RFC6119] <xref target="RFC6119" format="default"/> prohibits the
        use of TLV 139 when it is possible to use TLV 138.</t>
      </section>
    </section>
    <section anchor="ASLA"
             title="Advertising numbered="true" toc="default">
      <name>Advertising Application-Specific Link Attributes"> Attributes</name>
      <t>Two new code points codepoints are defined in to support of Application-Specific
      Link Attribute (ASLA) Advertisements:</t>

      <t>1) ASLA advertisements:</t>
<ol type="%d)">
      <li>Application-Specific Link Attributes sub-TLV for TLVs 22, 23, 25,
      141, 222, and 223 (defined in <xref target="ASLASUB"/> ).</t>

      <t>2)Application-Specific target="ASLASUB"
      format="default"/>).</li>
      <li>Application-Specific Shared Risk Link Group (SRLG) TLV (defined in
      <xref target="ASSRLGTLV"/>).</t>

      <t>In target="ASSRLGTLV" format="default"/>).</li>
</ol>

      <t>To support of these new advertisements, an
      application identifier bit mask is defined that identifies to identify the application(s)
      associated with a given advertisement (defined in <xref target="AIBM"/>).</t> target="AIBM"
      format="default"/>).</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 user-defined applications. Such applications are not subject to
      standardization and are outside the scope of this document.</t>
      <t>The following sections define the format of these new
      advertisements.</t>
      <section anchor="AIBM" title="Application numbered="true" toc="default">
        <name>Application Identifier Bit Mask"> Mask</name>
        <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 IANA controlled registry. IANA-controlled registry (see <xref target="IANA4"/>). A second
        bit mask is for non-standard
        User Defined Applications user-defined applications (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>

        <t><figure>
            <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
| SABM Length + Flag    |  1 octet
+--+--+--+--+--+--+--+--+
| UDABM Length + Flag   |  1 octet
+--+--+--+--+--+--+--+--+
|   SABM         ...       0 - 8 octets
+--+--+--+--+--+--+--+--+
|   UDABM        ...       0 - 8 octets
+--+--+--+--+--+--+--+--+

SABM
]]></artwork>

<dl newline="false">
<dt>SABM Length + Flag (1 octet) octet):</dt>
   <dd><t> Standard Application Identifier Bit Mask Length + Flag Flag</t>

  <artwork>
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |L| SABM Length |
         +-+-+-+-+-+-+-+-+

   L-flag: Legacy
</artwork>
<dl>

  <dt>L-flag:</dt><dd>Legacy Flag.
    See Section 4.2 <xref target="ASLASUB"/> for a description of how
    this flag is used.

   SABM Length: Indicates used.</dd>

  <dt>SABM Length:</dt><dd>Indicates the length in octets (0-8) of the
    Standard Application Identifier Bit Mask. The length SHOULD <bcp14>SHOULD</bcp14>
    be the minimum required to send all bits that are set.

UDABM set.</dd>
</dl>
   </dd>

<dt>UDABM Length + Flag (1 octet)
    User Defined octet):</dt>
   <dd><t> User-Defined Application Identifier Bit Mask Length + Flag Flag</t>
<artwork>
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |R| UDABM Length|
         +-+-+-+-+-+-+-+-+

   R:
</artwork>
<dl>

  <dt>R:</dt><dd> Reserved. SHOULD <bcp14>SHOULD</bcp14> be transmitted as 0 and
    MUST
    <bcp14>MUST</bcp14> be ignored on receipt

   UDABM Length: receipt.</dd>

  <dt>UDABM Length:</dt><dd> Indicates the length in octets (0-8) of the
    User Defined
    User-Defined Application Identifier Bit Mask. The length SHOULD <bcp14>SHOULD</bcp14>
    be the minimum required to send all bits that are set.

SABM set.</dd>
</dl>
   </dd>

<dt>SABM  (variable length) length):</dt>
  <dd><t> Standard Application Identifier Bit Mask Mask</t>

  <t> (SABM Length * 8) bits

   This bits</t>

<t>This field is omitted if SABM Length is 0. 0.</t>
<artwork>
          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |R|S|F|          ...
         +-+-+-+-+-+-+-+-+...

      R-bit: Set
</artwork>
 <dl>
     <dt> R-bit:</dt><dd>Set to specify RSVP-TE

      S-bit: Set RSVP-TE.</dd>

     <dt> S-bit:</dt><dd>Set to specify Segment Routing Policy

      F-bit: Set Policy.</dd>

     <dt> F-bit:</dt><dd>Set to specify Loop Free Loop-Free Alternate (LFA)
     (includes all LFA types)

 UDABM types).</dd>
 </dl>
  </dd>

<dt>UDABM  (variable length)
   User Defined length):</dt>
  <dd><t> User-Defined Application Identifier Bit Mask

   (UDABM Mask</t>

<t>(UDABM Length * 8) bits bits</t>
<artwork>
          0 1 2 3 4 5 6 7 ...
         +-+-+-+-+-+-+-+-+...
         |                ...
         +-+-+-+-+-+-+-+-+...
</artwork>
<t> This field is omitted if UDABM Length is 0.

]]></artwork>
          </figure>NOTE: 0.</t>
  </dd>
</dl>
<aside>
  <t>
        Note: SABM/UDABM Length is arbitrarily limited to 8 octets
        in order to insure ensure that sufficient space is left to advertise link
        attributes without overrunning the maximum length of a sub-TLV.</t> sub-TLV.</t></aside>
        <t>Standard Application Identifier Bits are defined/sent defined and sent starting with
        Bit
        bit 0.</t>

        <t>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 are be used
        starting with Bit bit 0 so as to minimize the number of octets required to
        advertise all UDAs.</t>

        <t>In the case of

        <t>For both SABM and UDABM, the following rules apply:</t>

        <t><list style="symbols">
            <t>Undefined
        <ul spacing="normal">
          <li>Undefined bits that are transmitted MUST <bcp14>MUST</bcp14> be transmitted as 0
            and MUST <bcp14>MUST</bcp14> be ignored on receipt</t>

            <t>Bits receipt.</li>
          <li>Bits that are not transmitted MUST <bcp14>MUST</bcp14> be treated as if they are
            set to 0 on receipt.</t>

            <t>Bits receipt.</li>
          <li>Bits that are not supported by an implementation MUST <bcp14>MUST</bcp14> be
            ignored on receipt.</t>
          </list>.</t> receipt.</li>
        </ul>
      </section>
      <section anchor="ASLASUB"
               title="Application-Specific numbered="true" toc="default">
        <name>Application-Specific Link Attributes sub-TLV"> Sub-TLV</name>
        <t>A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined
        that supports specification of the applications and
        application-specific attribute values.</t>

        <t><figure>
            <artwork><![CDATA[   Type: 16 (temporarily assigned by IANA)
   Length:

	<dl>
	  <dt>Type:</dt><dd> 16</dd>
	  <dt>Length:</dt><dd> Variable (1 octet)
   Value:

     Application octet)</dd>
	  <dt>Value:</dt>

	  <dd>
            <ul empty="true">
	    <li>Application Identifier Bit Mask
	  (as defined in Section 4.1) <xref target="AIBM"/>)</li>

	 <li> Link Attribute sub-sub-TLVs - -- format matches the
	  existing formats defined in [RFC5305], [RFC7308], <xref target="RFC5305"/>, <xref target="RFC7308"/>,
	 and [RFC8570]]]></artwork>
          </figure></t> <xref target="RFC8570"/></li>
	    </ul>
	  </dd>
	</dl>

        <t>If the SABM or UDABM length Length in the Application Identifier Bit Mask
        is greater than 8, the entire sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>When the L-flag is set in the Application Identifier Bit Mask, all
        of the applications specified in the bit mask MUST <bcp14>MUST</bcp14> use the legacy
        advertisements for the corresponding link found in TLVs 22, 23, 25,
        141, 222, and 223 or 223, in TLV 138 138, or in TLV 139 as appropriate. Link attribute
        sub-sub-TLVs for the corresponding link attributes MUST NOT <bcp14>MUST NOT</bcp14> be
        advertised for the set of applications specified in the Standard/User Standard or User-Defined
        Application Identifier Bit Masks Masks, and all such advertisements MUST <bcp14>MUST</bcp14> be
        ignored on receipt.</t>
        <t>Multiple Application-Specific Link Attribute Attributes sub-TLVs for the same
        link MAY <bcp14>MAY</bcp14> be advertised. When multiple sub-TLVs for the same link are
        advertised, they SHOULD <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 advertised, the first advertisement
        received in the lowest numbered lowest-numbered LSP SHOULD <bcp14>SHOULD</bcp14> be used used, and subsequent
        advertisements of the same attribute SHOULD <bcp14>SHOULD</bcp14> be ignored.</t>
        <t>For a given application, the setting of the L-flag MUST <bcp14>MUST</bcp14> be the same
        in all sub-TLVs for a given link. In cases where this constraint is
        violated, the L-flag MUST <bcp14>MUST</bcp14> be considered set for this
	application.</t>
        <t>If link attributes are advertised associated with zero length zero-length
        Application Identifier Bit Masks for both standard applications and
        user defined
        user-defined applications, then any Standard Application standard application and/or any
        User Defined Application
        user-defined application is permitted to use that set of link
        attributes so long as there is not another set of attributes
        advertised on that same link that is associated with a non-zero length non-zero-length
        Application Identifier Bit Mask with a matching Application Identifier
        Bit set.</t>

        <t>A
        <t>IANA has created a new registry of sub-sub-TLVs is to be created by IANA that
        defines define the link
        attribute sub-sub-TLV code points. codepoints (see <xref target="IANA3"/>). This
        document defines a sub-sub-TLV for each of the existing sub-TLVs
        listed in <xref target="LEGSUB"/> target="LEGSUB" format="default"/>, except as noted
        below. The format of the sub-sub-TLVs matches the format of the
        corresponding legacy sub-TLV sub-TLV, and IANA is requested to assign has assigned the legacy sub-TLV
        identifier to the corresponding sub-sub-TLV.</t>
        <section anchor="SCMLB"
                 title="Special numbered="true" toc="default">
          <name>Special Considerations for Maximum Link Bandwidth"> Bandwidth</name>
          <t>Maximum link bandwidth is an application independent application-independent attribute of
          the link. When advertised using the Application-Specific Link
          Attributes sub-TLV, multiple values for the same link MUST NOT <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>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>It is also possible to advertise a single advertisement with zero
          length
          zero-length SABM and UDABM so long as the constraints discussed in
          Sections <xref
          target="ASLASUB"/> target="ASLASUB" format="counter"/> and <xref target="DEPZERO"/>
          target="DEPZERO" format="counter"/> are acceptable.</t>
          <t>If different values for Maximum Link Bandwidth maximum link bandwidth for a given link
          are advertised, all values MUST <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section anchor="SCUB"
                 title="Special numbered="true" toc="default">
          <name>Special Considerations for Reservable/Unreserved Bandwidth"> Bandwidth</name>
          <t>Maximum Reservable Link Bandwidth reservable link bandwidth and Unreserved Bandwidth unreserved bandwidth are
          attributes specific to RSVP-TE. When advertised using the
          Application-Specific Link Attributes sub-TLV, bits other than the
          RSVP-TE (R-bit) MUST NOT <bcp14>MUST NOT</bcp14> be set in the Application Identifier Bit
          Mask. If an advertisement of Maximum Reservable Link Bandwidth maximum reservable link bandwidth or
          Unreserved Bandwidth
          unreserved bandwidth is received with bits other than the RSVP-TE
          bit set, the advertisement MUST <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section anchor="EXTTE" title="Considerations numbered="true" toc="default">
          <name>Considerations for Extended TE Metrics"> Metrics</name>
          <t><xref target="RFC8570"/> target="RFC8570" format="default"/> 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 Therefore, this document includes support for
          advertising these link attributes specific to a given application.
          However, in practice 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 explicitly specifying the
          applications in the Application Identifier Bit Mask or by using a
          zero length
          zero-length Application Identifier Bit Mask.</t>
        </section>
      </section>
      <section anchor="ASSRLGTLV" title="Application-Specific numbered="true" toc="default">
        <name>Application-Specific SRLG TLV"> TLV</name>
        <t>A new TLV is defined to advertise application-specific SRLGs for a
        given link. Although similar in functionality to TLV 138 [RFC5307] <xref
	target="RFC5307" format="default"/> and
        TLV 139 [RFC6119], <xref target="RFC6119" format="default"/>, a single TLV provides support for IPv4, IPv6, and
        unnumbered identifiers for a link. Unlike TLVs 138/139, 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>

        <t><figure>
            <artwork><![CDATA[    Type: 238 (Temporarily assigned by IANA)
    Length:

	<dl>
	  <dt>Type:</dt><dd> 238</dd>
   <dt> Length:</dt><dd> Number of octets in the value field (1 octet)
    Value:
      Neighbor octet)</dd>
   <dt>Value:</dt>

   <dd>

     <ul empty="true">
       <li>Neighbor System-ID + pseudo-node pseudonode ID (7 octets) octets)</li>
    <li> Application Identifier Bit Mask
       (as defined in Section 4.1) <xref target="AIBM"/>)</li>
     <li> Length of sub-TLVs (1 octet) octet)</li>
     <li> Link Identifier sub-TLVs (variable) (variable)</li>
     <li> 0 or more SRLG Values (Each values (each value is 4 octets) octets)</li>
     </ul>
     </dd>
 </dl>

   <t> The following Link Identifier sub-TLVs are defined.
    The values chosen are intentionally matching match the equivalent
   sub-TLVs from [RFC5305], [RFC5307], <xref target="RFC5305"/>, <xref target="RFC5307"/>, and [RFC6119]. <xref target="RFC6119"/>.</t>

   <table>
     <thead>
       <tr>

	 <th> Type    Description
     4      Link </th>
	 <th>Description</th>
       </tr>
     </thead>
     <tbody>
       <tr>
	 <td>4</td>
	 <td>Link Local/Remote Identifiers [RFC5307]
     6 <xref target="RFC5307"/></td>
       </tr>
       <tr>
	 <td>6</td>
	 <td>  IPv4 interface address [RFC5305]
     8      IPv4 <xref target="RFC5305"/></td>
       </tr>
       <tr>
	 <td>8</td>
	 <td>IPv4 neighbor address [RFC5305]
    12 <xref target="RFC5305"/></td>
       </tr>
       <tr>
	 <td>12</td>
	 <td> IPv6 Interface Address [RFC6119]
    13 <xref target="RFC6119"/></td>
       </tr>
       <tr>
	 <td>13</td>
	 <td> IPv6 Neighbor Address [RFC6119]
]]></artwork>
          </figure>At <xref target="RFC6119"/></td>
       </tr>
     </tbody>
   </table>
        <t>At least one set of link identifiers (IPv4, IPv6, or Link
        Local/Remote) MUST <bcp14>MUST</bcp14> be present. Multiple occurrences of the same
        identifier type MUST NOT <bcp14>MUST NOT</bcp14> be present. TLVs that do not meet this
        requirement MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>Multiple TLVs for the same link MAY <bcp14>MAY</bcp14> be advertised.</t>
        <t>When the L-flag is set in the Application Identifier Bit Mask, SRLG
        values MUST NOT <bcp14>MUST NOT</bcp14> be included in the TLV. Any SRLG values that are
        advertised MUST <bcp14>MUST</bcp14> be ignored. Based on the link identifiers advertised advertised,
        the corresponding legacy TLV (see <xref target="LEGSRLG"/>) target="LEGSRLG" format="default"/>) can be
        identified
        identified, and the SRLG values advertised in the legacy TLV MUST <bcp14>MUST</bcp14> be
        used by the set of applications specified in the Application
        Identifier Bit Mask.</t>
        <t>For a given application, the setting of the L-flag MUST <bcp14>MUST</bcp14> be the same
        in all TLVs for a given link. In cases where this constraint is
        violated, the L-flag MUST <bcp14>MUST</bcp14> be considered set for this application.</t>
      </section>
    </section>
    <section anchor="AAE" title="Attribute numbered="true" toc="default">
      <name>Attribute Advertisements and Enablement"> Enablement</name>
      <t>This document defines extensions to support the advertisement of
      application-specific link attributes.</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>In the case of RSVP-TE, the advertisement of application-specific
      link attributes implies that RSVP is enabled on that link. The absence
      of RSVP-TE application-specific link attributes in combination with the
      absence of legacy advertisements implies that RSVP is not enabled on
      that link.</t>
      <t>In the case of SR Policy, the advertisement of application-specific link
      attributes 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 Segment Routing enabled SR-enabled topology independent
      of the existence of link attribute advertisements.</t>
      <t>In the case of LFA, the advertisement of application-specific link
      attributes does not indicate enablement of LFA on that link. Enablement
      is controlled by local configuration.</t>

      <t>If, in
      <t>In the future, if additional standard applications are defined to
      use this mechanism, the specification defining this use MUST <bcp14>MUST</bcp14> define the
      relationship between application-specific link attribute advertisements
      and enablement for that application.</t>
      <t>This document allows the advertisement of application-specific link
      attributes with no application identifiers identifiers, i.e., both the Standard
      Application Identifier Bit Mask and the User Defined User-Defined Application
      Identifier Bit Mask are not present (See Section 4.1). (see <xref 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 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" title="Deployment Considerations"> numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <t>This section discuss discusses deployment considerations associated with the
      use of application-specific link attribute advertisements.</t>
      <section anchor="DEPLEGACY" title="Use numbered="true" toc="default">
        <name>Use of Legacy Advertisements"> Advertisements</name>
        <t>Bit Identifiers identifiers for Standard Applications standard applications are defined in <xref
        target="AIBM"/>. target="AIBM" format="default"/>. 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
        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>

        <t><list style="symbols">
            <t>The
        <ul spacing="normal">
          <li>The application is RSVP-TE</t>

            <t>The RSVP-TE.</li>
          <li>The application is SR Policy or LFA LFA, and RSVP-TE is not deployed
            anywhere in the network</t>

            <t>The network.</li>
          <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 is are fully congruent with the
            links and attribute values used by RSVP-TE</t>
          </list></t> RSVP-TE.</li>
        </ul>
        <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 type types of advertisements are to be
        sent/processed
        sent and processed on receive receipt for these applications. Further discussion
        of the associated issues can be found in <xref target="IBCMC"/>.</t> target="IBCMC"
	format="default"/>.</t>

        <t>New applications that future documents define to make use of the
        advertisements defined in this document MUST NOT <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"
               title="Use numbered="true" toc="default">
        <name>Use of Zero Length Zero-Length Application Identifier Bit Masks"> Masks</name>
        <t>Link attribute advertisements associated with zero length zero-length
        Application Identifier Bit Masks for both standard applications and
        user defined
        user-defined applications are usable by any application, subject to
        the restrictions specified in <xref target="ASLASUB"/>. target="ASLASUB" format="default"/>. If support for
        a new application is introduced on any node in a network in the
        presence of such advertisements, these advertisements are permitted to
        be used by the new application. If this is not what is intended, then
        existing advertisements MUST <bcp14>MUST</bcp14> be readvertised with an explicit set of
        applications specified before a new application is introduced.</t>
      </section>
      <section anchor="IBCMC"
               title="Interoperability, numbered="true" toc="default">
        <name>Interoperability, Backwards Compatibility Compatibility, and Migration Concerns"> Concerns</name>
        <t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the
        legacy advertisements listed in Section 3. <xref 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 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
        sub-sections
        subsections discuss interoperability and backwards compatibility backwards-compatibility
        concerns for a number of deployment scenarios.</t>
        <section anchor="MACARSVP"
                 title="Multiple numbered="true" toc="default">
          <name>Multiple Applications: Common Attributes with  RSVP-TE"> RSVP-TE</name>
          <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"
                 title="Multiple numbered="true" toc="default">
          <name>Multiple Applications: All Attributes Not Shared with RSVP-TE"> RSVP-TE</name>
          <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 MUST <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>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" title="Interoperability numbered="true" toc="default">
          <name>Interoperability with Legacy Routers"> Routers</name>
          <t>For the 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. So long as there
          is any legacy router in the network that has any of the applications
          enabled, all routers MUST <bcp14>MUST</bcp14> continue to advertise link attributes
          using legacy advertisements. In addition, the link attribute values
          associated with the set of applications supported by legacy routers
          (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy
          routers have no way of advertising or processing
          application-specific values. Once all legacy routers have been
          upgraded, migration from legacy advertisements to ASLA
          advertisements can be achieved via the following steps:</t>

          <t>1)Send
	  <ol type="%d)">

          <li>Send ASLA advertisements while continuing to advertise using
          legacy (all advertisements are then duplicated). Receiving routers
          continue to use legacy advertisements.</t>

          <t>2)Enable advertisements.</li>
          <li>Enable the use of the ASLA advertisements on all routers</t>

          <t>3)Remove routers.</li>
          <li>Remove legacy advertisements</t> advertisements.</li>
	  </ol>
          <t>When the migration is complete, it then becomes possible to
          advertise incongruent values per application on a given link.</t>
          <t>Note that the use of the L-flag is of no value in the
          migration.</t>
          <t>Documents defining new applications that make use of the
          application-specific advertisements defined in this document MUST <bcp14>MUST</bcp14>
          discuss interoperability and backwards compatibility backwards-compatibility issues that
          could occur in the presence of routers that do not support the new
          application.</t>
        </section>

        <section anchor="APPRSVP"
                 title="Use numbered="true" toc="default">
          <name>Use of Application-Specific Advertisements for RSVP-TE"> RSVP-TE</name>
          <t>The extensions defined in this document support include RSVP-TE as one of
          the supported applications. This allows that RSVP-TE could
          eventually utilize It is therefore possible, in the future, for
	  implementations to migrate to the use of application-specific advertisements.
	  advertisements in support of RSVP-TE. This can could
          be done in the following step-wise stepwise manner:</t>

          <t>1)Upgrade
	  <ol type="%d)">
          <li>Upgrade all routers to support the extensions in this
          document</t>

          <t>2)Advertise
          document.</li>
          <li>Advertise all legacy link attributes using ASLA advertisements
          with the L-flag clear and R-bit set. At this point point, both legacy and
          application-specific advertisements are being sent.</t>

          <t>3)Remove sent.</li>
          <li>Remove legacy advertisements</t> advertisements.</li>
	  </ol>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This section lists the protocol code point codepoint changes introduced by this
      document and the related IANA changes required.</t> updates made by IANA.</t>
      <t>For the new registries defined under IS-IS the "IS-IS TLV Codepoints Registry Codepoints" registry
      with the "Expert Review" registration procedure "Expert Review", (see Sections <xref
      target="IANA3" format="counter"/> and
      <xref target="IANA5" format="counter"/>), guidance for designated experts
      can be found in <xref target="RFC7370"/>.</t> target="RFC7370" format="default"/>.</t>
      <section anchor="IANA1"
               title="Application-Specific numbered="true" toc="default">
        <name>Application-Specific Link Attributes sub-TLV">
        <t>This document defines a Sub-TLV</name>
        <t>IANA has registered the new sub-TLV defined in
        <xref target="ASLASUB" format="default"/> in the Sub-TLVs "Sub-TLVs for TLVs
        22, 23, 25, 141, 222, and 223 registry. See <xref target="ASLASUB"/></t>

        <figure>
          <artwork><![CDATA[
 Type  Description             22   23   25  141  222  223
 ----  ---------------------  ---- ---- ---- ---- ---- ----
  16   Application-Specific     y    y  y(s)   y    y    y 223" registry.</t>
        <table>
	  <thead>
	  <tr>
		<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>16</td>
		<td>Application-Specific Link Attributes
]]></artwork>
        </figure> Attributes</td>
		<td>y</td>
		<td>y</td>
		<td>y(s)</td>
		<td>y</td>
		<td>y</td>
		<td>y</td>
	      </tr>
	    </tbody>
	</table>
        <t/>
      </section>
      <section anchor="IANA2" title="Application-Specific numbered="true" toc="default">
        <name>Application-Specific SRLG TLV">
        <t>This document defines one TLV</name>
        <t>IANA has registered the new TLV defined in <xref target="ASSRLGTLV"
	format="default"/> in the IS-IS TLV "TLV Codepoints
        Registry. See <xref target="ASSRLGTLV"/></t>

        <t><figure>
            <artwork><![CDATA[
 Type  Description             IIH LSP SNP Purge
 ----  ---------------------   --- --- --- -----
        Registry".
        </t>

        <table>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>  Description</th>
	      <th>IIH</th>
	      <th>LSP</th>
	      <th>SNP</th>
	      <th>Purge</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td> 238 </td>
	      <td> Application-Specific SRLG  </td>
	      <td> n </td>
	      <td> y </td>
	      <td> n </td>
	      <td> n
        SRLG
]]></artwork>
          </figure></t> </td>
	    </tr>
	  </tbody>
	</table>

      </section>
      <section anchor="IANA3"
               title="Application-Specific numbered="true" toc="default">
        <name>Sub-sub-TLV Codepoints for Application-Specific Link Attributes sub-sub-TLV Registry">
        <t>This document requests Registry</name>
        <t>IANA has created a new IANA registry titled "Sub-sub-TLV Codepoints for
        Application-Specific Link Attributes" under the IS-IS "IS-IS TLV
        Codepoints Registry be created
        Codepoints" registry to control the assignment of sub-sub-TLV
        codepoints for the Application-Specific Link Attributes sub-TLV
        defined in <xref target="IANA1"/>. The suggested name of the
        new registry is "sub-sub-TLV code points for application-specific link
        attributes". target="IANA1" format="default"/>.  The registration
        procedure is "Expert Review" as defined in <xref target="RFC8126"/>. target="RFC8126"
        format="default"/>. The following assignments are made by initial contents of this document:</t>

        <t><figure>
            <artwork><![CDATA[ Type   Description                          Encoding
                                             Reference
--------------------------------------------------------- registry are as follows:
        </t>
        <table>
	  <thead>
	    <tr>
	      <th>Type </th>
	      <th>Description</th>
	      <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	  <tr>
	    <td> 0-2 </td>
	    <td>  Unassigned </td>
	    <td/>
	    	  </tr>
	  <tr>
	    <td> 3 </td>
	    <td> Administrative group (color)         RFC5305 </td>
	    <td> <xref target="RFC5305"/> </td>
	     </tr>
	  <tr>
	    <td> 4-8 </td>
	    <td> Unassigned </td>
	     <td/>
	  </tr>
	  <tr>
	    <td> 9  </td>
	    <td> Maximum link bandwidth               RFC5305 bandwidth</td>
	    <td> <xref target="RFC5305"/> </td>
	      </tr>
	  <tr>
	    <td> 10 </td>
	    <td> Maximum reservable link bandwidth    RFC5305
11 </td>
	    <td> <xref target="RFC5305"/> </td>
	      </tr>
	  <tr>
	    <td>11 </td>
	    <td> Unreserved bandwidth                 RFC5305   </td>
	    <td> <xref target="RFC5305"/> </td>
	      </tr>
	  <tr>
	    <td> 12-13 </td>
	    <td> Unassigned
14 </td>
	     <td/>
	  </tr>
	  <tr>
	    <td>14 </td>
	    <td> Extended Administrative Group        RFC7308
15-17  </td>
	    <td> <xref target="RFC7308"/></td>
	      </tr>
	  <tr>
	    <td>15-17 </td>
	    <td> Unassigned
18 </td>
	     <td/>
	  </tr>
	  <tr>
	    <td>18 </td>
	    <td> TE Default Metric                    RFC5305  </td>
	    <td> <xref target="RFC5305"/></td>
	      </tr>
	  <tr>
	    <td> 19-32 </td>
	    <td> Unassigned </td>
	     <td/>

	      </tr>
	  <tr>
	    <td> 33 </td>
	    <td> Unidirectional Link Delay            RFC8570 </td>
	    <td> <xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td> 34 </td>
	    <td> Min/Max Unidirectional Link Delay    RFC8570 </td>
	    <td> <xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td> 35 </td>
	    <td> Unidirectional Delay Variation       RFC8570
36  </td>
	    <td> <xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td>36 </td>
	    <td> Unidirectional Link Loss             RFC8570
37      Unidirectional </td>
	    <td> <xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td>37 </td>
	    <td>Unidirectional Residual Bandwidth    RFC8570 </td>
	    <td> <xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td> 38      Unidirectional </td>
	    <td>Unidirectional Available Bandwidth   RFC8570
39      Unidirectional </td>
	    <td><xref target="RFC8570"/> </td>
	      </tr>
	  <tr>
	    <td>39 </td>
	    <td>Unidirectional Utilized Bandwidth    RFC8570
40-255 </td>
	    <td><xref target="RFC8570"/></td>
	      </tr>
	  <tr>
	    <td>40-255 </td>
	    <td> Unassigned
]]></artwork>
          </figure></t>

        <t>Note </td>
	     <td/>
	  </tr>
	</tbody>
	</table>

        <t>IANA has also added the following notes to IANA: this registry:</t>

<t 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 MUST <bcp14>MUST</bcp14> be to the document that
        defines the encoding.</t>

        <t>Note to designated experts:
        <t indent="3">Note: If a link attribute can be advertised
        both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a
        sub-sub-TLV of the Application-Specific Link Attributes sub-TLV
        defined in this document, RFC 8919, then the same numerical code should be
        assigned to the link attribute whenever possible.</t>
      </section>
      <section anchor="IANA4"
               title="Link numbered="true" toc="default">
        <name>Link Attribute Application Identifier Registry">
        <t>This document requests Identifiers Registry</name>
        <t>IANA has created a new IANA registry be created, titled "Link Attribute
        Application Identifiers" under the
        category of "Interior Gateway Protocol (IGP) Parameters", Parameters" registry
        to control the assignment of Application Identifier Bits.  The suggested name of
        the new registry is "Link Attribute Applications". The
        registration policy for this registry is "Expert Review" as defined in
        <xref target="RFC8126"/>. target="RFC8126" format="default"/>.  Bit definitions SHOULD
        <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 following assignments are made by initial contents of this document:</t>

        <t><figure>
            <artwork><![CDATA[ Bit registry are as follows:
</t>
        <table>
	  <thead>
	    <tr>
	      <th>Bit #   Name
---------------------------------------------------------
  0 </th>
	      <th>Name</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td> 0</td>
	      <td> RSVP-TE (R-bit)
  1 (R-bit)</td>
	    </tr>
	    <tr>
	      <td>1</td>
	      <td> Segment Routing Policy (S-bit)
  2      Loop Free (S-bit)</td>
	    </tr>
	    <tr>
	      <td>2</td>
	      <td> Loop-Free Alternate (F-bit)
  3-63   Unassigned
  ]]></artwork>
          </figure></t> (F-bit)</td>
	    </tr>
	    <tr>
	      <td>3-63</td>
	      <td> Unassigned</td>
	    </tr>
	  </tbody>
	</table>

      </section>
      <section anchor="IANA5" title="SRLG sub-TLVs">
        <t>This document requests numbered="true" toc="default">
        <name>Sub-TLVs for TLV 238 Registry</name>
        <t>IANA has created a new IANA registry be created titled "Sub-TLVs for TLV 238" under
        the
        IS-IS "IS-IS TLV Codepoints Registry Codepoints" registry to control the assignment of
        sub-TLV types for the application-specific Application-Specific SRLG TLV.  The suggested name of the
        new registry is "Sub-TLVs for TLV 238". The registration
        procedure is "Expert Review" as defined in <xref target="RFC8126"/>. target="RFC8126"
        format="default"/>. The following
        assignments are made by initial contents of this document:</t>

        <t><figure>
            <artwork><![CDATA[ Value    Description                    Encoding
                                         Reference
 ---------------------------------------------------------
  0-3     Unassigned
   4 registry are as follows:
        </t>
        <table>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Description</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>0-3 </td>
	      <td>Unassigned </td>
	       <td/>

	    </tr>
	    <tr>
	      <td>4 </td>
	      <td> Link Local/Remote Identifiers  [RFC5307]
   5 </td>
	      <td> <xref target="RFC5307"/> </td>
	    </tr>
	    <tr>
	         <td>5 </td>
		 <td>  Unassigned
   6 </td>
		  <td/>

	    </tr>
	    <tr>
	      <td>6 </td>
	      <td> IPv4 interface address         [RFC5305]
   7      Unassigned
   8 </td>
	      <td> <xref target="RFC5305"/> </td>
	    </tr>
	    <tr>
	         <td>7 </td>
		 <td>Unassigned </td>
		  <td/>
	    </tr>
	    <tr>
	      <td>8 </td>
	      <td> IPv4 neighbor address          [RFC5305]
  9-11    Unassigned
  12  </td>
	      <td> <xref target="RFC5305"/> </td>
	    </tr>
	    <tr>
	         <td>9-11 </td>
		 <td>Unassigned </td>
		  <td/>

	    </tr>
	    <tr>
	      <td>12 </td>
	      <td> IPv6 Interface Address         [RFC6119]
  13 </td>
	      <td> <xref target="RFC6119"/> </td>
	    </tr>
	    <tr>
	         <td>13 </td>
	      <td> IPv6 Neighbor Address          [RFC6119]
 14-255  </td>
	      <td> <xref target="RFC6119"/> </td>
	    </tr>
	    <tr>
	      <td>14-255 </td>
	      <td> Unassigned
]]></artwork>
          </figure>Note </td>
	       <td></td>

	    </tr>
	  </tbody>
	</table>

<t>IANA has also added the following note to IANA: this registry:</t>

        <t 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 MUST <bcp14>MUST</bcp14> be to the
        document that defines the encoding.</t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security concerns for IS-IS are addressed in <xref
      target="ISO10589"/>, target="ISO10589" format="default"/>, <xref target="RFC5304"/>, target="RFC5304" format="default"/>, and <xref
      target="RFC5310"/>. target="RFC5310" format="default"/>. 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 SHOULD <bcp14>SHOULD</bcp14> be used.</t>
      <t>This document defines a new 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 traffic engineering
      as discussed in <xref target="RFC8570"/>. target="RFC8570" format="default"/>. 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="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Eric Rosen and Acee Lindem for their
      careful review and content suggestions.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

<displayreference target="I-D.ietf-spring-segment-routing-policy" to="SEGMENT-ROUTING"/>

 <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="ISO10589">
          <front>
          <title>Intermediate system
            <title>Information technology - Telecommunications and information
	    exchange between systems - Intermediate System to Intermediate system
	    System intra-domain
          routeing routing information exchange protocol for use
	    in conjunction with the protocol for providing the
	    connectionless-mode Network Service network service (ISO 8473)</title>
            <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
            <author>
              <organization abbrev="ISO">International Organization for
            Standardization</organization>
            </author>
            <date month="Nov" year="2002"/>
          </front>

        <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
        </reference>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.8126'?>

      <?rfc include='reference.RFC.5304'?>

      <?rfc include='reference.RFC.5305'?>

      <?rfc include='reference.RFC.5307'?>

      <?rfc include='reference.RFC.5310'?>

      <?rfc include='reference.RFC.6119'?>

      <?rfc include='reference.RFC.7308'?>

      <?rfc include='reference.RFC.7370'?>

      <?rfc include='reference.RFC.8570'?>

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

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?>

      <?rfc include="reference.RFC.3209"?>

      <?rfc include="reference.RFC.5286"?>

      <?rfc include='reference.RFC.7855'?>

      <?rfc ?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Eric Rosen"/> and
      <contact fullname="Acee Lindem"/> for their careful review and content
      suggestions.</t>
    </section>

  </back>
</rfc>