<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="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" ipr="trust200902" docName="draft-ietf-ospf-te-link-attr-reuse-16.txt">
     docName="draft-ietf-ospf-te-link-attr-reuse-16" number="8920"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3">

   <front>
     <title abbrev="OSPF App-Specific Link TE Attributes Reuse">OSPF Attributes">OSPF Application-Specific Link Attributes</title>
     <seriesInfo name="RFC" value="8920"/>
     <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak">
       <organization>Cisco Systems</organization>
       <address>
	 <postal>
          <street>Eurovea
	   <extaddr>Eurovea Centre, Central 3</street> 3</extaddr>
	   <street>Pribinova Street 10</street>
	   <city>Bratislava</city>
	   <code>81109</code>
	   <country>Slovakia</country>
	 </postal>
	 <email>ppsenak@cisco.com</email>
       </address>
     </author>
     <author initials='L.' initials="L." surname="Ginsberg" fullname='Les Ginsberg'> fullname="Les Ginsberg">
       <organization>Cisco Systems</organization>
       <address>
	 <postal>
	   <street>821 Alder Drive</street>
        <city> MILPITAS</city>
	   <city>Milpitas</city>
	   <region>CA</region>
        <country>USA</country>
	   <country>United States of America</country>
	   <code>95035</code>
	 </postal>
	 <email>ginsberg@cisco.com</email>
       </address>
     </author>
     <author initials='W.' initials="W." surname="Henderickx" fullname='Wim Henderickx'> fullname="Wim Henderickx">
       <organization>Nokia</organization>
       <address>
	 <postal>
	   <street>Copernicuslaan 50</street>
        <city>Antwerp</city><region>2018</region>
	   <city>Antwerp</city>
	   <country>Belgium</country>
        <code>94089</code>
	   <code>2018 94089</code>
	 </postal>
	 <email>wim.henderickx@nokia.com</email>
       </address>
     </author>
     <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
       <organization>Apstra</organization>
       <address>
	 <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>US</country>
	   <street/>
	   <city/>
	   <region/>
	   <code/>
	   <country>United States of America</country>
	 </postal>
	 <email>jefftant.ietf@gmail.com</email>
       </address>
     </author>
     <author fullname="John Drake" initials="J." surname="Drake">
       <organization>Juniper Networks</organization>
       <address>
	 <postal>
	   <street>1194 N. Mathilda Ave</street>
	   <city>Sunnyvale</city>
	   <region>California</region>
	   <code>94089</code>

        <country>USA</country>
	   <country>United States of America</country>
	 </postal>
	 <email>jdrake@juniper.net</email>
       </address>
     </author>

