--- 1/draft-ietf-isis-te-app-16.txt 2020-06-17 11:13:10.152152195 -0700 +++ 2/draft-ietf-isis-te-app-17.txt 2020-06-17 11:13:10.196153318 -0700 @@ -1,24 +1,24 @@ Networking Working Group L. Ginsberg Internet-Draft P. Psenak Intended status: Standards Track Cisco Systems -Expires: December 17, 2020 S. Previdi +Expires: December 19, 2020 S. Previdi Huawei W. Henderickx Nokia J. Drake Juniper Networks - June 15, 2020 + June 17, 2020 IS-IS TE Attributes per application - draft-ietf-isis-te-app-16 + draft-ietf-isis-te-app-17 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 Policy, Loop Free Alternate) that also make use of the link attribute advertisements have been defined . In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application specific values for @@ -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 December 17, 2020. + This Internet-Draft will expire on December 19, 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 @@ -73,47 +73,47 @@ 2. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4 3. Legacy Advertisements . . . . . . . . . . . . . . . . . . . . 5 3.1. Legacy sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5 3.2. Legacy SRLG Advertisements . . . . . . . . . . . . . . . 6 4. Advertising Application Specific Link Attributes . . . . . . 6 4.1. Application Identifier Bit Mask . . . . . . . . . . . . . 6 4.2. Application Specific Link Attributes sub-TLV . . . . . . 9 4.2.1. Special Considerations for Maximum Link Bandwidth . . 10 4.2.2. Special Considerations for Reservable/Unreserved Bandwidth . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.3. Considerations for Extended TE Metrics . . . . . . . 10 + 4.2.3. Considerations for Extended TE Metrics . . . . . . . 11 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 11 5. Attribute Advertisements and Enablement . . . . . . . . . . . 12 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 13 6.2. Use of Zero Length Application Identifier Bit Masks . . . 14 6.3. Interoperability, Backwards Compatibility and Migration Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Multiple Applications: Common Attributes with RSVP- - TE . . . . . . . . . . . . . . . . . . . . . . . . . 14 + TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3.2. Multiple Applications: All Attributes Not Shared with - RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 14 + RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 15 6.3.3. Interoperability with Legacy Routers . . . . . . . . 15 6.3.4. Use of Application Specific Advertisements for RSVP- - TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 + TE . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 7.1. Application Specific Link Attributes sub-TLV . . . . . . 16 - 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 . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.1. Application Specific Link Attributes sub-TLV . . . . . . 17 + 7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 17 + 7.3. Application Specific Link Attributes sub-sub-TLV Registry 17 + 7.4. Link Attribute Application Identifier Registry . . . . . 18 + 7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 19 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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], [RFC7308], 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 @@ -249,20 +249,26 @@ 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 (defined in Section 4.2 ). 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in Section 4.3). In support of these new advertisements, an application identifier bit mask is defined that identifies the application(s) associated with a given advertisement (defined in Section 4.1). + In addition to supporting the advertisement of link attributes used + by standardized applications, link attributes can also be advertised + for use by user defined applications. Such applications are not + subject to standardization and are outside the scope of this + document. + The following sections define the format of these new advertisements. 4.1. Application Identifier Bit Mask Identification of the set of applications associated with link attribute advertisements utilizes two bit masks. One bit mask is for standard applications where the definition of each bit is defined in a new IANA controlled registry. A second bit mask is for non- standard User Defined Applications (UDAs).