--- 1/draft-ietf-isis-te-app-10.txt 2020-02-27 20:13:14.717217579 -0800 +++ 2/draft-ietf-isis-te-app-11.txt 2020-02-27 20:13:14.765218805 -0800 @@ -1,24 +1,24 @@ Networking Working Group L. Ginsberg Internet-Draft P. Psenak Intended status: Standards Track Cisco Systems -Expires: August 9, 2020 S. Previdi +Expires: August 30, 2020 S. Previdi Huawei W. Henderickx Nokia J. Drake Juniper Networks - February 6, 2020 + February 27, 2020 IS-IS TE Attributes per application - draft-ietf-isis-te-app-10 + draft-ietf-isis-te-app-11 Abstract Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Traffic Engineering, Loop Free Alternate) have been defined which also make use of the link attribute advertisements. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application @@ -43,21 +43,21 @@ 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 August 9, 2020. + This Internet-Draft will expire on August 30, 2020. Copyright Notice Copyright (c) 2020 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 @@ -72,69 +72,74 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4 3. Legacy Advertisements . . . . . . . . . . . . . . . . . . . . 4 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 5 4. Advertising Application Specific Link Attributes . . . . . . 6 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 6 4.2. Application Specific Link Attributes sub-TLV . . . . . . 8 4.2.1. Special Considerations for Maximum Link Bandwidth . . 9 4.2.2. Special Considerations for Reservable/Unreserved - Bandwidth . . . . . . . . . . . . . . . . . . . . . . 9 + Bandwidth . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Considerations for Extended TE Metrics . . . . . . . 10 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 10 5. Attribute Advertisements and Enablement . . . . . . . . . . . 11 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 12 6.2. Use of Zero Length Application Identifier Bit Masks . . . 13 6.3. Interoperability, Backwards Compatibility and Migration - Concerns . . . . . . . . . . . . . . . . . . . . . . . . 13 + Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Multiple Applications: Common Attributes with RSVP- - TE . . . . . . . . . . . . . . . . . . . . . . . . . 13 + TE . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.2. Multiple Applications: All Attributes Not Shared with RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 14 - 6.3.3. Interoperability with Legacy Routers . . . . . . . . 14 + 6.3.3. Interoperability with Legacy Routers . . . . . . . . 15 6.3.4. Use of Application Specific Advertisements for RSVP- - TE . . . . . . . . . . . . . . . . . . . . . . . . . 14 + TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Application Specific Link Attributes sub-TLV . . . . . . 15 + 7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 16 + 7.3. Application Specific Link Attributes sub-sub-TLV Registry 16 + 7.4. Link Attribute Application Identifier Registry . . . . . 17 + 7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Advertisement of link attributes by the Intermediate-System-to- Intermediate-System (IS-IS) protocol in support of traffic engineering (TE) was introduced by [RFC5305] and extended by [RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has been associated with deployments supporting Traffic Engineering over Multiprotocol Label Switching (MPLS) in the presence of the Resource Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE [RFC3209]. For the purposes of this document an application is a technology which makes use of link attribute advertisements - examples of which are listed in Section 3. In recent years new applications have been introduced which have use cases for many of the link attributes historically used by RSVP-TE. Such applications include Segment Routing Traffic Engineering (SRTE) - [RFC8402] and Loop Free Alternates (LFA) [RFC5286]. This has - introduced ambiguity in that if a deployment includes a mix of RSVP- - TE support and SRTE support (for example) it is not possible to - unambiguously indicate which advertisements are to be used by RSVP-TE - and which advertisements are to be used by SRTE. If the topologies - are fully congruent this may not be an issue, but any incongruence - leads to ambiguity. + [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates + (LFA) [RFC5286]. This has introduced ambiguity in that if a + deployment includes a mix of RSVP-TE support and SRTE support (for + example) it is not possible to unambiguously indicate which + advertisements are to be used by RSVP-TE and which advertisements are + to be used by SRTE. If the topologies are fully congruent this may + not be an issue, but any incongruence leads to ambiguity. An additional issue arises in cases where both applications are supported on a link but the link attribute values associated with each application differ. Current advertisements do not support advertising application specific values for the same attribute on a specific link. This document defines extensions which address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution which @@ -657,45 +662,55 @@ utilize the application specific advertisements. This can be done in the following step-wise manner: 1)Upgrade all routers to support the extensions in this document 2)Advertise all legacy link attributes using application specific advertisements with L-flag clear and R-bit set. 3)Remove legacy advertisements - Migrating RSVP-TE away from legacy advertisements could result in - some implementation simplification as it allows the removal of code - which encodes/decodes the legacy advertisements. Whether this is - seen as desirable is something for the marketplace to determine. - 7. IANA Considerations - This document defines a new sub-TLV for TLVs 22, 23, 25, 141, 222, - and 223. + This section lists the protocol code point changes introduced by this + document and the related IANA changes required. + + For new registries defined under IS-IS TLV Codepoints Registry with + registration procedure "Expert Review", guidance for designated + experts can be found in [RFC7370]. + +7.1. Application Specific Link Attributes sub-TLV + + This document defines a new sub-TLV in the Sub-TLVs for TLVs 22, 23, + 25, 141, 222, and 223 registry. Type Description 22 23 25 141 222 223 ---- --------------------- ---- ---- ---- ---- ---- ---- 16 Application Specific y y y(s) y y y Link Attributes - This document defines one new TLV: +7.2. Application Specific SRLG TLV + + This document defines one new TLV in the IS-IS TLV Codepoints + Registry. Type Description IIH LSP SNP Purge ---- --------------------- --- --- --- ----- 238 Application Specific n y n n SRLG - This document requests a new IANA registry be created to control the - assignment of sub-sub-TLV codepoints for the Application Specific - Link Attributes sub-TLV. The suggested name of the new registry is +7.3. Application Specific Link Attributes sub-sub-TLV Registry + + This document requests a new IANA registry under the IS-IS TLV + Codepoints Registry be created to control the assignment of sub-sub- + TLV codepoints for the Application Specific Link Attributes sub-TLV + defined in Section 7.1. The suggested name of the new registry is "sub-sub-TLV code points for application specific link attributes". The registration procedure is "Expert Review" as defined in [RFC8126]. The following assignments are made by this document: Type Description --------------------------------------------------------- 0-2 Unassigned 3 Administrative group (color) 4-8 Unassigned 9 Maximum link bandwidth @@ -707,77 +722,95 @@ 18 TE Default Metric 19-32 Unassigned 33 Unidirectional Link Delay 34 Min/Max Unidirectional Link Delay 35 Unidirectional Delay Variation 36 Unidirectional Link Loss 37 Unidirectional Residual Bandwidth 38 Unidirectional Available Bandwidth 39 Unidirectional Utilized Bandwidth 40-255 Unassigned - Note to designated experts: If a link attribute can be advertised both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- sub-TLV of the Application Specific Link Attributes sub-TLV defined in this document, then the same numerical code should be assigned to the link attribute whenever possible. +7.4. Link Attribute Application Identifier Registry + This document requests a new IANA registry be created, under the category of "Interior Gateway Protocol (IGP) Parameters", to control the assignment of Application Identifier Bits. The suggested name of the new registry is "Link Attribute Applications". The registration policy for this registry is "Standards Action" ([RFC8126] and [RFC7120]). Bit definitions SHOULD be assigned in ascending bit order beginning with Bit 0 so as to minimize the number of octets that will need to be transmitted. The following assignments are made by this document: Bit # Name --------------------------------------------------------- 0 RSVP-TE (R-bit) 1 Segment Routing Traffic Engineering (S-bit) 2 Loop Free Alternate (F-bit) + Additional bits are undefined + +7.5. SRLG sub-TLVs This document requests a new IANA registry be created to control the assignment of sub-TLV types for the application specific SRLG TLV. The suggested name of the new registry is "Sub-TLVs for TLV 238". - The registration procedure is "Expert Review" as defined in [RFC8126]. The following assignments are made by this document: - Value Description + Value Description Encoding + Reference --------------------------------------------------------- 0-3 Unassigned - 4 Link Local/Remote Identifiers (see [RFC5307]) + 4 Link Local/Remote Identifiers [RFC5307] 5 Unassigned - 6 IPv4 interface address (see [RFC5305]) + 6 IPv4 interface address [RFC5305] 7 Unassigned - 8 IPv4 neighbor address (see [RFC5305]) + 8 IPv4 neighbor address [RFC5305] 9-11 Unassigned - 12 IPv6 Interface Address (see [RFC6119]) - 13 IPv6 Neighbor Address (see [RFC6119]) + 12 IPv6 Interface Address [RFC6119] + 13 IPv6 Neighbor Address [RFC6119] 14-255 Unassigned 8. Security Considerations - Security concerns for IS-IS are addressed in [ISO10589, [RFC5304], + Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. + This document defines a new way to advertise link attributes. + Tampering with the information defined in this document may have an + effect on applications using it, including impacting Traffic + Engineering. This is similar in nature to the impacts associated + with (for example) [RFC5305]. + 9. Acknowledgements The authors would like to thank Eric Rosen and Acee Lindem for their careful review and content suggestions. 10. References 10.1. Normative References + [ISO10589] + International Organization for Standardization, + "Intermediate system to Intermediate system intra-domain + routeing information exchange protocol for use in + conjunction with the protocol for providing the + connectionless-mode Network Service (ISO 8473)", ISO/ + IEC 10589:2002, Second Edition, Nov 2002. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic @@ -795,20 +828,24 @@ 2009, . [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . + [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints + Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, + . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, @@ -833,25 +870,20 @@ IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . - [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., - Decraene, B., Litkowski, S., and R. Shakir, "Segment - Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, - July 2018, . - Authors' Addresses Les Ginsberg Cisco Systems 821 Alder Drive Milpitas, CA 95035 USA Email: ginsberg@cisco.com