<date/>
     <date year="2020" month="October" />
     <area>Routing</area>
     <workgroup>LSR Working Group</workgroup>
     <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) have been
   defined Policy and Loop-Free Alternates) that also make use of the
    link attribute advertisements. advertisements have been defined.  In
    cases where multiple applications wish to make use of these link
   attributes
    attributes, the current advertisements do not support application
   specific application-specific values for a given attribute attribute, nor do they support indication
    of which applications are using the advertised value for a given
    link.  This document introduces new link attribute advertisements in OSPFv2
       and OSPFv3 that address both of these shortcomings.</t>
     </abstract>
   </front>
   <middle>
     <section title="Introduction"> numbered="true" toc="default">
       <name>Introduction</name>
       <t>Advertisement of link attributes by the OSPFv2 <xref target="RFC2328"/>
       target="RFC2328" format="default"/> and OSPFv3 <xref target="RFC5340"/> target="RFC5340"
       format="default"/> protocols in support of traffic engineering (TE) was
       introduced by <xref target="RFC3630"/> target="RFC3630" format="default"/> and <xref target="RFC5329"/>
       target="RFC5329" format="default"/>, respectively. It has been extended
       by <xref target="RFC4203"/>, target="RFC4203" format="default"/>, <xref target="RFC7308"/> target="RFC7308"
       format="default"/>, and <xref target="RFC7471"/>. target="RFC7471" format="default"/>.  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, examples of which are
       listed in <xref target="ADVAPPVAL"/>.</t> target="ADVAPPVAL" format="default"/>.</t>

       <t>In recent years years, new applications have been introduced that have use
       cases for many of the link attributes historically used by RSVP-TE.
       Such applications include Segment Routing (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 in that
       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 the 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 for the introduction of new applications and new
    use cases.</t>

</section>

     <section title="Requirements Language"> numbered="true" toc="default">

       <name>Requirements Language</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
   "OPTIONAL"
    "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
   BCP 14
    BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> 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 OSPF, 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"/> 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="LEG_ADV" title="Existing numbered="true" toc="default">
       <name>Existing Advertisement of Link Attributes"> Attributes</name>
       <t>There are existing advertisements used in support of RSVP-TE.  These
       advertisements are carried in the OSPFv2 TE Opaque LSA Link State
       Advertisement (LSA) <xref target="RFC3630"/> target="RFC3630" format="default"/> and
       OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/>. target="RFC5329"
       format="default"/>. Additional RSVP-TE link attributes have been
       defined by <xref target="RFC4203"/>, target="RFC4203" format="default"/>, <xref target="RFC7308"/>
       target="RFC7308" format="default"/>, and <xref target="RFC7471"/>.</t> target="RFC7471"
       format="default"/>.</t>
       <t>Extended Link Opaque LSAs as defined in <xref target="RFC7684"/> target="RFC7684" format="default"/> for OSPFv2 and
 Extended Router-LSAs
  E-Router-LSAs <xref target="RFC8362"/> target="RFC8362" format="default"/> for OSPFv3 are used to advertise link
  attributes that are used by applications other than RSVP-TE or GMPLS <xref target="RFC4203"/>. target="RFC4203" format="default"/>.
  These LSAs were defined as a generic containers for distribution of the extended link attributes.</t>
     </section>
     <section title="Advertisement numbered="true" toc="default">
       <name>Advertisement of Link Attributes"> Attributes</name>
       <t>This section outlines the solution for advertising link attributes
   originally defined for RSVP-TE or GMPLS when they are used for other applications.</t>
       <section title="OSPFv2 numbered="true" toc="default">
	 <name>OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA">

  <t>Advantages E-Router-LSA</name>
	 <t>The following are the advantages of Extended Link Opaque LSAs as defined in <xref target="RFC7684"/> target="RFC7684" format="default"/>
   for OSPFv2 and Extended Router-LSAs E-Router-LSAs <xref target="RFC8362"/> target="RFC8362" format="default"/> for OSPFv3 with respect
   to the advertisement of link attributes originally defined for RSVP-TE when used in packet
   networks and in GMPLS:
   <list style="numbers">

    <t>Advertisement
	 </t>
	 <ol spacing="normal" type="1">
	   <li>Advertisement of the link attributes does not make the link part of the RSVP-TE topology.
      It avoids any conflicts and is fully compatible with <xref target="RFC3630"/> target="RFC3630" format="default"/> and
      <xref target="RFC5329"/>.</t>

    <t>The target="RFC5329" format="default"/>.</li>
	   <li>The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains remain
	   truly opaque to OSPFv2 and OSPFv3 as originally defined in <xref target="RFC3630"/>
	   target="RFC3630" format="default"/> and <xref target="RFC5329"/> target="RFC5329"
	   format="default"/>, respectively. Their contents are not inspected
	   by OSPF, which instead acts as a pure
    transport.</t>

    <t>There transport.</li>
	   <li>There is a clear distinction between link attributes used by RSVP-TE and
	link attributes used by other OSPFv2 or OSPFv3 applications.</t>

    <t>All applications.</li>
	   <li>All link attributes that are used by other applications are advertised in
       a single LSA, the Extended Link Opaque LSA in OSPFv2 <xref
	target="RFC7684" format="default"/> or the OSPFv3
	E-Router-LSA <xref target="RFC8362"/> target="RFC8362" format="default"/> in OSPFv3.</t>
  </list></t> OSPFv3.</li>
	 </ol>
	 <t>The disadvantage of this approach is that in rare cases, the same link attribute is
    advertised in both the TE Opaque and Extended Link Attribute LSAs in OSPFv2 or
    the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.</t>

  <t>Extended
	 <t>The Extended Link Opaque LSA <xref target="RFC7684"/> target="RFC7684"
	 format="default"/> and E-Router-LSA
   <xref target="RFC8362"/> target="RFC8362" format="default"/> are used to advertise any link attributes used
   for non-RSVP-TE applications in OSPFv2 or OSPFv3 OSPFv3, respectively, including those that have
   been originally defined for RSVP-TE applications (See (see <xref target="REUSED_ATTR"/>).</t> target="REUSED_ATTR" format="default"/>).</t>
	 <t>TE link attributes used for RSVP-TE/GMPLS continue to use the OSPFv2 TE Opaque LSA
   <xref target="RFC3630"/> target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/>.</t> target="RFC5329" format="default"/>.</t>
	 <t>The format of the link attribute TLVs that have been defined for
	 RSVP-TE applications will be kept unchanged even when they are used
	 for non-RSVP-TE applications. Unique code
  points codepoints are allocated for
	 these link attribute TLVs from the
  OSPFv2 "OSPFv2 Extended Link TLV Sub-TLV Registry Sub-TLVs"
	 registry <xref target="RFC7684"/> target="RFC7684" format="default"/> and from the
  OSPFv3
	 "OSPFv3 Extended-LSA Sub-TLV Registry Sub-TLVs" registry <xref target="RFC8362"/>, target="RFC8362"
	 format="default"/>, as specified in <xref target="IANA"/>.</t> target="IANA"
	 format="default"/>.</t>
       </section>
     </section>
     <section anchor="ADVAPPVAL" title="Advertisement numbered="true" toc="default">
       <name>Advertisement of Application-Specific Values"> Values</name>
       <t>To allow advertisement of the application-specific values of the link attribute, a new
 Application-Specific Link Attributes (ASLA) sub-TLV is defined.  The ASLA sub-TLV is a sub-TLV
 of the OSPFv2 Extended Link TLV <xref target="RFC7684"/> target="RFC7684" format="default"/> and OSPFv3 Router-Link TLV
 <xref target="RFC8362"/>.</t>

<t>On top of target="RFC8362" format="default"/>.</t>

      <t>In addition to advertising the link attributes for standardized
   applications, link attributes can be advertised for the purpose of
   applications that are not standardized.  We call such an
   application a "User Defined Application" "user-defined application" or "UDA".  These applications are
   not subject to standardization and are outside of the scope
   of this specification.</t>
      <t>The ASLA sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV and
OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in its a parent
TLV when different applications want to control different link attributes or
when a different value
of the same attribute needs to be advertised by multiple applications. The ASLA sub-TLV
MUST
<bcp14>MUST</bcp14> be used for advertisement of the link attributes listed at the end on of this section
if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV.
It has the following format:
<figure>
    <artwork>
</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SABM Length  |  UDABM Length |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Standard Application Identifier Bit Mask            |
+-                                                             -+
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           User Defined           User-Defined Application Identifier Bit Mask        |
+-                                                             -+
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Link Attribute sub-sub-TLVs              |
+-                                                             -+
|                            ...                                |

where:
    </artwork>
</figure>
          <list style="hanging">
            <t>Type:
]]></artwork>

      <t> where:</t>

      <dl newline="false">

        <dt>Type:</dt><dd> 10 (OSPFv2), 11 (OSPFv3)</t>

            <t>Length: variable</t>

            <t>SABM Length: (OSPFv3)</dd>

        <dt>Length:</dt><dd> Variable</dd>

        <dt>SABM Length:</dt><dd> Standard Application Identifier Bit Mask Length in octets.
            The value MUST <bcp14>MUST</bcp14> be 0, 4 4, or 8.
            If the Standard Application Identifier Bit Mask is not present, the Standard
            Application Bit Mask SABM
            Length MUST <bcp14>MUST</bcp14> be set to 0.</t>

            <t>UDABM Length: User Defined 0.</dd>

        <dt>UDABM Length:</dt><dd> User-Defined Application Identifier Bit Mask Length in octets.
            The value MUST <bcp14>MUST</bcp14> be 0, 4 4, or 8.
            If the User Defined User-Defined Application Identifier Bit Mask is not present, the User Defined
            Application Bit Mask
            UDABM Length MUST <bcp14>MUST</bcp14> be set to 0.</t>

            <t>Standard 0.</dd>

          <dt>Standard Application Identifier Bit Mask: Optional Mask:</dt><dd><t>Optional
          set of bits, where each bit represents a single standard
          application. Bits are defined in the Link "Link Attribute Application Identifier Registry, Applications"
          registry, which has been is defined in <xref target="I-D.ietf-isis-te-app"/>. target="RFC8919"
          format="default"/>.  Current assignments are repeated here for
          informational purpose:
             <figure>
             <artwork> purposes:</t>

          <artwork name="" type="" align="left" alt=""><![CDATA[
                 0 1 2 3 4 5 6 7 ...
                +-+-+-+-+-+-+-+-+...
                |R|S|F|          ...
                +-+-+-+-+-+-+-+-+...
             </artwork>
             </figure>
             <list style="hanging">
                <t>Bit-0 (R-bit): RSVP-TE</t>

                <t>Bit-1 (S-bit):
]]></artwork>

          <dl newline="false" spacing="normal">

            <dt>Bit 0 (R-bit):</dt><dd> RSVP-TE.</dd>

            <dt>Bit 1 (S-bit):</dt><dd> Segment Routing Policy</t>

                <t>Bit-2 (F-bit): Loop Free Policy.</dd>

            <dt>Bit 2 (F-bit):</dt><dd> Loop-Free Alternate (LFA). Includes all LFA types</t>

              </list></t>

            <t>User Defined types.</dd>
	  </dl>
	</dd>

            <dt>User-Defined Application Identifier Bit Mask: Mask:</dt><dd> Optional set of bits, where each bit
        represents a single user defined application.</t>
    </list></t> user-defined application.</dd>
	  </dl>

      <t>If the SABM or UDABM length Length is other than 0, 4, or 8, the ASLA sub-TLV MUST <bcp14>MUST</bcp14> be ignored
