doc: Add RFC documents

1 files changed, 1080 insertions, 0 deletions

diff --git a/doc/rfc/rfc9492.txt b/doc/rfc/rfc9492.txt
new file mode 100644
index 0000000..b0d97ef
--- /dev/null
+++ b/doc/rfc/rfc9492.txt
@@ -0,0 +1,1080 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                    P. Psenak, Ed.
+Request for Comments: 9492                                   L. Ginsberg
+Obsoletes: 8920                                            Cisco Systems
+Category: Standards Track                                  W. Henderickx
+ISSN: 2070-1721                                                    Nokia
+                                                             J. Tantsura
+                                                                  Nvidia
+                                                                J. Drake
+                                                        Juniper Networks
+                                                            October 2023
+
+
+               OSPF Application-Specific Link Attributes
+
+Abstract
+
+   Existing traffic-engineering-related link attribute advertisements
+   have been defined and are used in RSVP-TE deployments.  Since the
+   original RSVP-TE use case was defined, additional applications such
+   as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that
+   also make use of the link attribute advertisements have been defined.
+   In cases where multiple applications wish to make use of these link
+   attributes, the current advertisements do not support application-
+   specific values for a given attribute, nor do they support indication
+   of which applications are using the advertised value for a given
+   link.  This document introduces link attribute advertisements in
+   OSPFv2 and OSPFv3 that address both of these shortcomings.
+
+   This document obsoletes RFC 8920.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9492.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Requirements Discussion
+   3.  Existing Advertisement of Link Attributes
+   4.  Advertisement of Link Attributes
+     4.1.  OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
+   5.  Advertisement of Application-Specific Values
+   6.  Reused TE Link Attributes
+     6.1.  Shared Risk Link Group (SRLG)
+     6.2.  Extended Metrics
+     6.3.  Administrative Group
+     6.4.  TE Metric
+   7.  Maximum Link Bandwidth
+   8.  Considerations for Extended TE Metrics
+   9.  Local Interface IPv6 Address Sub-TLV
+   10. Remote Interface IPv6 Address Sub-TLV
+   11. Attribute Advertisements and Enablement
+   12. Deployment Considerations
+     12.1.  Use of Legacy RSVP-TE LSA Advertisements
+     12.2.  Use of Zero-Length Application Identifier Bit Masks
+     12.3.  Interoperability, Backwards Compatibility, and Migration
+            Concerns
+       12.3.1.  Multiple Applications: Common Attributes with RSVP-TE
+       12.3.2.  Multiple Applications: Some Attributes Not Shared with
+               RSVP-TE
+       12.3.3.  Interoperability with Legacy Routers
+       12.3.4.  Use of Application-Specific Advertisements for RSVP-TE
+   13. Security Considerations
+   14. IANA Considerations
+     14.1.  OSPFv2
+     14.2.  OSPFv3
+   15. Changes to RFC 8920
+   16. References
+     16.1.  Normative References
+     16.2.  Informative References
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   Advertisement of link attributes by the OSPFv2 [RFC2328] and OSPFv3
+   [RFC5340] protocols in support of traffic engineering (TE) was
+   introduced by [RFC3630] and [RFC5329], respectively.  It has been
+   extended by [RFC4203], [RFC7308], and [RFC7471].  Use of these
+   extensions has been associated with deployments supporting TE over
+   Multiprotocol Label Switching (MPLS) in the presence of the Resource
+   Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE
+   [RFC3209].
+
+   For the purposes of this document, an application is a technology
+   that makes use of link attribute advertisements, examples of which
+   are listed in Section 5.
+
+   In recent years, new applications have been introduced that have use
+   cases for many of the link attributes historically used by RSVP-TE.
+   Such applications include SR Policy [RFC9256] and LFAs [RFC5286].
+   This has introduced ambiguity in that if a deployment includes a mix
+   of RSVP-TE support and SR Policy support, for example, it is not
+   possible to unambiguously indicate which advertisements are to be
+   used by RSVP-TE and which advertisements are to be used by SR Policy.
+   If the topologies are fully congruent, this may not be an issue, but
+   any incongruence leads to ambiguity.
+
+   An example of where this ambiguity causes a problem is a network
+   where RSVP-TE is enabled only on a subset of its links.  A link
+   attribute is advertised for the purpose of another application (e.g.,
+   SR Policy) for a link that is not enabled for RSVP-TE.  As soon as
+   the router that is an RSVP-TE head end sees the link attribute being
+   advertised for that link, it assumes RSVP-TE is enabled on that link,
+   even though it is not.  If such an RSVP-TE head-end router tries to
+   set up an RSVP-TE path via that link, it will result in a setup
+   failure for the path.
+
+   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.
+
+   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.
+
+1.1.  Requirements Language
+
+   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.
+
+2.  Requirements Discussion
+
+   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:
+
+   1.  Support for indicating which applications are using the link
+       attribute advertisements on a link.
+
+   2.  Support for advertising application-specific values for the same
+       attribute on a link.
+
+   [RFC7855] discusses use cases and requirements for SR.  Included
+   among these use cases is SR Policy, which is defined in [RFC9256].
+   If both RSVP-TE and SR Policy are deployed in a network, link
+   attribute advertisements can be used by one or both of these
+   applications.  There is no requirement for the link attributes
+   advertised on a given link used by SR Policy to be identical to the
+   link attributes advertised on that same link used by RSVP-TE; thus,
+   there is a clear requirement to indicate independently which link
+   attribute advertisements are to be used by each application.
+
+   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 backwards-compatibility issues.
+
+   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.
+
+3.  Existing Advertisement of Link Attributes
+
+   There are existing advertisements used in support of RSVP-TE.  These
+   advertisements are carried in the OSPFv2 TE Opaque Link State
+   Advertisement (LSA) [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
+   Additional RSVP-TE link attributes have been defined by [RFC4203],
+   [RFC7308], and [RFC7471].
+
+   Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and E-
+   Router-LSAs [RFC8362] for OSPFv3 are used to advertise link
+   attributes that are used by applications other than RSVP-TE or GMPLS
+   [RFC4203].  These LSAs were defined as generic containers for
+   distribution of the extended link attributes.
+
+4.  Advertisement of Link Attributes
+
+   This section outlines the solution for advertising link attributes
+   originally defined for RSVP-TE or GMPLS when they are used for other
+   applications.
+
+4.1.  OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
+
+   The following are the advantages of Extended Link Opaque LSAs as
+   defined in [RFC7684] for OSPFv2 and E-Router-LSAs [RFC8362] for
+   OSPFv3 with respect to the advertisement of link attributes
+   originally defined for RSVP-TE when used in packet networks and in
+   GMPLS:
+
+   1.  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 [RFC3630] and [RFC5329].
+
+   2.  The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remain
+       truly opaque to OSPFv2 and OSPFv3 as originally defined in
+       [RFC3630] and [RFC5329], respectively.  Their contents are not
+       inspected by OSPF, which instead acts as a pure transport.
+
+   3.  There is a clear distinction between link attributes used by
+       RSVP-TE and link attributes used by other OSPFv2 or OSPFv3
+       applications.
+
+   4.  All link attributes that are used by other applications are
+       advertised in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or
+       the OSPFv3 E-Router-LSA [RFC8362] in OSPFv3.
+
+   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.
+
+   The Extended Link Opaque LSA [RFC7684] and E-Router-LSA [RFC8362] are
+   used to advertise any link attributes used for non-RSVP-TE
+   applications in OSPFv2 or OSPFv3, respectively, including those that
+   have been originally defined for RSVP-TE applications (see
+   Section 6).
+
+   TE link attributes used for RSVP-TE/GMPLS continue to use the OSPFv2
+   TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
+
+   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 codepoints are allocated for
+   these link attribute TLVs from the "OSPFv2 Extended Link TLV Sub-
+   TLVs" registry [RFC7684] and from the "OSPFv3 Extended-LSA Sub-TLVs"
+   registry [RFC8362], as specified in Section 14.
+
+5.  Advertisement of Application-Specific Values
+
+   To allow advertisement of the application-specific values of the link
+   attribute, an Application-Specific Link Attributes (ASLA) sub-TLV is
+   defined.  The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended Link
+   TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].
+
+   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" or "UDA".  These applications are not
+   subject to standardization and are outside of the scope of this
+   specification.
+
+   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 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 be used for advertisement of the link attributes listed
+   at the end of this section if these are advertised inside the OSPFv2
+   Extended Link TLV and OSPFv3 Router-Link TLV.  It has the following
+   format:
+
+    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 (SABM)         |
+   +-                                                             -+
+   |                            ...                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       User-Defined Application Identifier Bit Mask (UDABM)    |
+   +-                                                             -+
+   |                            ...                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Link Attribute sub-TLVs                  |
+   +-                                                             -+
+   |                            ...                                |
+
+   where:
+
+   Type:
+      10 (OSPFv2), 11 (OSPFv3)
+
+   Length:
+      Variable
+
+   SABM Length:
+      Standard Application Identifier Bit Mask Length in octets.  The
+      value MUST be 0, 4, or 8.  If the Standard Application Identifier
+      Bit Mask is not present, the SABM Length MUST be set to 0.
+
+   UDABM Length:
+      User-Defined Application Identifier Bit Mask Length in octets.
+      The value MUST be 0, 4, or 8.  If the User-Defined Application
+      Identifier Bit Mask is not present, the UDABM Length MUST be set
+      to 0.
+
+   Standard Application Identifier Bit Mask:
+      Optional set of bits, where each bit represents a single standard
+      application.  Bits are defined in the "Link Attribute Application
+      Identifiers" registry, which is defined in [RFC9479].  Current
+      assignments are repeated here for informational purposes:
+
+                              0 1 2 3 4 5 6 7 ...
+                             +-+-+-+-+-+-+-+-+...
+                             |R|S|F|          ...
+                             +-+-+-+-+-+-+-+-+...
+
+      Bit 0 (R-bit):  RSVP-TE.
+
+      Bit 1 (S-bit):  SR Policy (this is data plane independent).
+
+      Bit 2 (F-bit):  Loop-Free Alternate (includes all LFA types).
+
+   User-Defined Application Identifier Bit Mask:
+      Optional set of bits, where each bit represents a single user-
+      defined application.
+
+   If the SABM or UDABM Length is other than 0, 4, or 8, the ASLA sub-
+   TLV MUST be ignored by the receiver.
+
+   Standard Application Identifier Bits are defined and sent starting
+   with bit 0.  Undefined bits that are transmitted MUST be transmitted
+   as 0 and MUST be ignored on receipt.  Bits that are not transmitted
+   MUST be treated as if they are set to 0 on receipt.  Bits that are
+   not supported by an implementation MUST be ignored on receipt.
+
+   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 be used
+   starting with bit 0 so as to minimize the number of octets required
+   to advertise all UDAs.  Undefined bits that are transmitted MUST be
+   transmitted as 0 and MUST be ignored on receipt.  Bits that are not
+   transmitted MUST be treated as if they are set to 0 on receipt.  Bits
+   that are not supported by an implementation MUST be ignored on
+   receipt.
+
+   If the link attribute advertisement is intended to be only used by a
+   specific set of applications, corresponding bit masks MUST be present
+   and one or more application-specific bits MUST be set for all
+   applications that use the link attributes advertised in the ASLA sub-
+   TLV.
+
+   Application Identifier Bit Masks apply to all link attributes that
+   support application-specific values and are advertised in the ASLA
+   sub-TLV.
+
+   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.
+
+   If the same attribute is advertised in more than one ASLA sub-TLV
+   with the application listed in the Application Identifier Bit Masks,
+   the application SHOULD use the first instance of advertisement and
+   ignore any subsequent advertisements of that attribute.
+
+   Link attributes MAY be advertised associated with zero-length
+   Application Identifier Bit Masks for both standard applications and
+   user-defined applications.  Such link attribute advertisements MUST
+   be used by standard applications and/or user-defined applications
+   when no link attribute advertisements with a non-zero-length
+   Application Identifier Bit Mask and a matching Application Identifier
+   Bit set are present.  Otherwise, such link attribute advertisements
+   MUST NOT be used.
+
+   This document defines the initial set of link attributes that MUST
+   use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or
+   in the OSPFv3 Router-Link TLV.  Documents that define new link
+   attributes MUST state whether the new attributes support application-
+   specific values and, as such, are advertised in an ASLA sub-TLV.  The
+   standard link attributes that are advertised in ASLA sub-TLVs are:
+
+   *  Shared Risk Link Group [RFC4203]
+
+   *  Unidirectional Link Delay [RFC7471]
+
+   *  Min/Max Unidirectional Link Delay [RFC7471]
+
+   *  Unidirectional Delay Variation [RFC7471]
+
+   *  Unidirectional Link Loss [RFC7471]
+
+   *  Unidirectional Residual Bandwidth [RFC7471]
+
+   *  Unidirectional Available Bandwidth [RFC7471]
+
+   *  Unidirectional Utilized Bandwidth [RFC7471]
+
+   *  Administrative Group [RFC3630]
+
+   *  Extended Administrative Group [RFC7308]
+
+   *  TE Metric [RFC3630]
+
+6.  Reused TE Link Attributes
+
+   This section defines the use case and indicates the codepoints
+   (Section 14) from the "OSPFv2 Extended Link TLV Sub-TLVs" registry
+   and "OSPFv3 Extended-LSA Sub-TLVs" registry for some of the link
+   attributes that have been originally defined for RSVP-TE or GMPLS.
+
+6.1.  Shared Risk Link Group (SRLG)
+
+   The SRLG of a link can be used in OSPF-calculated IPFRR (IP Fast
+   Reroute) [RFC5714] to compute a backup path that does not share any
+   SRLG with the protected link.
+
+   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 [RFC4203]
+   is used with TLV type 11.  Similarly, for OSPFv3 to advertise the
+   SRLG in the OSPFv3 Router-Link TLV, TLV type 12 is used.
+
+6.2.  Extended Metrics
+
+   [RFC3630] defines several link bandwidth types.  [RFC7471] defines
+   extended link metrics that are based on link bandwidth, 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), or loss.
+
+   To advertise extended link metrics in the OSPFv2 Extended Link TLV,
+   the same format for the sub-TLVs defined in [RFC7471] is used with
+   the following TLV types:
+
+   12:  Unidirectional Link Delay
+
+   13:  Min/Max Unidirectional Link Delay
+
+   14:  Unidirectional Delay Variation
+
+   15:  Unidirectional Link Loss
+
+   16:  Unidirectional Residual Bandwidth
+
+   17:  Unidirectional Available Bandwidth
+
+   18:  Unidirectional Utilized Bandwidth
+
+   To advertise extended link metrics in the Router-Link TLV inside the
+   OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in
+   [RFC7471] is used with the following TLV types:
+
+   13:  Unidirectional Link Delay
+
+   14:  Min/Max Unidirectional Link Delay
+
+   15:  Unidirectional Delay Variation
+
+   16:  Unidirectional Link Loss
+
+   17:  Unidirectional Residual Bandwidth
+
+   18:  Unidirectional Available Bandwidth
+
+   19:  Unidirectional Utilized Bandwidth
+
+6.3.  Administrative Group
+
+   [RFC3630] and [RFC7308] define the Administrative Group and Extended
+   Administrative Group sub-TLVs, respectively.
+
+   To advertise the Administrative Group and Extended Administrative
+   Group in the OSPFv2 Extended Link TLV, the same format for the sub-
+   TLVs defined in [RFC3630] and [RFC7308] is used with the following
+   TLV types:
+
+   19:  Administrative Group
+
+   20:  Extended Administrative Group
+
+   To advertise the Administrative Group and Extended Administrative
+   Group in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs
+   defined in [RFC3630] and [RFC7308] is used with the following TLV
+   types:
+
+   20:  Administrative Group
+
+   21:  Extended Administrative Group
+
+6.4.  TE Metric
+
+   [RFC3630] defines the TE Metric.
+
+   To advertise the TE Metric in the OSPFv2 Extended Link TLV, the same
+   format for the sub-TLV defined in Section 2.5.5 of [RFC3630] is used
+   with TLV type 22.  Similarly, for OSPFv3 to advertise the TE Metric
+   in the OSPFv3 Router-Link TLV, TLV type 22 is used.
+
+7.  Maximum Link Bandwidth
+
+   Maximum link bandwidth is an application-independent attribute of the
+   link that is defined in [RFC3630].  Because it is an application-
+   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
+   Instead, it MAY be advertised as a sub-TLV of the Extended Link TLV
+   in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV
+   of the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3
+   [RFC8362].
+
+   To advertise the maximum link bandwidth in the OSPFv2 Extended Link
+   TLV, the same format for the sub-TLV defined in [RFC3630] is used
+   with TLV type 23.
+
+   To advertise the maximum link bandwidth in the OSPFv3 Router-Link
+   TLV, the same format for the sub-TLV defined in [RFC3630] is used
+   with TLV type 23.
+
+8.  Considerations for Extended TE Metrics
+
+   [RFC7471] defines a number of dynamic performance metrics associated
+   with a link.  It is conceivable that such metrics could be measured
+   specific to traffic associated with a specific application.
+   Therefore, this document includes support for advertising these link
+   attributes specific to a given application.  However, in practice, it
+   may well be more practical to have these metrics reflect the
+   performance of all traffic on the link regardless of application.  In
+   such cases, advertisements for these attributes 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 Application Identifier
+   Bit Mask.  The use of zero-length Application Identifier Bit Mask is
+   further discussed in Section 12.2.
+
+9.  Local Interface IPv6 Address Sub-TLV
+
+   The Local Interface IPv6 Address sub-TLV is an application-
+   independent attribute of the link that is defined in [RFC5329].
+   Because it is an application-independent attribute, it MUST NOT be
+   advertised in the ASLA sub-TLV.  Instead, it MAY be advertised as a
+   sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
+   [RFC8362].
+
+   To advertise the Local Interface IPv6 Address sub-TLV in the OSPFv3
+   Router-Link TLV, the same format for the sub-TLV defined in [RFC5329]
+   is used with TLV type 24.
+
+10.  Remote Interface IPv6 Address Sub-TLV
+
+   The Remote Interface IPv6 Address sub-TLV is an application-
+   independent attribute of the link that is defined in [RFC5329].
+   Because it is an application-independent attribute, it MUST NOT be
+   advertised in the ASLA sub-TLV.  Instead, it MAY be advertised as a
+   sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
+   [RFC8362].
+
+   To advertise the Remote Interface IPv6 Address sub-TLV in the OSPFv3
+   Router-Link TLV, the same format for the sub-TLV defined in [RFC5329]
+   is used with TLV type 25.
+
+11.  Attribute Advertisements and Enablement
+
+   This document defines extensions to support the advertisement of
+   application-specific link attributes.
+
+   There are applications where the application enablement on the link
+   is relevant; for example, with RSVP-TE, one needs to make sure that
+   RSVP is enabled on the link before sending an RSVP-TE signaling
+   message over it.
+
+   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.
+
+   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.
+
+   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 [RFC3630] and OSPFv3 Intra-Area-
+   TE-LSA [RFC5329].
+
+   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 SR-enabled topology
+   independent of the existence of link attribute advertisements.
+
+   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.
+
+   In the future, if additional standard applications are defined to use
+   this mechanism, the specification defining this use MUST define the
+   relationship between application-specific link attribute
+   advertisements and enablement for that application.
+
+   This document allows the advertisement of application-specific link
+   attributes with no application identifiers, i.e., both the SABM and
+   the UDABM are not present (see Section 5).  This supports the use of
+   the link attribute by any application.  In the presence of an
+   application where the advertisement of link 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.
+
+12.  Deployment Considerations
+
+12.1.  Use of Legacy RSVP-TE LSA Advertisements
+
+   Bit identifiers for standard applications are defined in Section 5.
+   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 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:
+
+   *  The application is RSVP-TE.
+
+   *  The application is SR Policy or LFA, and RSVP-TE is not deployed
+      anywhere in the network.
+
+   *  The application is SR Policy or LFA, RSVP-TE is deployed in the
+      network, and both the set of links on which SR Policy and/or LFA
+      advertisements are required and the attribute values used by SR
+      Policy and/or LFA on all such links are fully congruent with the
+      links and attribute values used by RSVP-TE.
+
+   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 types of advertisements are to be
+   sent and processed on receipt for these applications.  Further
+   discussion of the associated issues can be found in Section 12.3.
+
+   New applications that future documents define to make use of the
+   advertisements defined in this document MUST NOT 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.
+
+12.2.  Use of Zero-Length Application Identifier Bit Masks
+
+   Link attribute advertisements associated with zero-length Application
+   Identifier Bit Masks for both standard applications and user-defined
+   applications are usable by any application, subject to the
+   restrictions specified in Section 5.  If support for a new
+   application is introduced on any node in a network in the presence of
+   such advertisements, the new application will use these
+   advertisements when the aforementioned restrictions are met.  If this
+   is not what is intended, then existing link attribute advertisements
+   MUST be readvertised with an explicit set of applications specified
+   before a new application is introduced.
+
+12.3.  Interoperability, Backwards Compatibility, and Migration Concerns
+
+   Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the
+   legacy advertisements listed in Section 3.  Routers that do not
+   support the extensions defined in this document will only process
+   legacy advertisements and are likely to infer that RSVP-TE is enabled
+   on the links for which legacy advertisements exist.  It is expected
+   that deployments using the legacy advertisements will persist for a
+   significant period of time.  Therefore, deployments using the
+   extensions defined in this document in the presence of routers that
+   do not support these extensions need to be able to interoperate with
+   the use of legacy advertisements by the legacy routers.  The
+   following subsections discuss interoperability and backwards-
+   compatibility concerns for a number of deployment scenarios.
+
+12.3.1.  Multiple Applications: Common Attributes with RSVP-TE
+
+   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 be
+   advertised using application-specific advertisements.  This results
+   in duplicate advertisements for those attributes.
+
+12.3.2.  Multiple Applications: Some Attributes Not Shared with RSVP-TE
+
+   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 be advertised using application-specific advertisements.
+   In cases where some link attributes are shared with RSVP-TE, this
+   requires duplicate advertisements for those attributes.
+
+12.3.3.  Interoperability with Legacy Routers
+
+   For the standard applications defined in this document, routers that
+   do not support the extensions defined in this document will send and
+   receive only legacy link attribute advertisements.  In addition, the
+   link attribute values associated with these applications are always
+   shared since legacy routers have no way of advertising or processing
+   application-specific values.  So long as there is any legacy router
+   in the network that has any of the standard applications defined in
+   this document enabled, all routers MUST continue to advertise link
+   attributes for these applications using only legacy advertisements.
+   ASLA advertisements for these applications MUST NOT be sent.  Once
+   all legacy routers have been upgraded, migration from legacy
+   advertisements to ASLA advertisements can be achieved via the
+   following steps:
+
+   1)  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.
+
+   2)  Enable the use of the application-specific advertisements on all
+       routers.
+
+   3)  Keep legacy advertisements if needed for RSVP-TE purposes.
+
+   When the migration is complete, it then becomes possible to advertise
+   incongruent values per application on a given link.
+
+   Documents defining new applications that make use of the application-
+   specific advertisements defined in this document MUST discuss
+   interoperability and backwards-compatibility issues that could occur
+   in the presence of routers that do not support the new application.
+
+12.3.4.  Use of Application-Specific Advertisements for RSVP-TE
+
+   The extensions defined in this document support RSVP-TE as one of the
+   supported applications.  It is, however, RECOMMENDED to advertise all
+   link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
+   [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] to maintain
+   backwards compatibility.  RSVP-TE can eventually utilize the
+   application-specific advertisements for newly defined link attributes
+   that are defined as application specific.
+
+   Link attributes that are not allowed to be advertised in the ASLA
+   sub-TLV, such as maximum reservable link bandwidth and unreserved
+   bandwidth, MUST use the OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3
+   Intra-Area-TE-LSA [RFC5329] and MUST NOT be advertised in the ASLA
+   sub-TLV.
+
+13.  Security Considerations
+
+   Existing security extensions as described in [RFC2328], [RFC5340],
+   and [RFC8362] 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 [RFC5709],
+   [RFC7474], [RFC4552], or [RFC7166] SHOULD be used.
+
+   Implementations must ensure that if any of the TLVs and sub-TLVs
+   defined in this document are malformed, they are detected and do not
+   facilitate a vulnerability for attackers to crash or otherwise
+   compromise the OSPF router or routing process.  Reception of a
+   malformed TLV or sub-TLV SHOULD be counted and/or logged for further
+   analysis.  Logging of malformed TLVs and sub-TLVs SHOULD be rate-
+   limited to prevent a denial-of-service (DoS) attack (distributed or
+   otherwise) from overloading the OSPF control plane.
+
+   This document defines an improved way to advertise link attributes.
+   Tampering with the information defined in this document may have an
+   effect on applications using it, including impacting TE, which uses
+   various link attributes for its path computation.  This is similar in
+   nature to the impacts associated with, for example, [RFC3630].  As
+   the advertisements defined in this document limit the scope to
+   specific applications, the impact of tampering is similarly limited
+   in scope.
+
+14.  IANA Considerations
+
+   This specification updates two existing registries:
+
+   *  the "OSPFv2 Extended Link TLV Sub-TLVs" registry
+
+   *  the "OSPFv3 Extended-LSA Sub-TLVs" registry
+
+   The values defined in this document have been allocated using the
+   IETF Review procedure as described in [RFC8126].
+
+14.1.  OSPFv2
+
+   The "OSPFv2 Extended Link TLV Sub-TLVs" registry [RFC7684] defines
+   sub-TLVs at any level of nesting for OSPFv2 Extended Link TLVs.  IANA
+   has assigned the following sub-TLV types in the "OSPFv2 Extended Link
+   TLV Sub-TLVs" registry:
+
+   10:  Application-Specific Link Attributes
+
+   11:  Shared Risk Link Group
+
+   12:  Unidirectional Link Delay
+
+   13:  Min/Max Unidirectional Link Delay
+
+   14:  Unidirectional Delay Variation
+
+   15:  Unidirectional Link Loss
+
+   16:  Unidirectional Residual Bandwidth
+
+   17:  Unidirectional Available Bandwidth
+
+   18:  Unidirectional Utilized Bandwidth
+
+   19:  Administrative Group
+
+   20:  Extended Administrative Group
+
+   22:  TE Metric
+
+   23:  Maximum link bandwidth
+
+14.2.  OSPFv3
+
+   The "OSPFv3 Extended-LSA Sub-TLVs" registry [RFC8362] defines sub-
+   TLVs at any level of nesting for OSPFv3 Extended LSAs.  IANA has
+   assigned the following sub-TLV types in the "OSPFv3 Extended-LSA Sub-
+   TLVs" registry:
+
+   11:  Application-Specific Link Attributes
+
+   12:  Shared Risk Link Group
+
+   13:  Unidirectional Link Delay
+
+   14:  Min/Max Unidirectional Link Delay
+
+   15:  Unidirectional Delay Variation
+
+   16:  Unidirectional Link Loss
+
+   17:  Unidirectional Residual Bandwidth
+
+   18:  Unidirectional Available Bandwidth
+
+   19:  Unidirectional Utilized Bandwidth
+
+   20:  Administrative Group
+
+   21:  Extended Administrative Group
+
+   22:  TE Metric
+
+   23:  Maximum link bandwidth
+
+   24:  Local Interface IPv6 Address
+
+   25:  Remote Interface IPv6 Address
+
+15.  Changes to RFC 8920
+
+   Discussion within the LSR WG indicated that there was confusion
+   regarding the use of ASLA advertisements that had a zero-length SABM/
+   UDABM.  The discussion can be seen by searching the LSR WG mailing
+   list archives for the thread "Proposed Errata for RFCs 8919/8920"
+   starting on 15 June 2021.
+
+   Changes to Section 5 have been introduced to clarify normative
+   behavior in the presence of such advertisements.  [RFC8920] defines
+   advertising link attributes with zero-length SABM and zero-length
+   UDABM as a means of advertising link attributes that can be used by
+   any application.  However, the text uses the word "permitted",
+   suggesting that the use of such advertisements is "optional".  Such
+   an interpretation could lead to interoperability issues and is not
+   what was intended.
+
+   The replacement text makes explicit the specific conditions when such
+   advertisements MUST be used and the specific conditions under which
+   they MUST NOT be used.
+
+   A subsection discussing the use of zero-length Application Identifier
+   Bit Masks has been added for greater consistency with [RFC9479].  See
+   Section 12.2.
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+              (TE) Extensions to OSPF Version 2", RFC 3630,
+              DOI 10.17487/RFC3630, September 2003,
+              <https://www.rfc-editor.org/info/rfc3630>.
+
+   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
+              Support of Generalized Multi-Protocol Label Switching
+              (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
+              <https://www.rfc-editor.org/info/rfc4203>.
+
+   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
+              "Traffic Engineering Extensions to OSPF Version 3",
+              RFC 5329, DOI 10.17487/RFC5329, September 2008,
+              <https://www.rfc-editor.org/info/rfc5329>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS
+              Traffic Engineering (MPLS-TE)", RFC 7308,
+              DOI 10.17487/RFC7308, July 2014,
+              <https://www.rfc-editor.org/info/rfc7308>.
+
+   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
+              Previdi, "OSPF Traffic Engineering (TE) Metric
+              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
+              <https://www.rfc-editor.org/info/rfc7471>.
+
+   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
+              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
+              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
+              2015, <https://www.rfc-editor.org/info/rfc7684>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
+              F. Baker, "OSPFv3 Link State Advertisement (LSA)
+              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
+              2018, <https://www.rfc-editor.org/info/rfc8362>.
+
+   [RFC9479]  Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
+              J. Drake, "IS-IS Application-Specific Link Attributes",
+              RFC 9479, DOI 10.17487/RFC9479, October 2023,
+              <https://www.rfc-editor.org/info/rfc9479>.
+
+16.2.  Informative References
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
+              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
+              <https://www.rfc-editor.org/info/rfc4552>.
+
+   [RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
+              IP Fast Reroute: Loop-Free Alternates", RFC 5286,
+              DOI 10.17487/RFC5286, September 2008,
+              <https://www.rfc-editor.org/info/rfc5286>.
+
+   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
+              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
+              Authentication", RFC 5709, DOI 10.17487/RFC5709, October
+              2009, <https://www.rfc-editor.org/info/rfc5709>.
+
+   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
+              RFC 5714, DOI 10.17487/RFC5714, January 2010,
+              <https://www.rfc-editor.org/info/rfc5714>.
+
+   [RFC7166]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
+              Authentication Trailer for OSPFv3", RFC 7166,
+              DOI 10.17487/RFC7166, March 2014,
+              <https://www.rfc-editor.org/info/rfc7166>.
+
+   [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
+              "Security Extension for OSPFv2 When Using Manual Key
+              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
+              <https://www.rfc-editor.org/info/rfc7474>.
+
+   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
+              Litkowski, S., Horneffer, M., and R. Shakir, "Source
+              Packet Routing in Networking (SPRING) Problem Statement
+              and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
+              2016, <https://www.rfc-editor.org/info/rfc7855>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8920]  Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
+              J., and J. Drake, "OSPF Application-Specific Link
+              Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020,
+              <https://www.rfc-editor.org/info/rfc8920>.
+
+   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
+              A., and P. Mattes, "Segment Routing Policy Architecture",
+              RFC 9256, DOI 10.17487/RFC9256, July 2022,
+              <https://www.rfc-editor.org/info/rfc9256>.
+
+Acknowledgments
+
+   The following acknowledgments are included in [RFC8920]:
+
+   Thanks to Chris Bowers for his review and comments.
+
+   Thanks to Alvaro Retana for his detailed review and comments.
+
+   For this document, the authors would like to thank Bruno Decraene.
+
+Contributors
+
+   The following people contributed to the content of this document and
+   should be considered as coauthors:
+
+   Acee Lindem
+   LabN Consulting, L.L.C.
+   United States of America
+   Email: acee.ietf@gmail.com
+
+
+   Ketan Talaulikar
+   Cisco Systems
+   India
+   Email: ketant.ietf@gmail.com
+
+
+   Hannes Gredler
+   RtBrick Inc.
+   Email: hannes@rtbrick.com
+
+
+Authors' Addresses
+
+   Peter Psenak (editor)
+   Cisco Systems
+   Slovakia
+   Email: ppsenak@cisco.com
+
+
+   Les Ginsberg
+   Cisco Systems
+   United States of America
+   Email: ginsberg@cisco.com
+
+
+   Wim Henderickx
+   Nokia
+   Copernicuslaan 50
+   2018 94089 Antwerp
+   Belgium
+   Email: wim.henderickx@nokia.com
+
+
+   Jeff Tantsura
+   Nvidia
+   United States of America
+   Email: jefftant.ietf@gmail.com
+
+
+   John Drake
+   Juniper Networks
+   United States of America
+   Email: jdrake@juniper.net