< draft-ietf-ospf-te-link-attr-reuse-03.txt   draft-ietf-ospf-te-link-attr-reuse-04.txt >
Network Working Group P. Psenak, Ed. LSR Working Group P. Psenak, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: August 3, 2018 L. Ginsberg Expires: December 17, 2018 L. Ginsberg
Cisco Systems Cisco Systems
W. Henderickx W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Nuage Networks Nuage Networks
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Drake J. Drake
Juniper Networks Juniper Networks
January 30, 2018 June 15, 2018
OSPFv2 Link Traffic Engineering (TE) Attribute Reuse OSPF Link Traffic Engineering (TE) Attribute Reuse
draft-ietf-ospf-te-link-attr-reuse-03.txt draft-ietf-ospf-te-link-attr-reuse-04.txt
Abstract Abstract
Various link attributes have been defined in OSPFv2 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 purposes other than MPLS Traffic attributes can be used for applications other than MPLS Traffic
Engineering or GMPLS. This documents defines how to distribute such Engineering or GMPLS. This document defines how to distribute such
attributes in OSPFv2 for applications other than MPLS Traffic attributes in OSPFv2 and OSPFv3 for applications other than MPLS
Engineering or GMPLS purposes. 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 August 3, 2018. This Internet-Draft will expire on December 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 38 skipping to change at page 2, line 38
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Link attributes examples . . . . . . . . . . . . . . . . . . 4 2. Link attributes examples . . . . . . . . . . . . . . . . . . 4
3. Advertising Link Attributes . . . . . . . . . . . . . . . . . 4 3. Advertising Link Attributes . . . . . . . . . . . . . . . . . 4
3.1. TE Opaque LSA . . . . . . . . . . . . . . . . . . . . . . 4 3.1. OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA . . . . 4
3.2. Extended Link Opaque LSA . . . . . . . . . . . . . . . . 5 3.2. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA . 5
3.3. Selected Approach . . . . . . . . . . . . . . . . . . . . 5 3.3. Selected Approach . . . . . . . . . . . . . . . . . . . . 6
4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 6 4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 6
4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 6 4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 6
4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 6 4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 7
4.3. Administrative Group . . . . . . . . . . . . . . . . . . 7 4.3. Administrative Group . . . . . . . . . . . . . . . . . . 8
5. Advertisement of Application Specific Values . . . . . . . . 7 5. Advertisement of Application Specific Values . . . . . . . . 8
5.1. Special Considerations for Maximum Link Bandwidth . . . . 10 6. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 11
5.2. Special Considerations for Unreserved Bandwidth . . . . . 11 7. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 11
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 8. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 12
7. Attribute Advertisements and Enablement . . . . . . . . . . . 11 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 10. Attribute Advertisements and Enablement . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Various link attributes have been defined in OSPFv2 [RFC2328] in the Various link attributes have been defined in OSPFv2 [RFC2328] and
context of the MPLS traffic engineering and GMPLS. All these OSPFv3 [RFC5340] in the context of the MPLS traffic engineering and
attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV GMPLS. All these attributes are distributed by OSPFv2 as sub-TLVs of
advertised in the OSPFv2 TE Opaque LSA [RFC3630]. the Link-TLV advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In
OSPFv3, they are distributed as sub-TLVs of the Link-TLV advertised
in the OSPFv3 Intra-Area-TE-LSA as defined in [RFC5329].
Many of these link attributes are useful outside of the traditional Many of these link attributes are useful outside of traditional MPLS
MPLS Traffic Engineering or GMPLS. This brings its own set of Traffic Engineering or GMPLS. This brings its own set of problems,
problems, in particular how to distribute these link attributes in in particular how to distribute these link attributes in OSPFv2 and
OSPFv2 when MPLS TE or 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 SR. Included among [RFC7855] discusses use cases/requirements for SR. Included among
these use cases is SRTE. If both RSVP-TE and SRTE are deployed in a these use cases is SRTE. If both RSVP-TE and SRTE are deployed in a
network, link attribute advertisements can be used by one or both of network, link attribute advertisements can be used by one or both of
these applications. As there is no requirement for the link these applications. As there is no requirement for the link
attributes advertised on a given link used by SRTE to be identical to attributes advertised on a given link used by SRTE to be identical to
the link attributes advertised on that same link used by RSVP-TE, the link attributes advertised on that same link used by RSVP-TE,
there is a clear requirement to indicate independently which link there is a clear requirement to indicate independently which link
attribute advertisements are to be used by each application. attribute advertisements are to be used by each application.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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. Link attributes examples 2. Link attributes examples
This section lists some of the link attributes originally defined for This section lists some of the link attributes originally defined for
MPLS Traffic Engineering that can be used for other purposes in MPLS Traffic Engineering that can be used for other applications in
OSPFv2. The list doesn't necessarily contain all the required OSPFv2 and OSPFv3. The list doesn't necessarily contain all the
attributes. required attributes.
1. Remote Interface IP address [RFC3630] - OSPFv2 currently cannot 1. Remote Interface IP address [RFC3630] - OSPFv2 currently cannot
distinguish between parallel links between two OSPFv2 routers. distinguish between parallel links between two OSPFv2 routers.
As a result, the two-way connectivity check performed during SPF As a result, the two-way connectivity check performed during SPF
may succeed when the two routers disagree on which of the links may succeed when the two routers disagree on which of the links
to use for data traffic. to use for data traffic.
2. Link Local/Remote Identifiers - [RFC4203] - Used for the two-way 2. Link Local/Remote Identifiers - [RFC4203] - Used for the two-way
connectivity check for parallel unnumbered links. Also used for connectivity check for parallel unnumbered links. Also used for
identifying adjacencies for unnumbered links in Segment Routing identifying adjacencies for unnumbered links in Segment Routing
skipping to change at page 4, line 33 skipping to change at page 4, line 33
3. Shared Risk Link Group (SRLG) [RFC4203] - In IPFRR, the SRLG is 3. Shared Risk Link Group (SRLG) [RFC4203] - In IPFRR, the SRLG is
used to compute diverse backup paths [RFC5714]. used to compute diverse backup paths [RFC5714].
4. Unidirectional Link Delay/Loss Metrics [RFC7471] - Could be used 4. Unidirectional Link Delay/Loss Metrics [RFC7471] - Could be used
for the shortest path first (SPF) computation using alternate for the shortest path first (SPF) computation using alternate
metrics within an OSPF area. metrics within an OSPF area.
3. Advertising Link Attributes 3. Advertising Link Attributes
This section outlines possible approaches for advertising link This section outlines possible approaches for advertising link
attributes originally defined for MPLS Traffic Engineering purposes attributes originally defined for MPLS Traffic Engineering or GMPLS
or GMPLS when they are used for other applications. when they are used for other applications.
3.1. TE Opaque LSA 3.1. OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA
One approach for advertising link attributes is to continue to use TE One approach for advertising link attributes is to continue to use
Opaque LSA ([RFC3630]). There are several problems with this the OSPFv2 TE Opaque LSA [RFC3630] or the OSPFv3 Intra-Area-TE-LSA
approach: [RFC5329]. There are several problems with this approach:
1. Whenever the link is advertised in a TE Opaque LSA, the link 1. Whenever the link is advertised in an OSPFv2 TE Opaque LSA or in
becomes a part of the TE topology, which may not match IP routed an OSPFv3 Intra-Area-TE-LSA, the link becomes a part of the TE
topology. By making the link part of the TE topology, remote topology, which may not match IP routed topology. By making the
nodes may mistakenly believe that the link is available for MPLS link part of the TE topology, remote nodes may mistakenly believe
TE or GMPLS, when, in fact, MPLS is not enabled on the link. that the link is available for MPLS TE or GMPLS, when, in fact,
MPLS is not enabled on the link.
2. The TE Opaque LSA carries link attributes that are not used or 2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA advertise
required by MPLS TE or GMPLS. There is no mechanism in a TE link attributes that are not used or required by MPLS TE or
Opaque LSA to indicate which of the link attributes are passed to GMPLS. There is no mechanism in these TE LSAs to indicate which
MPLS TE application and which are used by other applications of the link attributes are passed to the MPLS TE application and
including OSPFv2 itself. which are used by other applications including OSPF itself.
3. Link attributes used for non-TE purposes are partitioned across 3. Link attributes used for non-TE applications are partitioned
multiple LSAs - the TE Opaque LSA and the Extended Link Opaque across multiple LSAs - the TE Opaque LSA and the Extended Link
LSA. This partitioning will require implementations to lookup Opaque LSA in OSPFv2 and the OSPFv3 Intra-Area-TE-LSA and OSPFv3
multiple LSAs to extract link attributes for a single link, Extended LSA Router-Link TLV [RFC8362] in OSPFv3. This
bringing needless complexity to OSPFv2 implementations. partitioning will require implementations to lookup multiple LSAs
to extract link attributes for a single link, bringing needless
complexity to OSPF implementations.
The advantage of this approach is that there is no additional The advantage of this approach is that there is no additional
standardization requirement to advertise the TE/GMPL attributes for standardization requirement to advertise the TE/GMPL attributes for
other applications. Additionally, link attributes are only other applications. Additionally, link attributes are only
advertised once when both OSPF TE and other applications are deployed advertised once when both OSPF TE and other applications are deployed
on the same link. This is not expected to be a common deployment on the same link. This is not expected to be a common deployment
scenario. scenario.
3.2. Extended Link Opaque LSA 3.2. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
An alternative approach for advertising link attributes is to use An alternative approach for advertising link attributes is to use
Extended Link Opaque LSAs as defined in [RFC7684]. This LSA was Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and
defined as a generic container for distribution of the extended link Extended Router-LSAs [RFC8362] for OSPFv3. These LSAs were defined
attributes. There are several advantages in using Extended Link LSA: as a generic containers for distribution of the extended link
attributes. There are several advantages in using 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 the [RFC3630]. compatible with the [RFC3630] and [RFC5329].
2. The TE Opaque LSA remains truly opaque to OSPFv2 as originally 2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains
defined in [RFC3630]. Its content is not inspected by OSPFv2 and truly opaque to OSPFv2 and OSPFv3 as originally defined in
OSPFv2 acts as a pure transport. [RFC3630] and [RFC5329] respectively. Their contents are not
inspected by OSPF, that act 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 TE and
link attributes used by other OSPFv2 applications. link attributes used by other OSPFv2 or OSPFv3 applications.
4. All link attributes that are used by OSPFv2 applications are 4. All link attributes that are used by other applications are
advertised in a single LSA, the Extended Link Opaque LSA. advertised in a single LSA, the Extended Link Opaque LSA in
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. Additionally, there will be additional Attribute LSAs in OSPFv2 or the Intra-Area-TE-LSA and E-Router-LSA in
standardization effort. However, this could also be viewed as an OSPFv3. Additionally, there will be additional standardization
advantage as the non-TE use cases for the TE link attributes are effort. However, this could also be viewed as an advantage as the
documented and validated by the OSPF working group. non-TE use cases for the TE link attributes are documented and
validated by the LSR working group.
3.3. Selected Approach 3.3. Selected Approach
It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to It is RECOMMENDED to use the Extended Link Opaque LSA [RFC7684] and
advertise any link attributes used for non-TE purposes in OSPFv2, E-Router-LSA [RFC8362] to advertise any link attributes used for non-
including those that have been originally defined for TE purposes. TE applications in OSPFv2 or OSPFv3 respectively, including those
TE link attributes used for TE purposes continue to use TE Opaque LSA that have been originally defined for TE applications.
([RFC3630]).
It is also RECOMMENDED that TE link attributes used for RSVP-TE/GMPLS
continue to use OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-
TE-LSA [RFC5329].
It is also RECOMMENDED to keep the format of the link attribute TLVs It is also RECOMMENDED to keep the format of the link attribute TLVs
that have been defined for TE purposes unchanged even when they are that have been defined for TE applications unchanged even when they
used for non-TE purposes. are used for non-TE applications.
Finally, it is RECOMMENDED to allocate unique code points for link Finally, it is RECOMMENDED to allocate unique code points for these
attribute TLVs that have been defined for TE purposes for the OSPFv2 TE link attribute TLVs in the OSPFv2 Extended Link TLV Sub-TLV
Extended Link TLV Sub-TLV Registry as defined in [RFC7684]. For each Registry [RFC7684] and in the OSPFv3 Extended LSA Sub-TLV Registry
reused TLV, the code point will be defined in an IETF document along [RFC8362]. For each reused TLV, the code point will be defined in an
with the expected usecase(s). IETF document along with the expected use-case(s).
4. Reused TE link attributes 4. Reused TE link attributes
This section defines the use case and code points for the OSPFv2 This section defines the use case and code points for the OSPFv2
Extended Link TLV Sub-TLV Registry for some of the link attributes Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV
that have been originally defined for TE or GMPLS purposes. Registry for some of the link attributes that have been originally
defined for TE or GMPLS.
Remote interface IP address and Link Local/Remote Identifiers have Remote interface IP address and Link Local/Remote Identifiers have
been added as sub-TLVs of OSPFv2 Extended Link TLV by been added as sub-TLVs of OSPFv2 Extended Link TLV by [RFC8379].
[I-D.ietf-ospf-link-overload]. Link Local/Remote Identifiers are already included in the OSPFv3
Router-Link TLV [RFC8362].
4.1. Shared Risk Link Group (SRLG) 4.1. Shared Risk Link Group (SRLG)
The SRLG of a link can be used in IPFRR to compute a backup path that The SRLG of a link can be used in IPFRR to compute a backup path that
does not share any SRLG group with the protected link. does not share any SRLG group with the 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 of the sub-TLV as defined in section 1.3. of the same format for the sub-TLV defined in section 1.3 of [RFC4203]
[RFC4203] is used and TLV type TBD1 is used. is used and TLV type TBD1 is used. Similarly, for OSPFv3 to
advertise the SRLG in the OSPFv3 Router-Link TLV, TLV type TBD2 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 best paths loss characteristics. All these can be used to compute best paths
within an OSPF area to satisfy requirements for bandwidth, delay within an OSPF area to satisfy requirements for bandwidth, delay
(nominal or worst case) or loss. (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 of the sub-TLVs as defined in [RFC7471] is used with the same format for the sub-TLVs defined in [RFC7471] is used with
following TLV types: the following TLV types:
TBD2 - Unidirectional Link Delay TBD3 - Unidirectional Link Delay
TBD3 - Min/Max Unidirectional Link Delay TBD4 - Min/Max Unidirectional Link Delay
TBD4 - Unidirectional Delay Variation TBD5 - Unidirectional Delay Variation
TBD5 - Unidirectional Link Loss TBD6 - Unidirectional Link Loss
TBD6 - Unidirectional Residual Bandwidth
TBD7 - Unidirectional Available Bandwidth TBD7 - Unidirectional Residual Bandwidth
TBD8 - Unidirectional Utilized Bandwidth TBD8 - Unidirectional Available Bandwidth
TBD9 - Unidirectional Utilized Bandwidth
To advertise extended link metrics in the OSPFv3 Extended LSA Router-
Link TLV, the same format for the sub-TLVs defined in [RFC7471] is
used with the following TLV types:
TBD10 - Unidirectional Link Delay
TBD11 - Min/Max Unidirectional Link Delay
TBD12 - Unidirectional Delay Variation
TBD13 - Unidirectional Link Loss
TBD14 - Unidirectional Residual Bandwidth
TBD15 - Unidirectional Available Bandwidth
TBD16 - Unidirectional Utilized Bandwidth
4.3. Administrative Group 4.3. Administrative Group
[RFC3630] and [RFC7308] define Administrative Group and Extended [RFC3630] and [RFC7308] define the Administrative Group and Extended
Administrative Group sub-TLVs. 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.hegdeppsenak-isis-sr-flex-algo]. [I-D.ietf-lsr-flex-algo].
To advertise the Administrative Group and Extended Administrative
Group in the OSPFv2 Extended Link TLV, the same format for the sub-
TLVs defined in [RFC3630] and [RFC7308] is used with the following
TLV types:
TBD17 - Administrative Group
TBD18 - Extended Administrative Group
To advertise Administrative Group and Extended Administrative Group To advertise Administrative Group and Extended Administrative Group
in the OSPFv2 Extended Link TLV, the same format of the sub-TLVs as in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs
defined in [RFC3630] and [RFC7308] is used with following TLV types: defined in [RFC3630] and [RFC7308] is used with the following TLV
types:
TBD9 - Administrative Group TBD19 - Administrative Group
TBD10 - Extended Administrative Group TBD20 - Extended Administrative Group
5. Advertisement of Application Specific Values 5. Advertisement of Application Specific Values
Multiple applications can utilize link attributes that are flooded by Multiple applications can utilize link attributes that are advertised
OSPFv2. Some examples of applications using the link attributes are by OSPF. Some examples of applications using the link attributes are
Segment Routing Traffic Engineering and LFA [RFC5286]. Segment Routing Traffic Engineering and LFA [RFC5286].
In some cases the link attribute only has a single value that is
applicable to all applications. An example is a Remote interface IP
address or Link Local/Remote Identifiers
[I-D.ietf-ospf-link-overload].
In some cases the link attribute MAY have different values for In some cases the link attribute MAY have different values for
different applications. An example could be SRLG [Section 4.1], different applications. An example could be SRLG [Section 4.1],
where values used by LFA could be different then the values used by where values used by LFA could be different then the values used by
Segment Routing Traffic Engineering. Segment Routing Traffic Engineering.
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 Extended Link Attribute sub-TLV of the Extended Link attribute, a new Application Specific Link Attributes (ASLA) sub-TLV
TLV [RFC7471] is defined. The Extended Link Attribute sub-TLV is an is defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
optional sub-TLV and can appear multiple times in the Extended Link Link TLV [RFC7471] and OSPFv3 Router-Link TLV [RFC8362]. The ASLA
TLV. It has following format: 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABML | UDABML | Reserved | | SABML | UDABML | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Bit-Mask | | Standard Application Bit-Mask |
+- -+ +- -+
skipping to change at page 8, line 26 skipping to change at page 9, 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: TBD11, suggested value 8 Type: TBD21 (OSPFv2), TBD22 (OSPFv3)
Length: variable Length: variable
SABML: Standard Application Bit-Mask Length. If the Standard SABML: Standard Application Bit-Mask Length. If the Standard
Application Bit-Mask is not present, the Standard Application Bit- Application Bit-Mask is not present, the Standard Application Bit-
Mask Length MUST be set to 0. Mask Length MUST be set to 0.
UDABML: User Defined Application Bit-Mask Length. If the User UDABML: User Defined Application Bit-Mask Length. If the User
Defined Application Bit-Mask is not present, the User Defined Defined Application Bit-Mask is not present, the User Defined
Application Bit-Mask Length MUST be set to 0. Application Bit-Mask Length MUST be set to 0.
skipping to change at page 8, line 48 skipping to change at page 9, line 48
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. The following bits bit represents a single standard application. The following bits
are defined by this document: are defined by this document:
Bit-0: RSVP Traffic Engineering Bit-0: RSVP Traffic Engineering
Bit-1: Segment Routing Traffic Engineering Bit-1: Segment Routing Traffic Engineering
Bit-2: Loop Free Alternate (LFA). Includes all LFA types. Bit-2: Loop Free Alternate (LFA). Includes all LFA types.
Bit-3: Flexible Algorithm as describe in Bit-3: Flexible Algorithm as described in
[I-D.hegdeppsenak-isis-sr-flex-algo]. [I-D.ietf-lsr-flex-algo].
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 may be defined in the future SHOULD Additional bit definitions that are defined in the future SHOULD be
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
octets that will need to be transmitted. octets that will need to be transmitted.
User Defined Application bits have no relationship to Standard User Defined Application bits have no relationship to Standard
Application bits and are NOT managed by IANA or any other standards Application bits and are NOT managed by IANA or any other standards
body. It is recommended that bits are used starting with Bit 0 so as body. It is recommended that bits are used starting with Bit 0 so as
to minimize the number of octets required to advertise all of them. to minimize the number of octets required to advertise all of them.
Undefined bits in both Bit-Masks MUST be transmitted as 0 and MUST be 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 ignored on receipt. Bits that are NOT transmitted MUST be treated as
if they are set to 0 on receipt. 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 Extended Link Attribute use the link attributes advertised in the ASLA sub-TLV.
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 Extended Link application specific values and are advertised in the ASLA sub-TLV.
Attribute 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 we can keep the format of the
link attributes that have been defined previously and reuse the same link attributes that have been defined previously and reuse the same
format when advertising them in the Extended Link Attribute sub-TLV. format when advertising them in the ASLA sub-TLV.
If the link attribute is advertised and there is no Application Bit- When neither the Standard Application Bits nor the User Defined
Mask present in the Extended Link Attribute Sub-TLV, the link Application bits are set (i.e., both SABML and UDABML are 0) in the
attribute advertisement MAY be used by any application. If, however, ASLA sub-TLV, then the link attributes included in it MUST be
another advertisement of the same link attribute includes any considered as being applicable to all applications.
Application Bit-Mask in the Extended Link Attribute sub-TLV,
applications that are listed in the Application Bit-Masks of such If, however, another advertisement of the same link attribute
Extended Link Attribute sub-TLV SHOULD use the attribute includes any Application Bit-Mask in the ASLA sub-TLV, applications
advertisement which has the application specific bit set in the that are listed in the Application Bit-Masks of such ASLA sub-TLV
Application Bit-Masks. 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 application is listed in the Application Bit-Masks of
more then one Extended Link Attribute sub-TLV, the application SHOULD more then one ASLA sub-TLV, the application SHOULD use the first
use the first advertisement and ignore any subsequent advertisements advertisement and ignore any subsequent advertisements of the same
of the same attribute. This situation SHOULD be logged as an error. attribute. This situation SHOULD be logged as an error.
This document defines the set of link attributes for which the This document defines the initial set of link attributes that MUST
Application Bit-Masks may be advertised. If any of the Application use ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in
Bit-Masks is included in the Extended Link Attribute sub-TLV that the OSPFv3 Router-Link TLV. If the ASLA sub-TLV includes any link
advertises any link attribute(s) NOT listed below, the Application attribute(s) NOT listed below, they MUST be ignored. Documents which
Bit-Masks MUST NOT be used for such link attribute(s). It MUST be define new link attributes MUST state whether the new attributes
used for those attribute(s) that support application specific values. support application specific values and as such MUST be advertised in
Documents which define new link attributes MUST state whether the new an ASLA sub-TLV. The link attributes that MUST be advertised in ASLA
attributes support application specific values. The link attributes sub-TLVs are:
to which the Application Bit-Masks may apply are:
- Shared Risk Link Group - Shared Risk Link Group
- Unidirectional Link Delay - Unidirectional Link Delay
- Min/Max Unidirectional Link Delay - Min/Max Unidirectional Link Delay
- Unidirectional Delay Variation - Unidirectional Delay Variation
- Unidirectional Link Loss - Unidirectional Link Loss
skipping to change at page 10, line 30 skipping to change at page 11, line 28
- 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
5.1. Special Considerations for Maximum Link Bandwidth 6. Maximum Link Bandwidth
Maximum link bandwidth is an application independent attribute of the Maximum link bandwidth is an application independent attribute of the
link. When advertised using the Application Specific Link Attributes link that is defined in [RFC3630]. Because it is an application
sub-TLV, multiple values for the same link MUST NOT be advertised. independent attribute, it MUST NOT be advertised in ASLA sub-TLV.
This can be accomplished most efficiently by having a single Instead, it MAY be advertised as a sub-TLV of the Extended Link
advertisement for a given link where both the Standard Application Opaque LSA Extended Link TLV in OSPFv2 [RFC7684] or sub-TLV of OSPFv3
Bit Mask and the User Defined Application Bit Mask are not present E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362].
(See Section Section 5).
Alternatively, similar can be achieved by having a single To advertise the Maximum link bandwidth in the OSPFv2 Extended Link
advertisement for a given link where the Application Bit Mask TLV, the same format for sub-TLV defined in [RFC3630] is used with
identifies all the applications which are making use of the value for TLV type TBD23.
that link.
It is also possible to advertise the same value for a given link To advertise the Maximum link bandwidth in the OSPFv3 Router-Link
multiple times with disjoint sets of applications specified in the TLV, the same format for sub-TLV defined in [RFC3630] is used with
Application Bit Mask. This is less efficient but still valid. TLV type TBD24.
If different values for Maximum Link Bandwidth for a given link are 7. Local Interface IPv6 Address Sub-TLV
advertised, all values MUST be ignored.
5.2. Special Considerations for Unreserved Bandwidth The Local Interface IPv6 Address Sub-TLV is an application
independent attribute of the link that is defined in [RFC5329].
Because it is an application independent attribute, it MUST NOT be
advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a
sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362].
Unreserved bandwidth is an attribute specific to RSVP. When To advertise the Local Interface IPv6 Address Sub-TLV in the OSPFv3
advertised using the Application Specific Link Attributes sub-TLV, Router-Link TLV, the same format for sub-TLV defined in [RFC5329] is
bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application used with TLV type TBD25.
Bit Mask. If an advertisement of Unreserved Bandwidth is received
with bits other than the RSVP-TE bit set, the advertisement MUST be
ignored.
6. Deployment Considerations 8. Remote Interface IPv6 Address Sub-TLV
The Remote Interface IPv6 Address Sub-TLV is an application
independent attribute of the link that is defined in [RFC5329].
Because it is an application independent attribute, it MUST NOT be
advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a
sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV [RFC8362].
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
used with TLV type TBD26.
9. 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
with an explicit set of applications specified before a new with an explicit set of applications specified before a new
application is introduced. application is introduced.
7. Attribute Advertisements and Enablement 10. Attribute Advertisements and Enablement
This document defines extensions to support the advertisement of This document defines extensions to support the advertisement of
application specific link attributes. application specific link attributes.
Whether the presence of link attribute advertisements for a given Whether the presence of link attribute advertisements for a given
application indicates that the application is enabled on that link application indicates that the application is enabled on that link
depends upon the application. Similarly, whether the absence of link depends upon the application. Similarly, whether the absence of link
attribute advertisements indicates that the application is not attribute advertisements indicates that the application is not
enabled depends upon the application. enabled depends upon the application.
skipping to change at page 12, line 7 skipping to change at page 13, line 14
In the case of LFA, advertisement of application specific link In the case of LFA, advertisement of application specific link
attributes does NOT indicate enablement of LFA on that link. attributes does NOT indicate enablement of LFA on that link.
Enablement is controlled by local configuration. Enablement is controlled by local configuration.
In the case of Flexible Algorithm, advertisement of application In the case of Flexible Algorithm, advertisement of application
specific link attributes does NOT indicate enablement of Flexible specific link attributes does NOT indicate enablement of Flexible
Algorithm on that link. Rather the attributes are used to determine Algorithm on that link. Rather the attributes are used to determine
what links are included/excluded in the algorithm specific what links are included/excluded in the algorithm specific
constrained SPF. This is fully specified in constrained SPF. This is fully specified in
[I-D.hegdeppsenak-isis-sr-flex-algo]. [I-D.ietf-lsr-flex-algo].
If, in the future, additional standard applications are defined to If, in the future, additional standard applications are defined to
use this mechanism, the specification defining this use MUST define use this mechanism, the specification defining this use MUST define
the relationship between application specific link attribute the relationship between application specific link attribute
advertisements and enablement for that application. advertisements and enablement for that application.
This document allows the advertisement of application specific link This document allows the advertisement of application specific link
attributes with no application identifiers i.e., both the Standard attributes with no application identifiers i.e., both the Standard
Application Bit Mask and the User Defined Application Bit Mask are Application Bit Mask and the User Defined Application Bit Mask are
not present (See Section Section 5). This supports the use of the not present Section 5. This supports the use of the link attribute
link attribute by any application. In the presence of an application by any application. In the presence of an application where the
where the advertisement of link attribute advertisements is used to advertisement of link attribute advertisements is used to infer the
infer the enablement of an application on that link (e.g., RSVP-TE), enablement of an application on that link (e.g., RSVP-TE), the
the absence of the application identifier leaves ambiguous whether absence of the application identifier leaves ambiguous whether that
that application is enabled on such a link. This needs to be application is enabled on such a link. This needs to be considered
considered when making use of the "any application" encoding. when making use of the "any application" encoding.
8. Backward Compatibility 11. Backward Compatibility
Link attributes may be concurrently advertised in both the TE Opaque Link attributes may be concurrently advertised in both the TE Opaque
LSA [RFC3630] and the Extended Link Opaque LSA [RFC7684]. LSA and the Extended Link Opaque LSA in OSPFv2 and the OSPFv3 Intra-
Area-TE-LSA and OSPFv3 Extended LSA Router-Link TLV in OSPFv3.
In fact, there is at least one OSPF implementation that utilizes the In fact, there is at least one OSPF implementation that utilizes the
link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP
TE applications. For example, this implementation of LFA and remote TE applications. For example, this implementation of LFA and remote
LFA utilizes links attributes such as Shared Risk Link Groups (SRLG) LFA utilizes links attributes such as Shared Risk Link Groups (SRLG)
[RFC4203] and Admin Group [[RFC3630]advertised in TE Opaque LSAs. [RFC4203] and Admin Group [[RFC3630] advertised in TE Opaque LSAs.
These applications are described in [RFC5286], [RFC7490], These applications are described in [RFC5286], [RFC7490], [RFC7916]
[I-D.ietf-rtgwg-lfa-manageability] and and [RFC8102].
[I-D.psarkar-rtgwg-rlfa-node-protection].
When an OSPF routing domain includes routers using link attributes When an OSPF routing domain includes routers using link attributes
from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF from the OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA for
routers in that domain should continue to advertise such TE Opaque Non-RSVP TE applications such as LFA, OSPF routers in that domain
LSAs. If there are also OSPF routers using the link attributes SHOULD continue to advertise such OSPFv2 TE Opaque LSAs or the OSPFv3
described herein for any application, OSPF routers in the routing Intra-Area-TE-LSA. If there are also OSPF routers using the link
domain will also need to advertise these attributes in OSPF Extended attributes described herein for any other application, OSPF routers
Link Attributes LSAs [RFC7684]. In such a deployment, the advertised in the routing domain will also need to advertise these attributes in
attributes SHOULD be the same and Non-RSVP application access to link OSPFv2 Extended Link Attributes LSAs or OSPFv3 E-Router-LSA. In such
attributes is a matter of local policy. a deployment, the advertised attributes SHOULD be the same and Non-
RSVP application access to link attributes is a matter of local
policy.
9. Security Considerations 12. Security Considerations
Implementations must assure that malformed TLV and Sub-TLV Implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors that cause hard OSPFv2 failures. permutations do not result in errors that cause hard OSPF failures.
10. IANA Considerations 13. IANA Considerations
13.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:
TBD1 (9 Recommended) - Shared Risk Link Group TBD21 (10 Recommended) - Application Specific Link Attributes
TBD2 (10 Recommended) - Unidirectional Link Delay TBD1 (11 Recommended) - Shared Risk Link Group
TBD3 (11 Recommended) - Min/Max Unidirectional Link Delay TBD3 (12 Recommended) - Unidirectional Link Delay
TBD4 (12 Recommended) - Unidirectional Delay Variation TBD4 (13 Recommended) - Min/Max Unidirectional Link Delay
TBD5 (13 Recommended) - Unidirectional Link Loss TBD5 (14 Recommended) - Unidirectional Delay Variation
TBD6 (14 Recommended) - Unidirectional Residual Bandwidth TBD6 (15 Recommended) - Unidirectional Link Loss
TBD7 (15 Recommended) - Unidirectional Available Bandwidth TBD7 (16 Recommended) - Unidirectional Residual Bandwidth
TBD8 (16 Recommended) - Unidirectional Utilized Bandwidth TBD8 (17 Recommended) - Unidirectional Available Bandwidth
TBD9 (17 Recommended) - Administrative Group TBD9 (18 Recommended) - Unidirectional Utilized Bandwidth
TBD10 (18 Recommended) - Extended Administrative Group TBD9 (19 Recommended) - Administrative Group
TBD11 (8 Recommended) - Extended Link Attribute TBD17 (20 Recommended) - Extended Administrative Group
11. Acknowledgments TBD23 (21 Recommended) - Maximum Link Bandwidth
13.2. OSPFv3
OSPFv3 Extended LSA Sub-TLV Registry [RFC8362] defines sub-TLVs at
any level of nesting for OSPFv3 Extended LSAs. This specification
updates OSPFv3 Extended LSA Sub-TLV Registry with the following TLV
types:
TBD22 (9 Recommended) - Application Specific Link Attributes
TBD2 (10 Recommended) - Shared Risk Link Group
TBD10 (11 Recommended) - Unidirectional Link Delay
TBD11 (12 Recommended) - Min/Max Unidirectional Link Delay
TBD12 (13 Recommended) - Unidirectional Delay Variation
TBD13 (14 Recommended) - Unidirectional Link Loss
TBD14 (15 Recommended) - Unidirectional Residual Bandwidth
TBD15 (16 Recommended) - Unidirectional Available Bandwidth
TBD16 (17 Recommended) - Unidirectional Utilized Bandwidth
TBD19 (18 Recommended) - Administrative Group
TBD20 (19 Recommended) - Extended Administrative Group
TBD24 (20 Recommended) - Maximum Link Bandwidth
TBD25 (21 Recommended) - Local Interface IPv6 Address Sub-TLV
TBD26 (22 Recommended) - Local Interface IPv6 Address Sub-TLV
14. Acknowledgments
Thanks to Chris Bowers for his review and comments. Thanks to Chris Bowers for his review and comments.
12. References 15. References
12.1. Normative References 15.1. Normative References
[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>.
[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>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[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>.
[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>.
[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>.
12.2. Informative References [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[I-D.hegdeppsenak-isis-sr-flex-algo] 15.2. Informative References
Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
Segment Routing Flexible Algorithm", draft-hegdeppsenak-
isis-sr-flex-algo-01 (work in progress), October 2017.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[I-D.ietf-ospf-link-overload] [I-D.ietf-lsr-flex-algo]
Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L. Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
Jalil, "OSPF Graceful Link shutdown", draft-ietf-ospf- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
link-overload-14 (work in progress), January 2018. algo-00 (work in progress), May 2018.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-24 (work in progress), December 2017. routing-extensions-25 (work in progress), April 2018.
[I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and
M. Horneffer, "Operational management of Loop Free
Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work
in progress), June 2015.
[I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
Protection and Manageability", draft-psarkar-rtgwg-rlfa-
node-protection-05 (work in progress), June 2014.
[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>.
skipping to change at page 15, line 41 skipping to change at page 17, line 35
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>. 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>.
[RFC8379] Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L.
Jalil, "OSPF Graceful Link Shutdown", RFC 8379,
DOI 10.17487/RFC8379, May 2018,
<https://www.rfc-editor.org/info/rfc8379>.
Authors' Addresses Authors' Addresses
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
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
 End of changes. 93 change blocks. 
238 lines changed or deleted 344 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/