by the receiver.</t>
      <t>Standard Application Identifier Bits are defined/sent defined and sent starting with
   Bit
   bit 0.  Undefined bits that are transmitted MUST <bcp14>MUST</bcp14> be transmitted as 0 and MUST <bcp14>MUST</bcp14> be ignored
   on receipt.  Bits that are not transmitted MUST <bcp14>MUST</bcp14> be treated as if they
   are set to 0 on receipt.  Bits that are not supported by an
   implementation MUST <bcp14>MUST</bcp14> be ignored on receipt.</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 these bits are be used
   starting with Bit bit 0 so as to minimize the number of octets required
   to advertise all UDAs. Undefined bits which that are transmitted MUST <bcp14>MUST</bcp14> be
   transmitted as 0 and MUST <bcp14>MUST</bcp14> be ignored on receipt. Bits that are not
   transmitted MUST <bcp14>MUST</bcp14> be treated as if they are set to 0 on receipt.  Bits that are not
   supported by an implementation MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>
      <t>If the link attribute advertisement is intended to be only used by a specific set of applications,
corresponding Bit Masks MUST bit masks <bcp14>MUST</bcp14> be present present, and application-specific bit(s) MUST <bcp14>MUST</bcp14> be set for all
applications that use the link attributes advertised in the ASLA sub-TLV.</t>
      <t>Application Identifier Bit Masks apply to all link attributes that support application-specific
