< draft-ietf-ospf-te-link-attr-reuse-10.txt   draft-ietf-ospf-te-link-attr-reuse-11.txt >
LSR Working Group P. Psenak, Ed. LSR Working Group P. Psenak, Ed.
Internet-Draft L. Ginsberg Internet-Draft L. Ginsberg
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: May 2, 2020 W. Henderickx Expires: November 8, 2020 W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Apstra Apstra
J. Drake J. Drake
Juniper Networks Juniper Networks
October 30, 2019 May 7, 2020
OSPF Link Traffic Engineering Attribute Reuse OSPF Link Traffic Engineering Attribute Reuse
draft-ietf-ospf-te-link-attr-reuse-10.txt draft-ietf-ospf-te-link-attr-reuse-11.txt
Abstract Abstract
Various link attributes have been defined in OSPF in the context of Existing traffic engineering related link attribute advertisements
the MPLS Traffic Engineering (TE) and GMPLS. Since the original have been defined and are used in RSVP-TE deployments. Since the
RSVP-TE use case was defined, additional applications (e.g., SRTE, original RSVP-TE use case was defined, additional applications (e.g.,
LFA) have been defined which also make use of the link attribute Segment Routing Traffic Engineering, Loop Free Alternate) have been
advertisements. This document defines how to distribute link defined which also make use of the link attribute advertisements. In
attributes in OSPFv2 and OSPFv3 for applications other than MPLS TE cases where multiple applications wish to make use of these link
or GMPLS. attributes the current advertisements do not support application
specific values for a given attribute nor do they support indication
of which applications are using the advertised value for a given
link. This document introduces new link attribute advertisements in
OSPFv2 and OSPFv3 which address both of these shortcomings.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2020. This Internet-Draft will expire on November 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Advertisement of Link Attributes . . . . . . . . . . . . . . 3 3. Existing Advertisement of Link Attributes . . . . . . . . . . 4
2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 3 4. Advertisement of Link Attributes . . . . . . . . . . . . . . 4
3. Advertisement of Application Specific Values . . . . . . . . 4 4.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 4
4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 7 5. Advertisement of Application Specific Values . . . . . . . . 5
4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 7 6. Reused TE link attributes . . . . . . . . . . . . . . . . . . 8
4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8 6.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 8
4.3. Administrative Group . . . . . . . . . . . . . . . . . . 9 6.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8
4.4. TE Metric . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Administrative Group . . . . . . . . . . . . . . . . . . 9
5. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 9 6.4. Traffic Engineering Metric . . . . . . . . . . . . . . . 10
6. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 7. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 10
7. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 8. Considerations for Extended TE Metrics . . . . . . . . . . . 10
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 9. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 11
8.1. Use of TE LSA Advertisements . . . . . . . . . . . . . . 10 10. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 11
8.2. Use of Zero Length Application Identifier Bit Masks . . . 11 11. Attribute Advertisements and Enablement . . . . . . . . . . . 11
9. Attribute Advertisements and Enablement . . . . . . . . . . . 11 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 12.1. Use of Legacy RSVP-TE LSA Advertisements . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12.2. Use of Zero Length Application Identifier Bit Masks . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12.3. Interoperability, Backwards Compatibility and Migration
12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 Concerns . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.3.1. Multiple Applications: Common Attributes with RSVP-
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 TE . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12.3.2. Multiple Applications: Some Attributes Not Shared
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 with RSVP-TE . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.3.3. Interoperability with Legacy Routers . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 16 12.3.4. Use of Application Specific Advertisements for RSVP-
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 TE . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
14.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 16
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Various link attributes have been defined in OSPFv2 [RFC2328] and Advertisement of link attributes by the OSPFv2 [RFC2328] and OSPFv3
OSPFv3 [RFC5340] in the context of the MPLS TE and GMPLS. All these [RFC5340] protocols in support of traffic engineering (TE) was
attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV introduced by [RFC3630] and [RFC5329] respectively. It has been
advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In OSPFv3, they extended by [RFC4203], [RFC7308] and [RFC7471]. Use of these
are distributed as sub-TLVs of the Link-TLV advertised in the OSPFv3 extensions has been associated with deployments supporting Traffic
Intra-Area-TE-LSA as defined in [RFC5329]. Engineering over Multiprotocol Label Switching (MPLS) in the presence
of the Resource Reservation Protocol (RSVP) - more succinctly
referred to as RSVP-TE [RFC3209].
Many of these link attributes are useful outside of traditional MPLS For the purposes of this document an application is a technology
Traffic Engineering or GMPLS. This brings its own set of problems, which makes use of link attribute advertisements - examples of which
in particular how to distribute these link attributes in OSPFv2 and are listed in Section 5.
OSPFv3 when MPLS TE and GMPLS are not deployed or are deployed in
parallel with other applications that use these link attributes.
[RFC7855] discusses use cases/requirements for Segment Routing (SR). In recent years new applications have been introduced which have use
Included among these use cases is Segment Routing Traffic Engineering cases for many of the link attributes historically used by RSVP-TE.
(SRTE). If both RSVP-TE and SRTE are deployed in a network, link Such applications include Segment Routing Traffic Engineering (SRTE)
attribute advertisements can be used by one or both of these [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates
applications. As there is no requirement for the link attributes (LFA) [RFC5286]. This has introduced ambiguity in that if a
advertised on a given link used by SRTE to be identical to the link deployment includes a mix of RSVP-TE support and SRTE support (for
attributes advertised on that same link used by RSVP-TE, there is a example) it is not possible to unambiguously indicate which
clear requirement to indicate independently which link attribute advertisements are to be used by RSVP-TE and which advertisements are
advertisements are to be used by each application. to be used by SRTE. If the topologies are fully congruent this may
not be an issue, but any incongruence leads to ambiguity.
As the number of applications which may wish to utilize link An additional issue arises in cases where both applications are
attributes may grow in the future, an additional requirement is that supported on a link but the link attribute values associated with
the extensions defined allow the association of additional each application differ. Current advertisements do not support
applications to link attributes without altering the format of the advertising application specific values for the same attribute on a
advertisements or introducing new backwards compatibility issues. specific link.
Finally, there may still be many cases where a single attribute value This document defines extensions which address these issues. Also,
can be shared among multiple applications, so the solution should as evolution of use cases for link attributes can be expected to
minimize advertising duplicate link/attribute when possible. continue in the years to come, this document defines a solution which
is easily extensible for the introduction of new applications and new
use cases.
1.1. Requirements notation 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
2. Advertisement of Link Attributes capitals, as shown here.
This section outlines the solution for advertising link attributes 3. Existing Advertisement of Link Attributes
originally defined for MPLS TE or GMPLS when they are used for other
applications.
2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA There are existing advertisements used in support of RSVP-TE. These
advertisements are carried in the OSPFv2 TE Opaque 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 Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and
Extended Router-LSAs [RFC8362] for OSPFv3 are used to advertise link Extended Router-LSAs [RFC8362] for OSPFv3 are used to advertise link
attributes that are used by applications other then MPLS TE or GMPLS. attributes that are used by applications other then RSVP-TE or GMPLS.
These LSAs were defined as a generic containers for distribution of These LSAs were defined as a generic containers for distribution of
the extended link attributes. There are several advantages in using the extended link attributes.
them:
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
Advantages of Extended Link Opaque LSAs as defined in [RFC7684] for
OSPFv2 and Extended Router-LSAs [RFC8362] for OSPFv3 when used for
advertisement of link attributes originally defined for RSVP-TE or
GMPLS:
1. Advertisement of the link attributes does not make the link part 1. Advertisement of the link attributes does not make the link part
of the TE topology. It avoids any conflicts and is fully of the RSVP-TE topology. It avoids any conflicts and is fully
compatible with [RFC3630] and [RFC5329]. compatible with [RFC3630] and [RFC5329].
2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains 2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains
truly opaque to OSPFv2 and OSPFv3 as originally defined in truly opaque to OSPFv2 and OSPFv3 as originally defined in
[RFC3630] and [RFC5329] respectively. Their contents are not [RFC3630] and [RFC5329] respectively. Their contents are not
inspected by OSPF, that acts as a pure transport. inspected by OSPF, that acts as a pure transport.
3. There is clear distinction between link attributes used by TE and 3. There is clear distinction between link attributes used by RSVP-
link attributes used by other OSPFv2 or OSPFv3 applications. TE and link attributes used by other OSPFv2 or OSPFv3
applications.
4. All link attributes that are used by other applications are 4. All link attributes that are used by other applications are
advertised in a single LSA, the Extended Link Opaque LSA in advertised in a single LSA, the Extended Link Opaque LSA in
OSPFv2 or the OSPFv3 E-Router-LSA [RFC8362] in OSPFv3. OSPFv2 or the OSPFv3 E-Router-LSA [RFC8362] in OSPFv3.
The disadvantage of this approach is that in rare cases, the same The disadvantage of this approach is that in rare cases, the same
link attribute is advertised in both the TE Opaque and Extended Link 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 Attribute LSAs in OSPFv2 or the Intra-Area-TE-LSA and E-Router-LSA in
OSPFv3. Additionally, there will be additional standardization OSPFv3.
effort. However, this could also be viewed as an advantage as the
non-TE use cases for the TE link attributes are documented and
validated by the LSR working group.
Extended Link Opaque LSA [RFC7684] and E-Router-LSA [RFC8362] are Extended Link Opaque LSA [RFC7684] and E-Router-LSA [RFC8362] are
used to advertise any link attributes used for non-TE applications in used to advertise any link attributes used for non-RSVP-TE
OSPFv2 or OSPFv3 respectively, including those that have been applications in OSPFv2 or OSPFv3 respectively, including those that
originally defined for TE applications. have been originally defined for RSVP-TE applications (See
Section 6).
TE link attributes used for RSVP-TE/GMPLS continue to use OSPFv2 TE TE link attributes used for RSVP-TE/GMPLS continue use OSPFv2 TE
Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329]. Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
The format of the link attribute TLVs that have been defined for TE The format of the link attribute TLVs that have been defined for
applications will be kept unchanged even when they are used for non- RSVP-TE applications will be kept unchanged even when they are used
TE applications. Unique code points will be allocated for these TE for non-RSVP-TE applications. Unique code points are allocated for
link attribute TLVs from the OSPFv2 Extended Link TLV Sub-TLV these link attribute TLVs from the OSPFv2 Extended Link TLV Sub-TLV
Registry [RFC7684] and from the OSPFv3 Extended LSA Sub-TLV Registry Registry [RFC7684] and from the OSPFv3 Extended LSA Sub-TLV Registry
[RFC8362]. For each reused TLV, the code point will be defined in an [RFC8362], as specified in Section 14.
IETF document along with the expected use-case(s).
3. Advertisement of Application Specific Values 5. Advertisement of Application Specific Values
To allow advertisement of the application specific values of the link To allow advertisement of the application specific values of the link
attribute, a new Application Specific Link Attributes (ASLA) sub-TLV attribute, a new Application Specific Link Attributes (ASLA) sub-TLV
is defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended is defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
Link TLV [RFC7471] and OSPFv3 Router-Link TLV [RFC8362]. Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].
The ASLA sub-TLV is an optional sub-TLV and can appear multiple times The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. It has in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA
the following format: sub-TLV MUST be used for advertisement of the link attributes listed
at the end on this section if these are advertised inside OSPFv2
Extended Link TLV and OSPFv3 Router-Link TLV. It has the following
format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABM Length | UDABM Length | Reserved | | SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Identifier Bit-Mask | | Standard Application Identifier Bit-Mask |
+- -+ +- -+
skipping to change at page 5, line 36 skipping to change at page 6, line 30
| Link Attribute sub-sub-TLVs | | Link Attribute sub-sub-TLVs |
+- -+ +- -+
| ... | | ... |
where: where:
Type: 10 (OSPFv2), 11 (OSPFv3) Type: 10 (OSPFv2), 11 (OSPFv3)
Length: variable Length: variable
SABM Length: Standard Application Identifier Bit-Mask Length. It SABM Length: Standard Application Identifier Bit-Mask Length in
MUST be a multiple of 4 bytes. If the Standard Application Bit- octets. The legal values are 0, 4 or 8. If the Standard
Mask is not present, the Standard Application Bit-Mask Length MUST Application Bit-Mask is not present, the Standard Application Bit-
be set to 0. Mask Length MUST be set to 0.
UDABM Length: User Defined Application Identifier Bit-Mask Length. UDABM Length: User Defined Application Identifier Bit-Mask Length
It MUST be a multiple of 4 bytes. If the User Defined Application in octets. The legal values are 0, 4 or 8. If the User Defined
Bit-Mask is not present, the User Defined Application Bit-Mask Application Bit-Mask is not present, the User Defined Application
Length MUST be set to 0. Bit-Mask Length MUST be set to 0.
Standard Application Identifier Bit-Mask: Optional set of bits, Standard Application Identifier Bit-Mask: Optional set of bits,
where each bit represents a single standard application. Bits are where each bit represents a single standard application. Bits are
defined in [I-D.ietf-isis-te-app], which also request a new IANA defined in [I-D.ietf-isis-te-app]. The bits are repeated here for
"Link Attribute Applications" registry under "Interior Gateway informational purpose:
Protocol (IGP) Parameters" for them. The bits are repeated here
for informational purpose:
Bit-0 (R-bit): RSVP TE Bit-0 (R-bit): RSVP-TE
Bit-1 (S-bit): Segment Routing TE Bit-1 (S-bit): Segment Routing TE
Bit-2 (F-bit): Loop Free Alternate (LFA). Includes all LFA Bit-2 (F-bit): Loop Free Alternate (LFA). Includes all LFA
types types
User Defined Application Identifier Bit-Mask: Optional set of User Defined Application Identifier Bit-Mask: Optional set of
bits, where each bit represents a single user defined application. 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/sent starting with Standard Application Identifier Bits are defined/sent starting with
Bit 0. Additional bit definitions that are defined in the future Bit 0. Undefined bits MUST be transmitted as 0 and MUST be ignored
SHOULD be assigned in ascending bit order so as to minimize the on receipt. Bits that are NOT transmitted MUST be treated as if they
number of octets that will need to be transmitted. 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 User Defined Application Identifier Bits have no relationship to
Standard Application bits and are NOT managed by IANA or any other Standard Application Identifier Bits and are NOT managed by IANA or
standards body. It is recommended that bits are used starting with any other standards body. It is recommended that bits are used
Bit 0 so as to minimize the number of octets required to advertise starting with Bit 0 so as to minimize the number of octets required
all of them. to advertise all UDAs.
Undefined bits in both Bit-Masks 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.
If the link attribute advertisement is limited to be used by a If the link attribute advertisement is limited to be used by a
specific set of applications, corresponding Bit-Masks MUST be present specific set of applications, corresponding Bit-Masks MUST be present
and application specific bit(s) MUST be set for all applications that and application specific bit(s) MUST be set for all applications that
use the link attributes advertised in the ASLA sub-TLV. use the link attributes advertised in the ASLA sub-TLV.
Application Bit-Masks apply to all link attributes that support Application Bit-Masks apply to all link attributes that support
application specific values and are advertised in the ASLA sub-TLV. application specific values and are advertised in the ASLA sub-TLV.
The advantage of not making the Application Bit-Masks part of the The advantage of not making the Application Bit-Masks part of the
attribute advertisement itself is that we can keep the format of the attribute advertisement itself is that the format of any previously
link attributes that have been defined previously and reuse the same defined link attributes can be kept and reused when advertising them
format when advertising them in the ASLA sub-TLV. in the ASLA sub-TLV.
When neither the Standard Application Bits nor the User Defined
Application bits are set (i.e., both SABM Length and UDABM Length are
0) in the ASLA sub-TLV, then the link attributes included in it MUST
be considered as being applicable to all applications.
If, however, another advertisement of the same link attribute
includes any Application Bit-Mask in the ASLA sub-TLV, applications
that are listed in the Application Bit-Masks of such ASLA sub-TLV
SHOULD use the attribute advertisement which has the application
specific bit set in the Application Bit-Masks.
If the same application is listed in the Application Bit-Masks of If the same attribute is advertised in more than single ASLA sub-TLVs
more then one ASLA sub-TLV, the application SHOULD use the first with the application listed in the Application Bit-Masks, the
advertisement and ignore any subsequent advertisements of the same application SHOULD use the first instance of advertisement and ignore
attribute. This situation SHOULD be logged as an error. any subsequent advertisements of that attribute.
This document defines the initial set of link attributes that MUST This document defines the initial set of link attributes that MUST
use ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or
the OSPFv3 Router-Link TLV. If the ASLA sub-TLV includes any link in the OSPFv3 Router-Link TLV. Documents which define new link
attribute(s) NOT listed below, they MUST be ignored. Documents which attributes MUST state whether the new attributes support application
define new link attributes MUST state whether the new attributes specific values and as such MUST be advertised in an ASLA sub-TLV.
support application specific values and as such MUST be advertised in The link attributes that MUST be advertised in ASLA sub-TLVs are:
an ASLA sub-TLV. The link attributes that MUST be advertised in ASLA
sub-TLVs are:
- Shared Risk Link Group
- Unidirectional Link Delay - Shared Risk Link Group [RFC4203]
- Min/Max Unidirectional Link Delay - Unidirectional Link Dela [RFC7471]
- Unidirectional Delay Variation - Min/Max Unidirectional Link Delay [RFC7471]
- Unidirectional Delay Variation [RFC7471]
- Unidirectional Link Loss - Unidirectional Link Loss [RFC7471]
- Unidirectional Residual Bandwidth - Unidirectional Residual Bandwidth [RFC7471]
- Unidirectional Available Bandwidth - Unidirectional Available Bandwidth [RFC7471]
- Unidirectional Utilized Bandwidth - Unidirectional Utilized Bandwidth [RFC7471]
- Administrative Group - Administrative Group [RFC3630]
- Extended Administrative Group - Extended Administrative Group [RFC7308]
- TE Metric - TE Metric [RFC3630]
4. Reused TE link attributes 6. Reused TE link attributes
This section defines the use case and code points from the OSPFv2 This section defines the use case and indicates the code points
Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV (Section 14) from the OSPFv2 Extended Link TLV Sub-TLV Registry and
Registry for some of the link attributes that have been originally OSPFv3 Extended LSA Sub-TLV Registry for some of the link attributes
defined for TE or GMPLS. that have been originally defined for RSVP-TE or GMPLS.
4.1. Shared Risk Link Group (SRLG) 6.1. Shared Risk Link Group (SRLG)
The SRLG of a link can be used in OSPF calculated IPFRR [RFC5714] to The SRLG of a link can be used in OSPF calculated IPFRR [RFC5714] to
compute a backup path that does not share any SRLG group with the compute a backup path that does not share any SRLG group with the
protected link. protected link.
To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, 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] the same format for the sub-TLV defined in section 1.3 of [RFC4203]
is used and TLV type 11 is used. Similarly, for OSPFv3 to advertise is used and TLV type 11 is used. Similarly, for OSPFv3 to advertise
the SRLG in the OSPFv3 Router-Link TLV, TLV type 12 is used. the SRLG in the OSPFv3 Router-Link TLV, TLV type 12 is used.
4.2. Extended Metrics 6.2. Extended Metrics
[RFC3630] defines several link bandwidth types. [RFC7471] defines [RFC3630] defines several link bandwidth types. [RFC7471] defines
extended link metrics that are based on link bandwidth, delay and extended link metrics that are based on link bandwidth, delay and
loss characteristics. All these can be used to compute primary and loss characteristics. All these can be used to compute primary and
backup paths within an OSPF area to satisfy requirements for backup paths within an OSPF area to satisfy requirements for
bandwidth, delay (nominal or worst case) or loss. bandwidth, delay (nominal or worst case) or loss.
To advertise extended link metrics in the OSPFv2 Extended Link TLV, 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 same format for the sub-TLVs defined in [RFC7471] is used with
the following TLV types: the following TLV types:
skipping to change at page 9, line 5 skipping to change at page 9, line 34
15 - Unidirectional Delay Variation 15 - Unidirectional Delay Variation
16 - Unidirectional Link Loss 16 - Unidirectional Link Loss
17 - Unidirectional Residual Bandwidth 17 - Unidirectional Residual Bandwidth
18 - Unidirectional Available Bandwidth 18 - Unidirectional Available Bandwidth
19 - Unidirectional Utilized Bandwidth 19 - Unidirectional Utilized Bandwidth
4.3. Administrative Group 6.3. Administrative Group
[RFC3630] and [RFC7308] define the Administrative Group and Extended [RFC3630] and [RFC7308] define the Administrative Group and Extended
Administrative Group sub-TLVs respectively. Administrative Group sub-TLVs respectively.
To advertise the Administrative Group and Extended Administrative To advertise the Administrative Group and Extended Administrative
Group in the OSPFv2 Extended Link TLV, the same format for the sub- Group in the OSPFv2 Extended Link TLV, the same format for the sub-
TLVs defined in [RFC3630] and [RFC7308] is used with the following TLVs defined in [RFC3630] and [RFC7308] is used with the following
TLV types: TLV types:
19 - Administrative Group 19 - Administrative Group
skipping to change at page 9, line 28 skipping to change at page 10, line 9
To advertise Administrative Group and Extended Administrative Group To advertise Administrative Group and Extended Administrative Group
in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs
defined in [RFC3630] and [RFC7308] is used with the following TLV defined in [RFC3630] and [RFC7308] is used with the following TLV
types: types:
20 - Administrative Group 20 - Administrative Group
21 - Extended Administrative Group 21 - Extended Administrative Group
4.4. TE Metric 6.4. Traffic Engineering Metric
[RFC3630] defines TE Metric. [RFC3630] defines Traffic Engineering Metric.
To advertise the TE Metric in the OSPFv2 Extended Link TLV, the same To advertise the Traffic Engineering Metric in the OSPFv2 Extended
format for the sub-TLV defined in section 2.5.5 of [RFC3630] is used Link TLV, the same format for the sub-TLV defined in section 2.5.5 of
and TLV type 22 is used. Similarly, for OSPFv3 to advertise the TE [RFC3630] is used and TLV type 22 is used. Similarly, for OSPFv3 to
Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used. advertise the Traffic Engineering Metric in the OSPFv3 Router-Link
TLV, TLV type 22 is used.
5. Maximum Link Bandwidth 7. Maximum Link Bandwidth
Maximum link bandwidth is an application independent attribute of the Maximum link bandwidth is an application independent attribute of the
link that is defined in [RFC3630]. Because it is an application link that is defined in [RFC3630]. Because it is an application
independent attribute, it MUST NOT be advertised in ASLA sub-TLV. independent attribute, it MUST NOT be advertised in ASLA sub-TLV.
Instead, it MAY be advertised as a sub-TLV of the Extended Link Instead, it MAY be advertised as a sub-TLV of the Extended Link
Opaque LSA Extended Link TLV in OSPFv2 [RFC7684] or sub-TLV of OSPFv3 Opaque LSA Extended Link TLV in OSPFv2 [RFC7684] or sub-TLV of OSPFv3
E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362]. E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362].
To advertise the Maximum link bandwidth in the OSPFv2 Extended Link To advertise the Maximum link bandwidth in the OSPFv2 Extended Link
TLV, the same format for sub-TLV defined in [RFC3630] is used with TLV, the same format for sub-TLV defined in [RFC3630] is used with
TLV type 23. TLV type 23.
To advertise the Maximum link bandwidth in the OSPFv3 Router-Link To advertise the Maximum link bandwidth in the OSPFv3 Router-Link
TLV, the same format for sub-TLV defined in [RFC3630] is used with TLV, the same format for sub-TLV defined in [RFC3630] is used with
TLV type 23. TLV type 23.
6. Local Interface IPv6 Address Sub-TLV 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, for example, by
listing all applications in the Application Bit-Mask.
9. Local Interface IPv6 Address Sub-TLV
The Local Interface IPv6 Address Sub-TLV is an application The Local Interface IPv6 Address Sub-TLV is an application
independent attribute of the link that is defined in [RFC5329]. independent attribute of the link that is defined in [RFC5329].
Because it is an application independent attribute, it MUST NOT be Because it is an application independent attribute, it MUST NOT be
advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a
sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362]. sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362].
To advertise the Local Interface IPv6 Address Sub-TLV in the OSPFv3 To advertise the Local Interface IPv6 Address Sub-TLV in the OSPFv3
Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is
used with TLV type 24. used with TLV type 24.
7. Remote Interface IPv6 Address Sub-TLV 10. Remote Interface IPv6 Address Sub-TLV
The Remote Interface IPv6 Address Sub-TLV is an application The Remote Interface IPv6 Address Sub-TLV is an application
independent attribute of the link that is defined in [RFC5329]. independent attribute of the link that is defined in [RFC5329].
Because it is an application independent attribute, it MUST NOT be Because it is an application independent attribute, it MUST NOT be
advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a
sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362]. sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362].
To advertise the Remote Interface IPv6 Address Sub-TLV in the OSPFv3 To advertise the Remote Interface IPv6 Address Sub-TLV in the OSPFv3
Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is
used with TLV type 25. used with TLV type 25.
8. Deployment Considerations 11. Attribute Advertisements and Enablement
8.1. Use of TE LSA Advertisements This document defines extensions to support the advertisement of
application specific link attributes.
Bit Identifers for Standard Applications are defined in Section 3. 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 SRTE, advertisement of application specific link
attributes does NOT indicate enablement of SRTE. The advertisements
are only used to support constraints which may be applied when
specifying an explicit path. SRTE is implicitly enabled on all links
which are part of the Segment Routing enabled topology independent of
the existence of link attribute advertisements
In the case of LFA, advertisement of application specific link
attributes does NOT indicate enablement of LFA on that link.
Enablement is controlled by local configuration.
If, in the future, 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 Standard
Application Identifier Bit Mask and the User Defined Application
Identifier Bit Mask 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 attribute
advertisements is used to infer the enablement of an application on
that link (e.g., RSVP-TE), the absence of the application identifier
leaves ambiguous whether that application is enabled on such a link.
This needs to be considered when making use of the "any application"
encoding.
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 All of the identifiers defined in this document are associated with
applications which were already deployed in some networks prior to applications which were already deployed in some networks prior to
the writing of this document. Therefore, such applications have been the writing of this document. Therefore, such applications have been
deployed using the TE LSA advertisements. The Standard Applications deployed using the RSVP-TE LSA advertisements. The Standard
defined in this document MAY continue to use TE LSA advertisements Applications defined in this document MAY continue to use RSVP-TE LSA
for a given link so long as at least one of the following conditions advertisements for a given link so long as at least one of the
is true: following conditions is true:
The application is RSVP-TE The application is RSVP-TE
The application is SRTE or LFA and RSVP-TE is not deployed The application is SRTE or LFA and RSVP-TE is not deployed
anywhere in the network anywhere in the network
The application is SRTE or LFA, RSVP-TE is deployed in the The application is SRTE or LFA, RSVP-TE is deployed in the
network, and both the set of links on which SRTE and/or LFA network, and both the set of links on which SRTE and/or LFA
advertisements are required and the attribute values used by SRTE advertisements are required and the attribute values used by SRTE
and/or LFA on all such links is fully congruent with the links and and/or LFA on all such links is fully congruent with the links and
attribute values used by RSVP-TE attribute values used by RSVP-TE
Under the conditions defined above, implementations which support the Under the conditions defined above, implementations which support the
extensions defined in this document have the choice of using TE LSA extensions defined in this document have the choice of using RSVP-TE
advertisements or application specific advertisements in support of LSA advertisements or application specific advertisements in support
SRTE and/or LFA. This will require implementations to provide of SRTE and/or LFA. This will require implementations to provide
controls specifying which type of advertisements are to be sent/ controls specifying which type of advertisements are to be sent/
processed on receive for these applications. Further discussion of processed on receive for these applications. Further discussion of
the associated issues can be found in Section 10. the associated issues can be found in Section 12.3.
New applications which future documents define to make use of the New applications which future documents define to make use of the
advertisements defined in this document MUST NOT make use of TE LSA advertisements defined in this document MUST NOT make use of RSVP-TE
advertisements. LSA advertisements. This simplifies deployment of new applications
by eliminating the need to support multiple ways to advertise
attributes for the new applications.
8.2. Use of Zero Length Application Identifier Bit Masks 12.2. Use of Zero Length Application Identifier Bit Masks
If link attributes are advertised associated with zero length If link attributes are advertised associated with zero length
Application Identifier Bit-Masks for both standard applications and Application Identifier Bit Masks for both standard applications and
user defined applications, then that set of link attributes MAY be user defined applications, then any Standard Application and/or any
used by any application. If support for a new application is User Defined Application is permitted to use that set of link
introduced on any node in a network in the presence of such attributes so long as there is not another set of attributes
advertisements, these advertisements MAY be used by the new advertised on that same link which is associated with a non-zero
application. If this is not what is intended, then existing length Application Identifier Bit Mask with a matching Application
advertisements MUST be readvertised with an explicit set of Identifier Bit set. If support for a new application is introduced
applications specified before 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 be
readvertised with an explicit set of applications specified before a
new application is introduced.
9. Attribute Advertisements and Enablement 12.3. Interoperability, Backwards Compatibility and Migration Concerns
This document defines extensions to support the advertisement of Existing deployments of RSVP-TE, SRTE, and/or LFA utilize the legacy
application specific link attributes. advertisements listed in Section 3. Routers which 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 must be able to co-exist with use
of the legacy advertisements by routers which do not support the
extensions defined in this document. The following sub-sections
discuss interoperability and backwards compatibility concerns for a
number of deployment scenarios.
Whether the presence of link attribute advertisements for a given 12.3.1. Multiple Applications: Common Attributes with RSVP-TE
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 In cases where multiple applications are utilizing a given link, one
link attributes implies that RSVP is enabled on that link. The of the applications is RSVP-TE, and all link attributes for a given
absence of RSVP-TE application specific link attributes in link are common to the set of applications utilizing that link,
combination with the absence of legacy advertisements implies that interoperability is achieved by using legacy advertisements for RSVP-
RSVP is NOT enabled on that link. TE. Attributes for applications other than RSVP-TE MUST be
advertised using application specific advertisements. This results
in duplicate advertisements for those attributes.
In the case of SRTE, advertisement of application specific link 12.3.2. Multiple Applications: Some Attributes Not Shared with RSVP-TE
attributes does NOT indicate enablement of SRTE. The advertisements
are only used to support constraints which may be applied when
specifying an explicit path. SRTE is implicitly enabled on all links
which are part of the Segment Routing enabled topology independent of
the existence of link attribute advertisements.
In the case of LFA, advertisement of application specific link In cases where one or more applications other than RSVP-TE are
attributes does NOT indicate enablement of LFA on that link. utilizing a given link and one or more link attribute values are NOT
Enablement is controlled by local configuration. 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
If, in the future, additional standard applications are defined to 12.3.3. Interoperability with Legacy Routers
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 For the applications defined in this document, routers which do not
attributes with no application identifiers i.e., both the Standard support the extensions defined in this document will send and receive
Application Identifier Bit-Mask and the User Defined Application Bit only legacy link attribute advertisements. So long as there is any
Mask are not present (See Section 3). This supports the use of the legacy router in the network which has any of the applications
link attribute by any application. In the presence of an application enabled, all routers MUST continue to advertise link attributes using
where the advertisement of link attribute advertisements is used to legacy advertisements. In addition, the link attribute values
infer the enablement of an application on that link (e.g., RSVP-TE), associated with the set of applications supported by legacy routers
the absence of the Application Identifier leaves ambiguous whether (RSVP-TE, SRTE, and/or LFA) are always shared since legacy routers
that application is enabled on such a link. This needs to be have no way of advertising or processing application specific values.
considered when making use of the "any application" encoding. Once all legacy routers have been upgraded, migration from legacy
advertisements to application specific advertisements can be achieved
via the following steps:
10. Backward Compatibility 1)Send application specific advertisements while continuing to
advertise using legacy (all advertisements are then duplicated).
Receiving routers continue to use legacy advertisements.
Link attributes may be concurrently advertised in both the TE Opaque 2)Enable the use of the application specific advertisements on all
LSA and the Extended Link Opaque LSA in OSPFv2 and the OSPFv3 Intra- routers
Area-TE-LSA and OSPFv3 Extended LSA Router-Link TLV in OSPFv3.
In fact, there is at least one OSPF implementation that utilizes the 3)Keep legacy advertisements if needed for RSVP-TE purposes.
link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP
TE applications. For example, this implementation of LFA and remote
LFA utilizes links attributes such as Shared Risk Link Groups (SRLG)
[RFC4203] and Admin Group [[RFC3630] advertised in TE Opaque LSAs.
These applications are described in [RFC5286], [RFC7490], [RFC7916]
and [RFC8102].
When an OSPF routing domain includes routers using link attributes When the migration is complete, it then becomes possible to advertise
from the OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA for incongruent values per application on a given link.
Non-RSVP TE applications defined in this document (i.e. SRTE and
LFA), OSPF routers in that domain SHOULD continue to advertise such
OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA. In such a
deployment, the advertised attributes SHOULD be the same and Non-
RSVP application access to link attributes is a matter of local
policy.
When advertising link-attributes for any new applications other then Documents defining new applications which make use of the application
RSVP-TE, SRTE or LFA, OSPF routers MUST NOT use TE Opaque LSA or specific advertisements defined in this document MUST discuss
OSPFv3 Intra-Area-TE-LSA. Instead, advertisement in the OSPFv2 interoperability and backwards compatibility issues that could occur
Extended Link Attributes LSAs or OSPFv3 E-Router-LSA MUST be used. in the presence of routers which do not support the new application.
It is RECOMMENDED to advertise link-attributes for RSVP-TE in the 12.3.4. Use of Application Specific Advertisements for RSVP-TE
existing TE LSAs.
11. Security Considerations 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 backward
compatibility. RSVP-TE can eventually utilize the application
specific advertisements for newly defined link attributes, which 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 ASLA Sub-
TLV.
13. Security Considerations
Existing security extensions as described in [RFC2328], [RFC5340] and Existing security extensions as described in [RFC2328], [RFC5340] and
[RFC8362] apply to extensions defined in this document. While OSPF [RFC8362] apply to extensions defined in this document. While OSPF
is under a single administrative domain, there can be deployments is under a single administrative domain, there can be deployments
where potential attackers have access to one or more networks in the where potential attackers have access to one or more networks in the
OSPF routing domain. In these deployments, stronger authentication OSPF routing domain. In these deployments, stronger authentication
mechanisms such as those specified in [RFC5709], [RFC7474], [RFC4552] mechanisms such as those specified in [RFC5709], [RFC7474], [RFC4552]
or [RFC7166] SHOULD be used. or [RFC7166] SHOULD be used.
Implementations MUST assure that malformed TLV and Sub-TLV defined in Implementations must assure that malformed TLV and Sub-TLV defined in
this document are detected and do not provide a vulnerability for this document are detected and do not provide a vulnerability for
attackers to crash the OSPF router or routing process. Reception of attackers to crash the OSPF router or routing process. Reception of
a malformed TLV or Sub-TLV SHOULD be counted and/or logged for a malformed TLV or Sub-TLV SHOULD be counted and/or logged for
further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be
rate-limited to prevent a Denial of Service (DoS) attack (distributed rate-limited to prevent a Denial of Service (DoS) attack (distributed
or otherwise) from overloading the OSPF control plane. or otherwise) from overloading the OSPF control plane.
12. IANA Considerations 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. 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.
12.1. OSPFv2 14. IANA Considerations
14.1. OSPFv2
OSPFv2 Extended Link TLV Sub-TLVs registry [RFC7684] defines sub-TLVs The OSPFv2 Extended Link TLV Sub-TLVs registry [RFC7684] defines sub-
at any level of nesting for OSPFv2 Extended Link TLVs. This TLVs at any level of nesting for OSPFv2 Extended Link TLVs. IANA has
specification updates OSPFv2 Extended Link TLV sub-TLVs registry with assigned the following Sub-TLV types from the OSPFv2 Extended Link
the following TLV types: TLV Sub-TLVs Registry:
10 - Application Specific Link Attributes 10 - Application Specific Link Attributes
11 - Shared Risk Link Group 11 - Shared Risk Link Group
12 - Unidirectional Link Delay 12 - Unidirectional Link Delay
13 - Min/Max Unidirectional Link Delay 13 - Min/Max Unidirectional Link Delay
14 - Unidirectional Delay Variation 14 - Unidirectional Delay Variation
skipping to change at page 14, line 4 skipping to change at page 16, line 28
14 - Unidirectional Delay Variation 14 - Unidirectional Delay Variation
15 - Unidirectional Link Loss 15 - Unidirectional Link Loss
16 - Unidirectional Residual Bandwidth 16 - Unidirectional Residual Bandwidth
17 - Unidirectional Available Bandwidth 17 - Unidirectional Available Bandwidth
18 - Unidirectional Utilized Bandwidth 18 - Unidirectional Utilized Bandwidth
19 - Administrative Group 19 - Administrative Group
20 - Extended Administrative Group 20 - Extended Administrative Group
22 - TE Metric 22 - TE Metric
23 - Maximum Link Bandwidth 23 - Maximum Link Bandwidth
12.2. OSPFv3 14.2. OSPFv3
OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs at The OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs
any level of nesting for OSPFv3 Extended LSAs. This specification at any level of nesting for OSPFv3 Extended LSAs. IANA has assigned
updates OSPFv3 Extended LSA Sub-TLV Registry with the following TLV the following Sub-TLV types from the OSPFv3 Extended LSA Sub-TLV
types: Registry:
11 - Application Specific Link Attributes 11 - Application Specific Link Attributes
12 - Shared Risk Link Group 12 - Shared Risk Link Group
13 - Unidirectional Link Delay 13 - Unidirectional Link Delay
14 - Min/Max Unidirectional Link Delay 14 - Min/Max Unidirectional Link Delay
15 - Unidirectional Delay Variation 15 - Unidirectional Delay Variation
16 - Unidirectional Link Loss 16 - Unidirectional Link Loss
16 - Unidirectional Residual Bandwidth 16 - Unidirectional Residual Bandwidth
18 - Unidirectional Available Bandwidth 18 - Unidirectional Available Bandwidth
19 - Unidirectional Utilized Bandwidth 19 - Unidirectional Utilized Bandwidth
skipping to change at page 15, line 5 skipping to change at page 17, line 26
21 - Extended Administrative Group 21 - Extended Administrative Group
22 - TE Metric 22 - TE Metric
23 - Maximum Link Bandwidth 23 - Maximum Link Bandwidth
24 - Local Interface IPv6 Address Sub-TLV 24 - Local Interface IPv6 Address Sub-TLV
25 - Remote Interface IPv6 Address Sub-TLV 25 - Remote Interface IPv6 Address Sub-TLV
13. Contributors 15. Contributors
The following people contributed to the content of this document and The following people contributed to the content of this document and
should be considered as co-authors: should be considered as co-authors:
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
skipping to change at page 15, line 30 skipping to change at page 18, line 25
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Austria Austria
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
14. Acknowledgments 16. Acknowledgments
Thanks to Chris Bowers for his review and comments. Thanks to Chris Bowers for his review and comments.
15. References Thanks to Alvaro Retana for his detailed review and comments.
15.1. Normative References 17. References
17.1. Normative References
[I-D.ietf-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS TE Attributes per application", draft-
ietf-isis-te-app-12 (work in progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <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., [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008, RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>. <https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308, Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014, DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>. <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., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 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 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
15.2. Informative References 17.2. Informative References
[I-D.ietf-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS TE Attributes per application", draft-
ietf-isis-te-app-08 (work in progress), October 2019.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [I-D.ietf-spring-segment-routing-policy]
DOI 10.17487/RFC2328, April 1998, Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
<https://www.rfc-editor.org/info/rfc2328>. P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress),
December 2019.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Support of Generalized Multi-Protocol Label Switching and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
skipping to change at page 17, line 19 skipping to change at page 20, line 39
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010, RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>. <https://www.rfc-editor.org/info/rfc5714>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014, DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>. <https://www.rfc-editor.org/info/rfc7166>.
[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>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[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>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <https://www.rfc-editor.org/info/rfc7916>.
[RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
S. Litkowski, "Remote-LFA Node Protection and
Manageability", RFC 8102, DOI 10.17487/RFC8102, March
2017, <https://www.rfc-editor.org/info/rfc8102>.
Authors' Addresses Authors' Addresses
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems Cisco Systems
Eurovea Centre, Central 3 Eurovea Centre, Central 3
Pribinova Street 10 Pribinova Street 10
Bratislava 81109 Bratislava 81109
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Les Ginsberg Les Ginsberg
 End of changes. 105 change blocks. 
320 lines changed or deleted 409 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/