< draft-ietf-ospf-te-link-attr-reuse-09.txt   draft-ietf-ospf-te-link-attr-reuse-10.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: March 22, 2020 W. Henderickx Expires: May 2, 2020 W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Apstra Apstra
J. Drake J. Drake
Juniper Networks Juniper Networks
September 19, 2019 October 30, 2019
OSPF Link Traffic Engineering Attribute Reuse OSPF Link Traffic Engineering Attribute Reuse
draft-ietf-ospf-te-link-attr-reuse-09.txt draft-ietf-ospf-te-link-attr-reuse-10.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. Since the original
attributes can be used for applications other than MPLS TE or GMPLS. RSVP-TE use case was defined, additional applications (e.g., SRTE,
This document defines how to distribute such attributes in OSPFv2 and LFA) have been defined which also make use of the link attribute
OSPFv3 for applications other than MPLS TE or GMPLS. advertisements. This document defines how to distribute link
attributes in OSPFv2 and OSPFv3 for applications other than MPLS TE
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 March 22, 2020. This Internet-Draft will expire on May 2, 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 27 skipping to change at page 2, line 31
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. TE 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 . . . . . . . . . . . 10 8.1. Use of TE LSA Advertisements . . . . . . . . . . . . . . 10
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 8.2. Use of Zero Length Application Identifier Bit Masks . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Attribute Advertisements and Enablement . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12
12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 TE and GMPLS. All these OSPFv3 [RFC5340] in the context of the MPLS TE and GMPLS. All these
attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV
advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In OSPFv3, they advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In OSPFv3, they
are distributed as sub-TLVs of the Link-TLV advertised in the OSPFv3 are distributed as sub-TLVs of the Link-TLV advertised in the OSPFv3
Intra-Area-TE-LSA as defined in [RFC5329]. Intra-Area-TE-LSA as defined in [RFC5329].
skipping to change at page 5, line 10 skipping to change at page 5, line 16
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. It has
the following format: 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 | | SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Bit-Mask | | Standard Application Identifier Bit-Mask |
+- -+ +- -+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Defined Application Bit-Mask | | User Defined Application Identifier Bit-Mask |
+- -+ +- -+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
SABML: Standard Application Bit-Mask Length. It MUST be a SABM Length: Standard Application Identifier Bit-Mask Length. It
multiple of 4 bytes. If the Standard Application Bit-Mask is not MUST be a multiple of 4 bytes. If the Standard Application Bit-
present, the Standard Application Bit-Mask Length MUST be set to Mask is not present, the Standard Application Bit-Mask Length MUST
0. be set to 0.
UDABML: User Defined Application Bit-Mask Length. It MUST be a UDABM Length: User Defined Application Identifier Bit-Mask Length.
multiple of 4 bytes. If the User Defined Application Bit-Mask is It MUST be a multiple of 4 bytes. If the User Defined Application
not present, the User Defined Application Bit-Mask Length MUST be Bit-Mask is not present, the User Defined Application Bit-Mask
set to 0. Length MUST be set to 0.
Standard Application Bit-Mask: Optional set of bits, where each Standard Application Identifier Bit-Mask: Optional set of bits,
bit represents a single standard application. Bits are defined in where each bit represents a single standard application. Bits are
[I-D.ietf-isis-te-app], which also request a new IANA "Link defined in [I-D.ietf-isis-te-app], which also request a new IANA
Attribute Applications" registry under "Interior Gateway Protocol "Link Attribute Applications" registry under "Interior Gateway
(IGP) Parameters" for them. The bits are repeated here for Protocol (IGP) Parameters" for them. The bits are repeated here
informational purpose: for informational purpose:
Bit-0: RSVP TE Bit-0 (R-bit): RSVP TE
Bit-1: Segment Routing TE Bit-1 (S-bit): Segment Routing TE
Bit-2: Loop Free Alternate (LFA). Includes all LFA types Bit-2 (F-bit): Loop Free Alternate (LFA). Includes all LFA
Bit-3: Flexible Algorithm types
User Defined Application Bit-Mask: Optional set of bits, where User Defined Application Identifier Bit-Mask: Optional set of
each bit represents a single user defined application. bits, where each bit represents a single user defined application.
Standard Application Bits are defined/sent starting with Bit 0. Standard Application Identifier Bits are defined/sent starting with
Additional bit definitions that are defined in the future SHOULD be Bit 0. Additional bit definitions that are defined in the future
assigned in ascending bit order so as to minimize the number of SHOULD be assigned in ascending bit order so as to minimize the
octets that will need to be transmitted. number of octets that will need to be transmitted.
User Defined Application bits have no relationship to Standard User Defined Application Identifier Bits have no relationship to
Application bits and are NOT managed by IANA or any other standards Standard Application bits and are NOT managed by IANA or any other
body. It is recommended that bits are used starting with Bit 0 so as standards body. It is recommended that bits are used starting with
to minimize the number of octets required to advertise all of them. Bit 0 so as 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 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 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 ASLA sub-TLV. format when advertising them in the ASLA sub-TLV.
When neither the Standard Application Bits nor the User Defined When neither the Standard Application Bits nor the User Defined
Application bits are set (i.e., both SABML and UDABML are 0) in the Application bits are set (i.e., both SABM Length and UDABM Length are
ASLA sub-TLV, then the link attributes included in it MUST be 0) in the ASLA sub-TLV, then the link attributes included in it MUST
considered as being applicable to all applications. be considered as being applicable to all applications.
If, however, another advertisement of the same link attribute If, however, another advertisement of the same link attribute
includes any Application Bit-Mask in the ASLA sub-TLV, applications includes any Application Bit-Mask in the ASLA sub-TLV, applications
that are listed in the Application Bit-Masks of such ASLA sub-TLV that are listed in the Application Bit-Masks of such ASLA sub-TLV
SHOULD use the attribute advertisement which has the application SHOULD use the attribute advertisement which has the application
specific bit set in the Application Bit-Masks. 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 ASLA sub-TLV, the application SHOULD use the first more then one ASLA sub-TLV, the application SHOULD use the first
advertisement and ignore any subsequent advertisements of the same advertisement and ignore any subsequent advertisements of the same
skipping to change at page 9, line 10 skipping to change at page 9, line 10
18 - Unidirectional Available Bandwidth 18 - Unidirectional Available Bandwidth
19 - 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
Group(s) for a link is required is described in
[I-D.ietf-lsr-flex-algo].
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
20 - Extended Administrative Group 20 - Extended Administrative Group
To advertise Administrative Group and Extended Administrative Group To advertise Administrative Group and Extended Administrative Group
skipping to change at page 10, line 35 skipping to change at page 10, line 31
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 8. Deployment Considerations
8.1. Use of TE LSA Advertisements
Bit Identifers for Standard Applications are defined in Section 3.
All of the identifiers defined in this document are associated with
applications which were already deployed in some networks prior to
the writing of this document. Therefore, such applications have been
deployed using the TE LSA advertisements. The Standard Applications
defined in this document MAY continue to use TE LSA advertisements
for a given link so long as at least one of the following conditions
is true:
The application is RSVP-TE
The application is SRTE or LFA and RSVP-TE is not deployed
anywhere in the network
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
advertisements are required and the attribute values used by SRTE
and/or LFA on all such links is fully congruent with the links and
attribute values used by RSVP-TE
Under the conditions defined above, implementations which support the
extensions defined in this document have the choice of using TE LSA
advertisements or application specific advertisements in support of
SRTE and/or LFA. This will require implementations to provide
controls specifying which type of advertisements are to be sent/
processed on receive for these applications. Further discussion of
the associated issues can be found in Section 10.
New applications which future documents define to make use of the
advertisements defined in this document MUST NOT make use of TE LSA
advertisements.
8.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 bit masks for both standard applications and user defined Application Identifier Bit-Masks for both standard applications and
applications, then that set of link attributes MAY be used by any user defined applications, then that set of link attributes MAY be
application. If support for a new application is introduced on any used by any application. If support for a new application is
node in a network in the presence of such advertisements, these introduced on any node in a network in the presence of such
advertisements MAY be used by the new application. If this is not advertisements, these advertisements MAY be used by the new
what is intended, then existing advertisements MUST be readvertised application. If this is not what is intended, then existing
with an explicit set of applications specified before a new advertisements MUST be readvertised with an explicit set of
application is introduced. applications specified before a new application is introduced.
9. Attribute Advertisements and Enablement 9. 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.
In the case of RSVP-TE, the advertisement of application specific In the case of RSVP-TE, the advertisement of application specific
link attributes implies that RSVP is enabled on that link. link attributes implies that RSVP is enabled on that link. The
absence of RSVP-TE application specific link attributes in
combination with the absence of legacy advertisements implies that
RSVP is NOT enabled on that link.
In the case of SRTE, advertisement of application specific link In the case of SRTE, advertisement of application specific link
attributes does NOT indicate enablement of SRTE. The advertisements attributes does NOT indicate enablement of SRTE. The advertisements
are only used to support constraints which may be applied when are only used to support constraints which may be applied when
specifying an explicit path. SRTE is implicitly enabled on all links specifying an explicit path. SRTE is implicitly enabled on all links
which are part of the Segment Routing enabled topology independent of which are part of the Segment Routing enabled topology independent of
the existence of link attribute advertisements. the existence of link attribute advertisements.
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
specific link attributes does NOT indicate enablement of Flexible
Algorithm on that link. Rather the attributes are used to determine
what links are included/excluded in the algorithm specific
constrained SPF. This is fully specified in
[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 Identifier Bit-Mask and the User Defined Application Bit
not present (See Section 3). This supports the use of the link Mask are not present (See Section 3). This supports the use of the
attribute by any application. In the presence of an application link attribute by any application. In the presence of an application
where the advertisement of link attribute advertisements is used to where the advertisement of link attribute advertisements is used to
infer the enablement of an application on that link (e.g., RSVP-TE), infer the enablement of an application on that link (e.g., RSVP-TE),
the absence of the application identifier leaves ambiguous whether the absence of the Application Identifier leaves ambiguous whether
that application is enabled on such a link. This needs to be that application is enabled on such a link. This needs to be
considered when making use of the "any application" encoding. considered when making use of the "any application" encoding.
10. Backward Compatibility 10. 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 and the Extended Link Opaque LSA in OSPFv2 and the OSPFv3 Intra- 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. 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], [RFC7916] These applications are described in [RFC5286], [RFC7490], [RFC7916]
and [RFC8102]. and [RFC8102].
When an OSPF routing domain includes routers using link attributes When an OSPF routing domain includes routers using link attributes
from the OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA for from the OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA for
Non-RSVP TE applications such as LFA, OSPF routers in that domain Non-RSVP TE applications defined in this document (i.e. SRTE and
SHOULD continue to advertise such OSPFv2 TE Opaque LSAs or the OSPFv3 LFA), OSPF routers in that domain SHOULD continue to advertise such
Intra-Area-TE-LSA. If there are also OSPF routers using the link OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA. In such a
attributes described herein for any other application, OSPF routers deployment, the advertised attributes SHOULD be the same and Non-
in the routing domain will also need to advertise these attributes in
OSPFv2 Extended Link Attributes LSAs or OSPFv3 E-Router-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 RSVP application access to link attributes is a matter of local
policy. policy.
When advertising link-attributes for any new applications other then
RSVP-TE, SRTE or LFA, OSPF routers MUST NOT use TE Opaque LSA or
OSPFv3 Intra-Area-TE-LSA. Instead, advertisement in the OSPFv2
Extended Link Attributes LSAs or OSPFv3 E-Router-LSA MUST be used.
It is RECOMMENDED to advertise link-attributes for RSVP-TE in the
existing TE LSAs.
11. Security Considerations 11. 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.
skipping to change at page 15, line 45 skipping to change at page 16, line 34
[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 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-08 (work in progress), October 2019.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
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. 30 change blocks. 
90 lines changed or deleted 123 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/