values and are advertised in the ASLA sub-TLV.</t>
      <t>The advantage of not making the Application Identifier Bit Masks part of the attribute advertisement
itself is that the format of any previously defined link attributes
can be kept and reused when advertising them in the ASLA sub-TLV.</t>
      <t>If the same attribute is advertised in more than one ASLA sub-TLVs with the application
listed in the Application Identifier Bit Masks, the application SHOULD <bcp14>SHOULD</bcp14> use the first instance of
advertisement and ignore any subsequent advertisements of that attribute.</t>
      <t>If link attributes are advertised 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. 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>
      <t>An application-specific advertisement (Application Identifier Bit
    Mask with a matching Application Identifier Bit set) for an attribute
    MUST
    <bcp14>MUST</bcp14> always be preferred over the advertisement of the same attribute
    with the zero length zero-length Application Identifier Bit Masks for both
    standard applications and user defined user-defined applications on the same link.</t>
      <t>This document defines the initial set of link attributes that MUST <bcp14>MUST</bcp14> use the ASLA sub-TLV if
advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV.
Documents which that define new link attributes MUST <bcp14>MUST</bcp14> state whether the new attributes support
application-specific values and and, as such such, are advertised in an ASLA sub-TLV. The standard
link attributes that are advertised in ASLA sub-TLVs are:

 <list style="hanging">
     <t>-

      </t>
      <ul>

        <li> Shared Risk Link Group <xref target="RFC4203"/></t>
     <t>- target="RFC4203" format="default"/></li>

        <li> Unidirectional Link Delay <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Min/Max Unidirectional Link Delay <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Unidirectional Delay Variation <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Unidirectional Link Loss <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Unidirectional Residual Bandwidth <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Unidirectional Available Bandwidth <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Unidirectional Utilized Bandwidth <xref target="RFC7471"/></t>
     <t>- target="RFC7471" format="default"/></li>

        <li> Administrative Group <xref target="RFC3630"/></t>
     <t>- target="RFC3630" format="default"/></li>

        <li> Extended Administrative Group <xref target="RFC7308"/></t>
     <t>- target="RFC7308" format="default"/></li>

        <li> TE Metric <xref target="RFC3630"/></t>
    </list></t> target="RFC3630" format="default"/></li>
      </ul>
    </section>
    <section anchor="REUSED_ATTR" title="Reused numbered="true" toc="default">
      <name>Reused TE link attributes"> Link Attributes</name>
      <t>This section defines the use case and indicates the code points codepoints (<xref target="IANA"/>)
      target="IANA" format="default"/>) from the OSPFv2 "OSPFv2 Extended Link TLV Sub-TLV Registry
      Sub-TLVs" registry and OSPFv3 "OSPFv3 Extended-LSA Sub-TLV
  Registry Sub-TLVs" registry for some of
      the link attributes that have been originally defined for RSVP-TE or
      GMPLS.</t>

      <section anchor ="SRLG" title="Shared anchor="SRLG" numbered="true" toc="default">
        <name>Shared Risk Link Group (SRLG)"> (SRLG)</name>
        <t>The SRLG of a link can be used in OSPF calculated OSPF-calculated IPFRR (IP Fast Reroute)
   <xref target="RFC5714"/> target="RFC5714" format="default"/> to compute a backup path
  that does not share any SRLG group with the protected link.</t>

        <t>To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, the same format
   for the sub-TLV defined in section 1.3 of <xref target="RFC4203"/> target="RFC4203"
   sectionFormat="of" section="1.3"/> is used and with TLV
   type 11 is used. 11. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Router-Link
   TLV, TLV type 12 is used.</t>
      </section>
      <section title="Extended Metrics"> numbered="true" toc="default">
        <name>Extended Metrics</name>
        <t><xref target="RFC3630"/> target="RFC3630" format="default"/> defines several link bandwidth types. <xref target="RFC7471"/> target="RFC7471" format="default"/>
  defines extended link metrics that are based on link bandwidth, delay delay, and loss
  characteristics. All of these can be used to compute primary and backup paths within an
  OSPF area to satisfy requirements for bandwidth, delay (nominal or worst case) case), or loss.</t>
        <t>To advertise extended link metrics in the OSPFv2 Extended Link TLV, the same format
    for the sub-TLVs defined in <xref target="RFC7471"/> target="RFC7471" format="default"/> is used with the following
    TLV types:
    <list style="hanging">
     <t>12 -
        </t>
        <dl>

          <dt>12:</dt><dd> Unidirectional Link Delay</t>
     <t>13 - Delay</dd>

          <dt>13:</dt><dd> Min/Max Unidirectional Link Delay</t>
     <t>14 - Delay</dd>

          <dt>14:</dt><dd> Unidirectional Delay Variation</t>
     <t>15 - Variation</dd>

          <dt>15:</dt><dd> Unidirectional Link Loss</t>
     <t>16 - Loss</dd>

          <dt>16:</dt><dd> Unidirectional Residual Bandwidth</t>
     <t>17 - Bandwidth</dd>

          <dt>17:</dt><dd> Unidirectional Available Bandwidth</t>
     <t>18 - Bandwidth</dd>

          <dt>18:</dt><dd> Unidirectional Utilized Bandwidth</t>
    </list></t> Bandwidth</dd>
        </dl>
        <t>To advertise extended link metrics in the OSPFv3 Extended-LSA Router-Link TLV, TLV inside
	the OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in <xref target="RFC7471"/> target="RFC7471" format="default"/> is used with the following
    TLV types:
    <list style="hanging">
     <t>13 -
        </t>
        <dl>

          <dt>13:</dt><dd> Unidirectional Link Delay</t>
     <t>14 - Delay</dd>

          <dt>14:</dt><dd> Min/Max Unidirectional Link Delay</t>
     <t>15 - Delay</dd>

          <dt>15:</dt><dd> Unidirectional Delay Variation</t>
     <t>16 - Variation</dd>

          <dt>16:</dt><dd> Unidirectional Link Loss</t>
     <t>17 - Loss</dd>

          <dt>17:</dt><dd> Unidirectional Residual Bandwidth</t>
     <t>18 - Bandwidth</dd>

          <dt>18:</dt><dd> Unidirectional Available Bandwidth</t>
     <t>19 - Bandwidth</dd>

          <dt>19:</dt><dd> Unidirectional Utilized Bandwidth</t>
    </list></t> Bandwidth</dd>
        </dl>
      </section>
      <section title="Administrative Group"> numbered="true" toc="default">
        <name>Administrative Group</name>
        <t><xref target="RFC3630"/> target="RFC3630" format="default"/> and <xref target="RFC7308"/> target="RFC7308" format="default"/> define the Administrative Group and
  Extended Administrative Group sub-TLVs sub-TLVs, respectively.</t>
        <t>To advertise the Administrative Group and Extended Administrative Group in the OSPFv2
    Extended Link TLV, the same format for the sub-TLVs defined in <xref target="RFC3630"/> target="RFC3630" format="default"/>
    and <xref target="RFC7308"/> target="RFC7308" format="default"/> is used with the following TLV types:

    <list style="hanging">
     <t>19 -

        </t>
        <dl>

          <dt>19:</dt><dd>  Administrative Group</t>
     <t>20 - Group</dd>

          <dt>20:</dt><dd> Extended Administrative Group</t>
    </list></t> Group</dd>
        </dl>
        <t>To advertise the Administrative Group and Extended Administrative Group in the OSPFv3
    Router-Link TLV, the same format for the sub-TLVs defined in <xref target="RFC3630"/> target="RFC3630" format="default"/>
    and <xref target="RFC7308"/> target="RFC7308" format="default"/> is used with the following TLV types:

    <list style="hanging">
     <t>20 -

        </t>
        <dl>

          <dt>20:</dt><dd>  Administrative Group</t>
     <t>21 - Group</dd>

          <dt>21:</dt><dd> Extended Administrative Group</t>
    </list></t> Group</dd>
        </dl>
      </section>
      <section title="Traffic numbered="true" toc="default">
        <name>Traffic Engineering Metric"> Metric</name>
        <t><xref target="RFC3630"/> target="RFC3630" format="default"/> defines the Traffic Engineering Metric.</t>
        <t>To advertise the Traffic Engineering Metric in the OSPFv2 Extended Link TLV,
  the same format for the sub-TLV defined in section 2.5.5 of <xref target="RFC3630"/>
  target="RFC3630" sectionFormat="of" section="2.5.5"/>
  is used and with TLV type 22 is used. 22. Similarly, for OSPFv3 to advertise the
  Traffic Engineering Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used.</t>
      </section>
    </section>
    <section anchor="SPECIALMAXBANDW" title="Maximum numbered="true" toc="default">
      <name>Maximum Link Bandwidth"> Bandwidth</name>

      <t>Maximum link bandwidth is an application independent application-independent attribute of the
  link that is defined in <xref target="RFC3630"/>. target="RFC3630" format="default"/>. Because
  it is an application
  independent application-independent attribute, it MUST NOT <bcp14>MUST NOT</bcp14> be
  advertised in the ASLA sub-TLV.

