--- 1/draft-ietf-isis-te-app-05.txt 2019-04-08 06:13:12.554578423 -0700 +++ 2/draft-ietf-isis-te-app-06.txt 2019-04-08 06:13:12.590579366 -0700 @@ -1,24 +1,24 @@ Networking Working Group L. Ginsberg Internet-Draft P. Psenak Intended status: Standards Track Cisco Systems -Expires: April 20, 2019 S. Previdi +Expires: October 10, 2019 S. Previdi Huawei W. Henderickx Nokia J. Drake Juniper Networks - October 17, 2018 + April 8, 2019 IS-IS TE Attributes per application - draft-ietf-isis-te-app-05.txt + draft-ietf-isis-te-app-06.txt Abstract Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. @@ -44,25 +44,25 @@ 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 April 20, 2019. + This Internet-Draft will expire on October 10, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -96,21 +96,21 @@ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 [RFC7810]. Use of these extensions has + [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 Resource Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. 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) and Loop Free Alternates (LFA). 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 @@ -142,28 +142,27 @@ are: 1. Support for indicating which applications are using the link attribute advertisements on a link 2. Support for advertising application specific values for the same attribute on a link [RFC7855] discusses use cases/requirements for SR. Included among these use cases is SRTE which is defined in - [I-D.filsfils-spring-segment-routing-policy]. If both RSVP-TE and - SRTE are deployed in a network, link attribute advertisements can be - used by one or both of these applications. As there is no - requirement for the link 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, there is a clear requirement to indicate - independently which link attribute advertisements are to be used by - each application. + [I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SRTE + are deployed in a network, link attribute advertisements can be used + by one or both of these applications. As there is no requirement for + the link 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, there is a clear requirement to indicate independently which + link attribute advertisements are to be used by each application. As the number of applications which may wish to utilize link attributes may grow in the future, an additional requirement is that the extensions defined allow the association of additional applications to link attributes without altering the format of the advertisements or introducing new backwards compatibility issues. Finally, there may still be many cases where a single attribute value can be shared among multiple applications, so the solution must minimize advertising duplicate link/attribute pairs whenever @@ -320,28 +319,28 @@ 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 UDAs. 4.2. Application Specific Link Attributes sub-TLV A new sub-TLV for TLVs 22, 23, 141, 222, and 223 is defined which supports specification of the applications and application specific attribute values. - Type: 16 (suggested value - to be assigned by IANA) + Type: 16 (temporarily assigned by IANA) Length: Variable (1 octet) Value: Application Bit Mask (as defined in Section 3.1) Link Attribute sub-sub-TLVs - format matches the - existing formats defined in [RFC5305] and [RFC7810] + existing formats defined in [RFC5305] and [RFC8570] When the L-flag is set in the Application Identifiers, all of the applications specified in the bit mask MUST use the link attribute sub-TLV advertisements listed in Section 3.1 for the corresponding link. Application specific link attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard/User Application Bit Masks and all such advertisements MUST be ignored on receipt. Multiple sub-TLVs for the same link MAY be advertised. When multiple @@ -392,21 +391,21 @@ 4.3. Application Specific SRLG TLV A new TLV is defined to advertise application specific SRLGs for a given link. Although similar in functionality to TLV 138 (defined by [RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides support for IPv4, IPv6, and unnumbered identifiers for a link. Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link identifiers in order to provide the flexible formatting required to support multiple link identifier types. - Type: 238 (Suggested value - to be assigned by IANA) + Type: 238 (Temporarily assigned by IANA) Length: Number of octets in the value field (1 octet) Value: Neighbor System-ID + pseudo-node ID (7 octets) Application Bit Mask (as defined in Section 3.1) Length of sub-TLVs (1 octet) Link Identifier sub-TLVs (variable) 0 or more SRLG Values (Each value is 4 octets) The following Link Identifier sub-TLVs are defined. The type values are suggested and will be assigned by IANA - but as @@ -471,21 +470,21 @@ 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 Flex-Algo, advertisement of application specific link attributes does NOT indicate enablement of Flex-Algo. 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.hegdeppsenak-isis-sr-flex-algo]. + [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 4.1). This supports the use of the link @@ -677,49 +676,46 @@ 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, . - [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and - Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", - RFC 7810, DOI 10.17487/RFC7810, May 2016, - . - [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, + D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) + Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March + 2019, . + 11.2. Informative References - [I-D.filsfils-spring-segment-routing-policy] - Filsfils, C., Sivabalan, S., Hegde, S., - daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, - b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., - Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, - J., Clad, F., and K. Raza, "Segment Routing Policy - Architecture", draft-filsfils-spring-segment-routing- - policy-06 (work in progress), May 2018. + [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-01 (work in progress), November 2018. - [I-D.hegdeppsenak-isis-sr-flex-algo] - Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS - Segment Routing Flexible Algorithm", draft-hegdeppsenak- - isis-sr-flex-algo-02 (work in progress), February 2018. + [I-D.ietf-spring-segment-routing-policy] + Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., + bogdanov@google.com, b., and P. Mattes, "Segment Routing + Policy Architecture", draft-ietf-spring-segment-routing- + policy-02 (work in progress), October 2018. [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, . Authors' Addresses Les Ginsberg