--- 1/draft-ietf-ospf-te-link-attr-reuse-09.txt 2019-10-30 05:13:10.231333511 -0700 +++ 2/draft-ietf-ospf-te-link-attr-reuse-10.txt 2019-10-30 05:13:10.267334422 -0700 @@ -1,49 +1,51 @@ LSR Working Group P. Psenak, Ed. Internet-Draft L. Ginsberg Intended status: Standards Track Cisco Systems -Expires: March 22, 2020 W. Henderickx +Expires: May 2, 2020 W. Henderickx Nokia J. Tantsura Apstra J. Drake Juniper Networks - September 19, 2019 + October 30, 2019 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 Various link attributes have been defined in OSPF in the context of - the MPLS Traffic Engineering (TE) and GMPLS. Many of these link - attributes can be used for applications other than MPLS TE or GMPLS. - This document defines how to distribute such attributes in OSPFv2 and - OSPFv3 for applications other than MPLS TE or GMPLS. + the MPLS Traffic Engineering (TE) and GMPLS. Since the original + RSVP-TE use case was defined, additional applications (e.g., SRTE, + LFA) have been defined which also make use of the link attribute + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,32 +64,34 @@ 3. Advertisement of Application Specific Values . . . . . . . . 4 4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 7 4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 7 4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 8 4.3. Administrative Group . . . . . . . . . . . . . . . . . . 9 4.4. TE Metric . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Maximum Link Bandwidth . . . . . . . . . . . . . . . . . . . 9 6. Local Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 7. Remote Interface IPv6 Address Sub-TLV . . . . . . . . . . . . 10 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 - 9. Attribute Advertisements and Enablement . . . . . . . . . . . 10 - 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Use of TE LSA Advertisements . . . . . . . . . . . . . . 10 + 8.2. Use of Zero Length Application Identifier Bit Masks . . . 11 + 9. Attribute Advertisements and Enablement . . . . . . . . . . . 11 + 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 12.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 15.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + 15.2. Informative References . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Various link attributes have been defined in OSPFv2 [RFC2328] and 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 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]. @@ -187,98 +191,99 @@ 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 the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 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 | +- -+ | ... | where: Type: 10 (OSPFv2), 11 (OSPFv3) Length: variable - SABML: Standard Application Bit-Mask Length. It MUST be a - multiple of 4 bytes. If the Standard Application Bit-Mask is not - present, the Standard Application Bit-Mask Length MUST be set to - 0. + SABM Length: Standard Application Identifier Bit-Mask Length. It + MUST be a multiple of 4 bytes. If the Standard Application Bit- + Mask is not present, the Standard Application Bit-Mask Length MUST + be set to 0. - UDABML: User Defined Application Bit-Mask Length. It MUST be a - multiple of 4 bytes. If the User Defined Application Bit-Mask is - not present, the User Defined Application Bit-Mask Length MUST be - set to 0. + UDABM Length: User Defined Application Identifier Bit-Mask Length. + It MUST be a multiple of 4 bytes. If the User Defined Application + Bit-Mask is not present, the User Defined Application Bit-Mask + Length MUST be set to 0. - Standard Application Bit-Mask: Optional set of bits, where each - bit represents a single standard application. Bits are defined in - [I-D.ietf-isis-te-app], which also request a new IANA "Link - Attribute Applications" registry under "Interior Gateway Protocol - (IGP) Parameters" for them. The bits are repeated here for - informational purpose: + Standard Application Identifier Bit-Mask: Optional set of bits, + where each bit represents a single standard application. Bits are + defined in [I-D.ietf-isis-te-app], which also request a new IANA + "Link Attribute Applications" registry under "Interior Gateway + Protocol (IGP) Parameters" for them. The bits are repeated here + 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-3: Flexible Algorithm + Bit-2 (F-bit): Loop Free Alternate (LFA). Includes all LFA + types - User Defined Application Bit-Mask: Optional set of bits, where - each bit represents a single user defined application. + User Defined Application Identifier Bit-Mask: Optional set of + bits, where each bit represents a single user defined application. - Standard Application Bits are defined/sent starting with Bit 0. - Additional bit definitions that are defined in the future SHOULD be - assigned in ascending bit order so as to minimize the number of - octets that will need to be transmitted. + Standard Application Identifier Bits are defined/sent starting with + Bit 0. Additional bit definitions that are defined in the future + SHOULD be assigned in ascending bit order so as to minimize the + number of octets that will need to be transmitted. - User Defined Application bits have no relationship to Standard - 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 - to minimize the number of octets required to advertise all of them. + User Defined Application Identifier Bits have no relationship to + Standard 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 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 ignored on receipt. Bits that are NOT transmitted MUST be treated as if they are set to 0 on receipt. If the link attribute advertisement is limited to be used by a specific set of applications, corresponding Bit-Masks MUST be present and application specific bit(s) MUST be set for all applications that use the link attributes advertised in the ASLA sub-TLV. Application Bit-Masks apply to all link attributes that support application specific values and are advertised in the ASLA sub-TLV. The advantage of not making the Application Bit-Masks part 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 format when advertising them in the ASLA sub-TLV. When neither the Standard Application Bits nor the User Defined - Application bits are set (i.e., both SABML and UDABML are 0) in the - ASLA sub-TLV, then the link attributes included in it MUST be - considered as being applicable to all applications. + Application bits are set (i.e., both SABM Length and UDABM Length are + 0) in the ASLA sub-TLV, then the link attributes included in it MUST + be considered as being applicable to all applications. If, however, another advertisement of the same link attribute includes any Application Bit-Mask in the ASLA sub-TLV, applications that are listed in the Application Bit-Masks of such ASLA sub-TLV SHOULD use the attribute advertisement which has the application specific bit set in the Application Bit-Masks. If the same application is listed in the Application Bit-Masks of more then one ASLA sub-TLV, the application SHOULD use the first advertisement and ignore any subsequent advertisements of the same @@ -375,24 +380,20 @@ 18 - Unidirectional Available Bandwidth 19 - Unidirectional Utilized Bandwidth 4.3. Administrative Group [RFC3630] and [RFC7308] define the Administrative Group and Extended 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 Group in the OSPFv2 Extended Link TLV, the same format for the sub- TLVs defined in [RFC3630] and [RFC7308] is used with the following TLV types: 19 - Administrative Group 20 - Extended Administrative Group To advertise Administrative Group and Extended Administrative Group @@ -449,104 +450,141 @@ 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 25. 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 - application bit masks for both standard applications and user defined - applications, then that set of link attributes MAY be used by any - application. If support for a new application is introduced on any - node in a network in the presence of such advertisements, these - advertisements MAY be used by the new application. If this is not - what is intended, then existing advertisements MUST be readvertised - with an explicit set of applications specified before a new - application is introduced. + Application Identifier Bit-Masks for both standard applications and + user defined applications, then that set of link attributes MAY be + used by any application. If support for a new application is + introduced on any node in a network in the presence of such + advertisements, these advertisements MAY be used by the new + application. If this is not what is intended, then existing + advertisements MUST be readvertised with an explicit set of + applications specified before a new application is introduced. 9. Attribute Advertisements and Enablement This document defines extensions to support the advertisement of application specific link attributes. Whether the presence of link attribute advertisements for a given application indicates that the application is enabled on that link depends upon the application. Similarly, whether the absence of link attribute advertisements indicates that the application is not enabled depends upon the application. In the case of RSVP-TE, the advertisement of application specific - link attributes 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 attributes does NOT indicate enablement of SRTE. The advertisements are only used to support constraints which may be applied when specifying an explicit path. SRTE is implicitly enabled on all links which are part of the Segment Routing enabled topology independent of the existence of link attribute advertisements. In the case of LFA, advertisement of application specific link attributes does NOT indicate enablement of LFA on that link. Enablement is controlled by local configuration. - 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 use this mechanism, the specification defining this use MUST define the relationship between application specific link attribute advertisements and enablement for that application. This document allows the advertisement of application specific link attributes with no application identifiers i.e., both the Standard - Application Bit Mask and the User Defined Application Bit Mask are - not present (See Section 3). This supports the use of the link - attribute by any application. In the presence of an application + Application Identifier Bit-Mask and the User Defined Application Bit + Mask are not present (See Section 3). This supports the use of the + link attribute by any application. In the presence of an application where the advertisement of link attribute advertisements is used to infer the enablement of an application on that link (e.g., RSVP-TE), - the absence of the application identifier leaves ambiguous whether + the absence of the Application Identifier leaves ambiguous whether that application is enabled on such a link. This needs to be considered when making use of the "any application" encoding. 10. Backward Compatibility Link attributes may be concurrently advertised in both the TE Opaque 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 link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP TE applications. For example, this implementation of LFA and remote LFA utilizes links attributes such as Shared Risk Link Groups (SRLG) [RFC4203] and Admin Group [[RFC3630] advertised in TE Opaque LSAs. These applications are described in [RFC5286], [RFC7490], [RFC7916] and [RFC8102]. When an OSPF routing domain includes routers using link attributes 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 - SHOULD continue to advertise such OSPFv2 TE Opaque LSAs or the OSPFv3 - Intra-Area-TE-LSA. If there are also OSPF routers using the link - attributes described herein for any other application, OSPF routers - 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- + Non-RSVP TE applications defined in this document (i.e. SRTE and + LFA), OSPF routers in that domain SHOULD continue to advertise such + OSPFv2 TE Opaque LSAs or the OSPFv3 Intra-Area-TE-LSA. In such a + deployment, the advertised attributes SHOULD be the same and Non- RSVP application access to link attributes is a matter of local policy. + When advertising link-attributes for any new applications other then + 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 Existing security extensions as described in [RFC2328], [RFC5340] and [RFC8362] apply to extensions defined in this document. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC5709], [RFC7474], [RFC4552] or [RFC7166] SHOULD be used. @@ -692,26 +732,21 @@ [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, . 15.2. Informative References [I-D.ietf-isis-te-app] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS TE Attributes per application", draft- - ietf-isis-te-app-06 (work in progress), April 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. + ietf-isis-te-app-08 (work in progress), October 2019. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, .