Instead, it MAY <bcp14>MAY</bcp14> be
  advertised as a sub-TLV of the Extended Link Opaque LSA TLV in the Extended Link TLV Opaque
  LSA in OSPFv2 <xref target="RFC7684"/> target="RFC7684" format="default"/> or as a sub-TLV of OSPFv3
  the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3
  <xref target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
      <t>To advertise the Maximum maximum link bandwidth in the OSPFv2 Extended Link TLV, the same
  format for the sub-TLV defined in <xref target="RFC3630"/> target="RFC3630" format="default"/> is used with
  TLV type 23.</t>
      <t>To advertise the Maximum maximum link bandwidth in the OSPFv3 Router-Link TLV, the same
  format for the sub-TLV defined in <xref target="RFC3630"/> target="RFC3630" format="default"/> is used with
  TLV type 23.</t>
    </section>
    <section anchor="EXT_METRICS" title="Considerations numbered="true" toc="default">
      <name>Considerations for Extended TE Metrics"> Metrics</name>
      <t><xref target="RFC7471"/> target="RFC7471" 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 can 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 anchor="LOCALIPV6ADDR" title="Local numbered="true" toc="default">
      <name>Local Interface IPv6 Address Sub-TLV"> Sub-TLV</name>
      <t>The Local Interface IPv6 Address Sub-TLV sub-TLV is an application independent application-independent attribute of the
  link that is defined in <xref target="RFC5329"/>. target="RFC5329" format="default"/>. Because it is an application
  independent application-independent attribute, it MUST NOT <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub-TLV.  Instead, it MAY <bcp14>MAY</bcp14> be
  advertised as a sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV inside the OSPFv3 E-Router-LSA <xref target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
      <t>To advertise the Local Interface IPv6 Address Sub-TLV sub-TLV in the OSPFv3 Router-Link TLV,
  the same format for the sub-TLV defined in <xref target="RFC5329"/> target="RFC5329" format="default"/> is used with
  TLV type 24.</t>
    </section>
    <section anchor="REMOTEIPV6ADDR" title="Remote numbered="true" toc="default">
      <name>Remote Interface IPv6 Address Sub-TLV"> Sub-TLV</name>
      <t>The Remote Interface IPv6 Address Sub-TLV sub-TLV is an application independent application-independent attribute of the
  link that is defined in <xref target="RFC5329"/>. target="RFC5329" format="default"/>. Because it is an application
  independent application-independent attribute, it MUST NOT <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub-TLV. Instead, it MAY <bcp14>MAY</bcp14> be
  advertised as a sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV inside the OSPFv3 E-Router-LSA <xref target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
      <t>To advertise the Remote Interface IPv6 Address Sub-TLV sub-TLV in the OSPFv3 Router-Link TLV,
  the same format for the sub-TLV defined in <xref target="RFC5329"/> target="RFC5329" format="default"/> is used with
  TLV type 25.</t>
    </section>
    <section 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>There are applications where the application enablement on the link
      is relevant -
   e.g., RSVP-TE - relevant; for example, with RSVP-TE, one needs to make sure that RSVP
      is enabled on the link before sending a an RSVP-TE signaling message over it.</t>
      <t>There are applications where the enablement of the application on the link is
   irrelevant and has nothing to do with the fact that some link attributes are advertised
   for the purpose of such application. An example of this is LFA.</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 has no implication of RSVP-TE being enabled on that link.
   The RSVP-TE enablement is solely derived from the information carried in
   the OSPFv2 TE Opaque LSA  <xref target="RFC3630"/> target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA
   <xref target="RFC5329"/>.</t> target="RFC5329" format="default"/>.</t>
      <t>In the case of SR Policy, advertisement of application-specific link
   attributes does not indicate enablement of SR Policy.  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> 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 (see <xref target="ADVAPPVAL"/>). target="ADVAPPVAL" format="default"/>).
   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 title="Deployment Considerations"> numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <section anchor="LEGACY_OSPF" title="Use numbered="true" toc="default">
        <name>Use of Legacy RSVP-TE LSA Advertisements"> Advertisements</name>
        <t>Bit Identifiers identifiers for Standard Applications standard applications are defined in <xref target="ADVAPPVAL"/>. target="ADVAPPVAL" 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 RSVP-TE LSA advertisements.  The Standard Applications standard applications
   defined in this document may continue to use RSVP-TE LSA advertisements
   for a given link so long as at least one of the following conditions
   is true:

   <list style="hanging">

    <t>The

        </t>
        <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 RSVP-TE LSA
   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/ 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 RSVP-TE LSA
   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="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 <xref target="LEG_ADV"/>. target="LEG_ADV" format="default"/>. Routers which 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 for RSVP-TE.
          Attributes for applications other than RSVP-TE MUST <bcp14>MUST</bcp14> be advertised using
          application-specific advertisements. This results in duplicate
          advertisements for those attributes.</t>
        </section>
        <section anchor="MAALLNS"
                 title="Multiple numbered="true" toc="default">
          <name>Multiple Applications: Some 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, interoperability is achieved by using legacy advertisements
          for RSVP-TE. Attributes for applications other than RSVP-TE MUST <bcp14>MUST</bcp14> be advertised using
          application-specific advertisements. In cases where some link attributes are
          shared with RSVP-TE, this requires duplicate advertisements for those attributes</t> attributes.</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 application
          specific
	   application-specific advertisements can be achieved via the
	   following steps:</t>

          <t>1)Send
 <ol type="%d)">
	   <li>Send new application-specific advertisements while continuing to
	   advertise using the legacy advertisement (all advertisements are
	   then duplicated). Receiving routers continue to use legacy advertisements.</t>

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

          <t>3)Keep routers.</li>
	   <li>Keep legacy advertisements if needed for RSVP-TE purposes.</t> purposes.</li>
 </ol>
          <t>When the migration is complete, it then becomes possible to
          advertise incongruent values per application on a given link.</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 RSVP-TE as one of
          the supported applications. It is however RECOMMENDED is, however, <bcp14>RECOMMENDED</bcp14> to advertise all
          link-attributes
          link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
          <xref target="RFC3630"/> target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/> target="RFC5329" format="default"/>
          to maintain backward backwards compatibility. RSVP-TE can eventually
          utilize the application-specific advertisements for newly defined
	  link attributes, attributes that are defined as application-specific.</t> application specific.</t>
          <t>Link attributes that are not allowed to be advertised in the ASLA Sub-TLV, sub-TLV,
          such as Maximum Reservable Link Bandwidth maximum reservable link bandwidth and Unreserved Bandwidth MUST unreserved bandwidth, <bcp14>MUST</bcp14> use the
          OSPFv2 TE Opaque LSA <xref target="RFC3630"/> target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA
          <xref target="RFC5329"/> target="RFC5329" format="default"/> and MUST NOT <bcp14>MUST
	  NOT</bcp14> be advertised in the ASLA Sub-TLV.</t> sub-TLV.</t>
        </section>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Existing security extensions as described in <xref target="RFC2328"></xref>, target="RFC2328" format="default"/>,
       <xref target="RFC5340"></xref> target="RFC5340" format="default"/>, and <xref target="RFC8362"/> target="RFC8362" format="default"/> apply to extensions
       defined in this document. While OSPF is under a single administrative domain,
       there can be deployments where potential attackers have access to one or more
       networks in the OSPF routing domain. In these deployments, stronger authentication
       mechanisms such as those specified in <xref target="RFC5709"></xref>, target="RFC5709" format="default"/>,
       <xref target="RFC7474"></xref>, target="RFC7474" format="default"/>, <xref target="RFC4552"></xref> target="RFC4552" format="default"/>, or
       <xref target="RFC7166"></xref> SHOULD target="RFC7166" format="default"/> <bcp14>SHOULD</bcp14> be
      used.</t>
      <t>Implementations must assure ensure that malformed TLV if any of the TLVs and Sub-TLV sub-TLVs
      defined in this document are malformed, they are detected and do not provide
      facilitate a vulnerability for attackers to crash the OSPF router or routing process. Reception of a
      malformed TLV or Sub-TLV SHOULD sub-TLV <bcp14>SHOULD</bcp14> be counted and/or logged
      for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD sub-TLVs
      <bcp14>SHOULD</bcp14> be rate-limited to prevent a Denial of Service denial-of-service
      (DoS) attack (distributed or otherwise) from overloading the OSPF
      control plane.</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 that traffic
      engineering, which uses various link attributes for its path
      computation. This is similar in nature to the impacts associated with (for example) with,
      for example, <xref target="RFC3630"/>. target="RFC3630" 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="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This specifications specification updates two existing registries:
    <list style="hanging">
      <t>- OSPFv2
      </t>
      <ul>

        <li>the "OSPFv2 Extended Link TLV Sub-TLVs Registry</t>

      <t>- OSPFv3 Sub-TLVs" registry</li>

        <li>the "OSPFv3 Extended-LSA Sub-TLV Registry</t>
    </list></t>

      <t>New Sub-TLVs" registry</li>
      </ul>

      <t>The new values are defined in this document have been allocated using the
      IETF Review procedure as described in
      <xref target="RFC5226"/>.</t> target="RFC8126" format="default"/>.</t>
      <section anchor="OSPFV2IANA" title="OSPFv2"> numbered="true" toc="default">
        <name>OSPFv2</name>
        <t>The OSPFv2 "OSPFv2 Extended Link TLV Sub-TLVs Registry Sub-TLVs" registry <xref target="RFC7684"/>
        target="RFC7684" format="default"/> defines sub-TLVs at any level of
        nesting for OSPFv2 Extended Link TLVs. IANA has assigned the following
   Sub-TLV
        sub-TLV types from the OSPFv2 "OSPFv2 Extended Link TLV Sub-TLVs Registry:
  <list style="hanging">
     <t>10 - Sub-TLVs" registry:
        </t>
        <dl>

          <dt>10:</dt><dd> Application-Specific Link Attributes</t>
     <t>11 - Attributes</dd>

          <dt>11:</dt><dd> Shared Risk Link Group</t>
     <t>12 - Group</dd>

          <dt>12:</dt><dd> Unidirectional Link Delay</t>
     <t>13 - Delay</dd>

          <dt>13:</dt><dd> Min/Max Unidirectional Link Delay</t>
     <t>14 - Delay</dd>

          <dt>14:</dt><dd> Unidirectional Delay Variation</t>
     <t>15 - Variation</dd>

          <dt>15:</dt><dd> Unidirectional Link Loss</t>
     <t>16 - Loss</dd>

          <dt>16:</dt><dd> Unidirectional Residual Bandwidth</t>
     <t>17 - Bandwidth</dd>

          <dt>17:</dt><dd> Unidirectional Available Bandwidth</t>
     <t>18 - Bandwidth</dd>

          <dt>18:</dt><dd> Unidirectional Utilized Bandwidth</t>
     <t>19 - Bandwidth</dd>

          <dt>19:</dt><dd> Administrative Group</t>
     <t>20 - Group</dd>

          <dt>20:</dt><dd> Extended Administrative Group</t>
     <t>22 - Group</dd>

          <dt>22:</dt><dd> TE Metric</t>
     <t>23 - Metric</dd>

          <dt>23:</dt><dd> Maximum Link Bandwidth</t>
  </list></t> link bandwidth</dd>
        </dl>
      </section>
      <section anchor="OSPFV3IANA" title="OSPFv3"> numbered="true" toc="default">
        <name>OSPFv3</name>
        <t>The OSPFv3 "OSPFv3 Extended-LSA Sub-TLV Registry Sub-TLVs" registry <xref target="RFC8362"/> target="RFC8362"
        format="default"/> defines sub-TLVs at any level of nesting for OSPFv3
        Extended LSAs. IANA has assigned the following
   Sub-TLV sub-TLV types from the OSPFv3
        "OSPFv3 Extended-LSA Sub-TLV Registry:
  <list style="hanging">
     <t>11 - Sub-TLVs" registry:
        </t>
       <dl>

          <dt>11:</dt><dd> Application-Specific Link Attributes</t>
     <t>12 - Attributes</dd>

          <dt>12:</dt><dd> Shared Risk Link Group</t>
     <t>13 - Group</dd>

          <dt>13:</dt><dd> Unidirectional Link Delay</t>
     <t>14 - Delay</dd>

          <dt>14:</dt><dd> Min/Max Unidirectional Link Delay</t>
     <t>15 - Delay</dd>

          <dt>15:</dt><dd> Unidirectional Delay Variation</t>
     <t>16 - Variation</dd>

          <dt>16:</dt><dd> Unidirectional Link Loss</t>
     <t>17 - Loss</dd>

          <dt>17:</dt><dd> Unidirectional Residual Bandwidth</t>
     <t>18 - Bandwidth</dd>

          <dt>18:</dt><dd> Unidirectional Available Bandwidth</t>
     <t>19 - Bandwidth</dd>

          <dt>19:</dt><dd> Unidirectional Utilized Bandwidth</t>
     <t>20 - Bandwidth</dd>

          <dt>20:</dt><dd> Administrative Group</t>
     <t>21 - Group</dd>

          <dt>21:</dt><dd> Extended Administrative Group</t>
     <t>22 - Group</dd>

          <dt>22:</dt><dd> TE Metric</t>
     <t>23 - Metric</dd>

          <dt>23:</dt><dd> Maximum Link Bandwidth</t>
     <t>24 - link bandwidth</dd>

          <dt>24:</dt><dd> Local Interface IPv6 Address Sub-TLV</t>
     <t>25 - Address</dd>

          <dt>25:</dt><dd> Remote Interface IPv6 Address Sub-TLV</t>

    </list></t> Address</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>

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

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.2328.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7684.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.5329.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>

