< draft-ietf-ospf-te-link-attr-reuse-08.txt   draft-ietf-ospf-te-link-attr-reuse-09.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: February 20, 2020 W. Henderickx Expires: March 22, 2020 W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Apstra Apstra
J. Drake J. Drake
Juniper Networks Juniper Networks
August 19, 2019 September 19, 2019
OSPF Link Traffic Engineering (TE) Attribute Reuse OSPF Link Traffic Engineering Attribute Reuse
draft-ietf-ospf-te-link-attr-reuse-08.txt draft-ietf-ospf-te-link-attr-reuse-09.txt
Abstract Abstract
Various link attributes have been defined in OSPF in the context of Various link attributes have been defined in OSPF in the context of
the MPLS Traffic Engineering (TE) and GMPLS. Many of these link the MPLS Traffic Engineering (TE) and GMPLS. Many of these link
attributes can be used for applications other than MPLS Traffic attributes can be used for applications other than MPLS TE or GMPLS.
Engineering or GMPLS. This document defines how to distribute such This document defines how to distribute such attributes in OSPFv2 and
attributes in OSPFv2 and OSPFv3 for applications other than MPLS OSPFv3 for applications other than MPLS TE or GMPLS.
Traffic Engineering or GMPLS.
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 February 20, 2020. This Internet-Draft will expire on March 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 23 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Advertisement of Link Attributes . . . . . . . . . . . . . . 3 2. Advertisement of Link Attributes . . . . . . . . . . . . . . 3
2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 3 2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 3
3. Advertisement of Application Specific Values . . . . . . . . 4 3. Advertisement of Application Specific Values . . . . . . . . 4
4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 7 4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 7
4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 7 4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 7
4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8 4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8
4.3. Administrative Group . . . . . . . . . . . . . . . . . . 9 4.3. Administrative Group . . . . . . . . . . . . . . . . . . 9
4.4. Traffic Engineering Metric . . . . . . . . . . . . . . . 9 4.4. TE Metric . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 9 5. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 9
6. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 6. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10
7. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 7. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
9. Attribute Advertisements and Enablement . . . . . . . . . . . 11 9. Attribute Advertisements and Enablement . . . . . . . . . . . 10
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 16 15.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Various link attributes have been defined in OSPFv2 [RFC2328] and Various link attributes have been defined in OSPFv2 [RFC2328] and
OSPFv3 [RFC5340] in the context of the MPLS traffic engineering and OSPFv3 [RFC5340] in the context of the MPLS TE and GMPLS. All these
GMPLS. All these attributes are distributed by OSPFv2 as sub-TLVs of attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV
the Link-TLV advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In OSPFv3, they
OSPFv3, they are distributed as sub-TLVs of the Link-TLV advertised are distributed as sub-TLVs of the Link-TLV advertised in the OSPFv3
in the OSPFv3 Intra-Area-TE-LSA as defined in [RFC5329]. Intra-Area-TE-LSA as defined in [RFC5329].
Many of these link attributes are useful outside of traditional MPLS Many of these link attributes are useful outside of traditional MPLS
Traffic Engineering or GMPLS. This brings its own set of problems, Traffic Engineering or GMPLS. This brings its own set of problems,
in particular how to distribute these link attributes in OSPFv2 and in particular how to distribute these link attributes in OSPFv2 and
OSPFv3 when MPLS TE and GMPLS are not deployed or are deployed in OSPFv3 when MPLS TE and GMPLS are not deployed or are deployed in
parallel with other applications that use these link attributes. parallel with other applications that use these link attributes.
[RFC7855] discusses use cases/requirements for Segment Routing. [RFC7855] discusses use cases/requirements for Segment Routing (SR).
Included among these use cases is SRTE. If both RSVP-TE and SRTE are Included among these use cases is Segment Routing Traffic Engineering
deployed in a network, link attribute advertisements can be used by (SRTE). If both RSVP-TE and SRTE are deployed in a network, link
one or both of these applications. As there is no requirement for attribute advertisements can be used by one or both of these
the link attributes advertised on a given link used by SRTE to be applications. As there is no requirement for the link attributes
identical to the link attributes advertised on that same link used by advertised on a given link used by SRTE to be identical to the link
RSVP-TE, there is a clear requirement to indicate independently which attributes advertised on that same link used by RSVP-TE, there is a
link attribute advertisements are to be used by each application. clear requirement to indicate independently which link attribute
advertisements are to be used by each application.
As the number of applications which may wish to utilize link As the number of applications which may wish to utilize link
attributes may grow in the future, an additional requirement is that attributes may grow in the future, an additional requirement is that
the extensions defined allow the association of additional the extensions defined allow the association of additional
applications to link attributes without altering the format of the applications to link attributes without altering the format of the
advertisements or introducing new backwards compatibility issues. advertisements or introducing new backwards compatibility issues.
Finally, there may still be many cases where a single attribute value Finally, there may still be many cases where a single attribute value
can be shared among multiple applications, so the solution should can be shared among multiple applications, so the solution should
minimize advertising duplicate link/attribute when possible. minimize advertising duplicate link/attribute when possible.
1.1. Requirements notation 1.1. Requirements notation
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Advertisement of Link Attributes 2. Advertisement of Link Attributes
This section outlines the solution for advertising link attributes This section outlines the solution for advertising link attributes
originally defined for MPLS Traffic Engineering or GMPLS when they originally defined for MPLS TE or GMPLS when they are used for other
are used for other applications. applications.
2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA 2.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
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 traffic attributes that are used by applications other then MPLS TE or GMPLS.
engineering or GMPLS. These LSAs were defined as a generic These LSAs were defined as a generic containers for distribution of
containers for distribution of the extended link attributes. There the extended link attributes. There are several advantages in using
are several advantages in using them: them:
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 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.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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. Additionally, there will be additional standardization
effort. However, this could also be viewed as an advantage as the effort. However, this could also be viewed as an advantage as the
non-TE use cases for the TE link attributes are documented and non-TE use cases for the TE link attributes are documented and
validated by the LSR working group. validated by the LSR working group.
It is RECOMMENDED to use the Extended Link Opaque LSA [RFC7684] and Extended Link Opaque LSA [RFC7684] and E-Router-LSA [RFC8362] are
E-Router-LSA [RFC8362] to advertise any link attributes used for non- used to advertise any link attributes used for non-TE applications in
TE applications in OSPFv2 or OSPFv3 respectively, including those OSPFv2 or OSPFv3 respectively, including those that have been
that have been originally defined for TE applications. originally defined for TE applications.
It is also RECOMMENDED that TE link attributes used for RSVP-TE/GMPLS TE link attributes used for RSVP-TE/GMPLS continue to use OSPFv2 TE
continue to use OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area- Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
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 TE
applications will be kept unchanged even when they are used for non- applications will be kept unchanged even when they are used for non-
TE applications. Unique code points will be allocated for these TE TE applications. Unique code points will be allocated for these TE
link attribute TLVs from the OSPFv2 Extended Link TLV Sub-TLV 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]. For each reused TLV, the code point will be defined in an
IETF document along with the expected use-case(s). IETF document along with the expected use-case(s).
3. Advertisement of Application Specific Values 3. Advertisement of Application Specific Values
skipping to change at page 5, line 26 skipping to change at page 5, line 26
| User Defined Application Bit-Mask | | User Defined Application Bit-Mask |
+- -+ +- -+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute sub-sub-TLVs | | Link Attribute sub-sub-TLVs |
+- -+ +- -+
| ... | | ... |
where: where:
Type: 10 (OSPFv2), TBD1 (OSPFv3) Type: 10 (OSPFv2), 11 (OSPFv3)
Length: variable Length: variable
SABML: Standard Application Bit-Mask Length. It MUST be a SABML: Standard Application Bit-Mask Length. It MUST be a
multiple of 4 bytes. If the Standard Application Bit-Mask is not multiple of 4 bytes. If the Standard Application Bit-Mask is not
present, the Standard Application Bit-Mask Length MUST be set to present, the Standard Application Bit-Mask Length MUST be set to
0. 0.
UDABML: User Defined Application Bit-Mask Length. It MUST be a UDABML: User Defined Application Bit-Mask Length. It MUST be a
multiple of 4 bytes. If the User Defined Application Bit-Mask is multiple of 4 bytes. If the User Defined Application Bit-Mask is
not present, the User Defined Application Bit-Mask Length MUST be not present, the User Defined Application Bit-Mask Length MUST be
set to 0. set to 0.
Standard Application Bit-Mask: Optional set of bits, where each Standard Application Bit-Mask: Optional set of bits, where each
bit represents a single standard application. Bits are defined in bit represents a single standard application. Bits are defined in
[I-D.ietf-isis-te-app], which also request a new IANA "Link [I-D.ietf-isis-te-app], which also request a new IANA "Link
Attribute Applications" registry under "Interior Gateway Protocol Attribute Applications" registry under "Interior Gateway Protocol
(IGP) Parameters" for them. The bits are repeated here for (IGP) Parameters" for them. The bits are repeated here for
informational purpose: informational purpose:
Bit-0: RSVP Traffic Engineering Bit-0: RSVP TE
Bit-1: Segment Routing Traffic Engineering Bit-1: Segment Routing TE
Bit-2: Loop Free Alternate (LFA). Includes all LFA types Bit-2: Loop Free Alternate (LFA). Includes all LFA types
Bit-3: Flexible Algorithm Bit-3: Flexible Algorithm
User Defined Application Bit-Mask: Optional set of bits, where User Defined Application Bit-Mask: Optional set of bits, where
each bit represents a single user defined application. each bit represents a single user defined application.
Standard Application Bits are defined/sent starting with Bit 0. Standard Application Bits are defined/sent starting with Bit 0.
Additional bit definitions that are defined in the future SHOULD be Additional bit definitions that are defined in the future SHOULD be
assigned in ascending bit order so as to minimize the number of assigned in ascending bit order so as to minimize the number of
skipping to change at page 7, line 34 skipping to change at page 7, line 34
- Unidirectional Residual Bandwidth - Unidirectional Residual Bandwidth
- Unidirectional Available Bandwidth - Unidirectional Available Bandwidth
- Unidirectional Utilized Bandwidth - Unidirectional Utilized Bandwidth
- Administrative Group - Administrative Group
- Extended Administrative Group - Extended Administrative Group
- Traffic Engineering Metric - TE Metric
4. Reused TE link attributes 4. Reused TE link attributes
This section defines the use case and code points from the OSPFv2 This section defines the use case and code points from the OSPFv2
Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV
Registry for some of the link attributes that have been originally Registry for some of the link attributes that have been originally
defined for TE or GMPLS. defined for TE or GMPLS.
4.1. Shared Risk Link Group (SRLG) 4.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 TBD2 is used. the SRLG in the OSPFv3 Router-Link TLV, TLV type 12 is used.
4.2. Extended Metrics 4.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,
skipping to change at page 8, line 35 skipping to change at page 8, line 35
16 - Unidirectional Residual Bandwidth 16 - Unidirectional Residual Bandwidth
17 - Unidirectional Available Bandwidth 17 - Unidirectional Available Bandwidth
18 - Unidirectional Utilized Bandwidth 18 - Unidirectional Utilized Bandwidth
To advertise extended link metrics in the OSPFv3 Extended LSA Router- To advertise extended link metrics in the OSPFv3 Extended LSA Router-
Link TLV, the same format for the sub-TLVs defined in [RFC7471] is Link TLV, the same format for the sub-TLVs defined in [RFC7471] is
used with the following TLV types: used with the following TLV types:
TBD3 - Unidirectional Link Delay 13 - Unidirectional Link Delay
TBD4 - Min/Max Unidirectional Link Delay 14 - Min/Max Unidirectional Link Delay
TBD5 - Unidirectional Delay Variation 15 - Unidirectional Delay Variation
TBD6 - Unidirectional Link Loss 16 - Unidirectional Link Loss
TBD7 - Unidirectional Residual Bandwidth 17 - Unidirectional Residual Bandwidth
TBD8 - Unidirectional Available Bandwidth 18 - Unidirectional Available Bandwidth
TBD9 - Unidirectional Utilized Bandwidth 19 - Unidirectional Utilized Bandwidth
4.3. Administrative Group 4.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.
One use case where advertisement of the Extended Administrative One use case where advertisement of the Extended Administrative
Group(s) for a link is required is described in Group(s) for a link is required is described in
[I-D.ietf-lsr-flex-algo]. [I-D.ietf-lsr-flex-algo].
skipping to change at page 9, line 28 skipping to change at page 9, line 28
19 - Administrative Group 19 - Administrative Group
20 - Extended Administrative Group 20 - Extended Administrative Group
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:
TBD10 - Administrative Group 20 - Administrative Group
TBD11 - Extended Administrative Group 21 - Extended Administrative Group
4.4. Traffic Engineering Metric 4.4. TE Metric
[RFC3630] defines Traffic Engineering Metric. [RFC3630] defines TE Metric.
To advertise the Traffic Engineering Metric in the OSPFv2 Extended To advertise the TE Metric in the OSPFv2 Extended Link TLV, the same
Link TLV, the same format for the sub-TLV defined in section 2.5.5 of format for the sub-TLV defined in section 2.5.5 of [RFC3630] is used
[RFC3630] is used and TLV type TBD12 is used. Similarly, for OSPFv3 and TLV type 22 is used. Similarly, for OSPFv3 to advertise the TE
to advertise the Traffic Engineering Metric in the OSPFv3 Router-Link Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used.
TLV, TLV type TBD13 is used.
5. Maximum Link Bandwidth 5. 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 TBD14. 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 TBD15. TLV type 23.
6. Local Interface IPv6 Address Sub-TLV 6. 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 TBD16. used with TLV type 24.
7. Remote Interface IPv6 Address Sub-TLV 7. 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 TBD17. used with TLV type 25.
8. Deployment Considerations 8. Deployment Considerations
If link attributes are advertised associated with zero length If link attributes are advertised associated with zero length
application bit masks for both standard applications and user defined application bit masks for both standard applications and user defined
applications, then that set of link attributes MAY be used by any applications, then that set of link attributes MAY be used by any
application. If support for a new application is introduced on any application. If support for a new application is introduced on any
node in a network in the presence of such advertisements, these node in a network in the presence of such advertisements, these
advertisements MAY be used by the new application. If this is not advertisements MAY be used by the new application. If this is not
what is intended, then existing advertisements MUST be readvertised what is intended, then existing advertisements MUST be readvertised
skipping to change at page 13, line 17 skipping to change at page 13, line 4
12.1. OSPFv2 12.1. OSPFv2
OSPFv2 Extended Link TLV Sub-TLVs registry [RFC7684] defines sub-TLVs OSPFv2 Extended Link TLV Sub-TLVs registry [RFC7684] defines sub-TLVs
at any level of nesting for OSPFv2 Extended Link TLVs. This at any level of nesting for OSPFv2 Extended Link TLVs. This
specification updates OSPFv2 Extended Link TLV sub-TLVs registry with specification updates OSPFv2 Extended Link TLV sub-TLVs registry with
the following TLV types: the following TLV types:
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
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
TBD12 (22 Recommended) - Traffic Engineering Metric 22 - TE Metric
TBD14 (21 Recommended) - Maximum Link Bandwidth 23 - Maximum Link Bandwidth
12.2. OSPFv3 12.2. OSPFv3
OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs at OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs at
any level of nesting for OSPFv3 Extended LSAs. This specification any level of nesting for OSPFv3 Extended LSAs. This specification
updates OSPFv3 Extended LSA Sub-TLV Registry with the following TLV updates OSPFv3 Extended LSA Sub-TLV Registry with the following TLV
types: types:
TBD1 (10 Recommended) - Application Specific Link Attributes 11 - Application Specific Link Attributes
TBD2 (11 Recommended) - Shared Risk Link Group 12 - Shared Risk Link Group
TBD3 (12 Recommended) - Unidirectional Link Delay 13 - Unidirectional Link Delay
TBD4 (13 Recommended) - Min/Max Unidirectional Link Delay
TBD5 (14 Recommended) - Unidirectional Delay Variation 14 - Min/Max Unidirectional Link Delay
TBD6 (15 Recommended) - Unidirectional Link Loss 15 - Unidirectional Delay Variation
TBD7 (16 Recommended) - Unidirectional Residual Bandwidth 16 - Unidirectional Link Loss
TBD8 (17 Recommended) - Unidirectional Available Bandwidth 16 - Unidirectional Residual Bandwidth
TBD9 (18 Recommended) - Unidirectional Utilized Bandwidth 18 - Unidirectional Available Bandwidth
TBD10 (19 Recommended) - Administrative Group 19 - Unidirectional Utilized Bandwidth
TBD11 (20 Recommended) - Extended Administrative Group 20 - Administrative Group
21 - Extended Administrative Group
TBD13 (21 Recommended) - Traffic Engineering Metric 22 - TE Metric
TBD15 (22 Recommended) - Maximum Link Bandwidth 23 - Maximum Link Bandwidth
TBD16 (23 Recommended) - Local Interface IPv6 Address Sub-TLV 24 - Local Interface IPv6 Address Sub-TLV
TBD17 (24 Recommended) - Local Interface IPv6 Address Sub-TLV 25 - Remote Interface IPv6 Address Sub-TLV
13. Contributors 13. 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
skipping to change at page 16, line 30 skipping to change at page 15, line 50
15.2. Informative References 15.2. Informative References
[I-D.ietf-isis-te-app] [I-D.ietf-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS TE Attributes per application", draft- J. Drake, "IS-IS TE Attributes per application", draft-
ietf-isis-te-app-06 (work in progress), April 2019. ietf-isis-te-app-06 (work in progress), April 2019.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-03 (work in progress), July 2019. algo-04 (work in progress), September 2019.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc4203>.
 End of changes. 55 change blocks. 
88 lines changed or deleted 85 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/