<reference anchor='RFC8919'>
<front>
<title>IS-IS Application-Specific Link Attributes</title>

<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'>
    <organization />
</author>

<author initials='P' surname='Psenak' fullname='Peter Psenak'>
    <organization />
</author>

<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
    <organization />
</author>

<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
    <organization />
</author>

<author initials='J' surname='Drake' fullname='John Drake'>
    <organization />
</author>

<date month='September' year='2020' />
</front>
<seriesInfo name="RFC" value="8919"/>
<seriesInfo name="DOI" value="10.17487/RFC8919"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <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.4552.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5709.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.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"/>

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

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to <contact fullname="Chris Bowers"/> for his review and comments.</t>
      <t>Thanks to <contact fullname="Alvaro Retana"/> for his detailed review and comments.</t>
    </section>

    <section anchor="CONTR" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed to the content
      of this document and should be considered as co-authors:</t>

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

   Acee Lindem
   Cisco Systems
   301 coauthors:</t>

  <contact fullname="Acee Lindem">
    <organization>Cisco Systems</organization>
    <address>
      <postal>
   <street>301 Midenhall Way
   Cary, NC 27513
   USA

   Email: acee@cisco.com

   Ketan Talaulikar
   Cisco Way</street>
   <city>Cary</city>
   <region>NC</region><code>27513</code>
   <country>United States of America</country>
      </postal>

      <email>acee@cisco.com</email>
    </address>
  </contact>

  <contact fullname="Ketan Talaulikar">
    <organization>Cisco Systems, Inc.
   India

   Email: ketant@cisco.com

   Hannes Gredler
   RtBrick Inc.
   Austria

   Email: hannes@rtbrick.com

]]></artwork>
        </figure></t>

</section>

<section title="Acknowledgments">

<t>Thanks to Chris Bowers for his review and comments.</t>

<t>Thanks to Alvaro Retana for his detailed review and comments.</t> </organization>
    <address>
      <postal>
	<country>India</country>
      </postal>

      <email>ketant@cisco.com</email>
    </address>
  </contact>

  <contact fullname="Hannes Gredler">
    <organization>RtBrick Inc.</organization>
      <address>
      <postal>
  <country>Austria</country>
      </postal>
  <email>hannes@rtbrick.com</email>
    </address>
  </contact>

    </section>

</middle>

<back>
 <references title="Normative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-isis-te-app.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"?>
      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?>
  </references>

  </back>
</rfc>