ISIS Working Group C. Bowers Internet-Draft S. Hegde Intended status: Standards Track Juniper Networks Expires: January 4, 2018 July 3, 2017 Extensions to IS-IS to Associate TE Attributes with TE Attribute Sets and SRLGs with SRLG Sets draft-bowers-isis-te-attribute-set-00 Abstract This document specifies encodings that allow traffic engineering attributes to be associated with different TE attribute set identifiers and SRLGs to be associated with SRLG set identifiers. 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 http://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 January 4, 2018. Copyright Notice Copyright (c) 2017 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 (http://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 described in the Simplified BSD License. Bowers & Hegde Expires January 4, 2018 [Page 1]
Internet-Draft ISIS TE Attribute Sets July 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Basic assumptions . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Minimize disruption . . . . . . . . . . . . . . . . . . . 2 2.2. Maximize flexibilty . . . . . . . . . . . . . . . . . . . 3 3. TE Link Attributes that would benefit from this new functionality . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Link Attribute Set sub-TLV . . . . . . . . . . . . . . . . . 4 5. TE Attribute Set usage . . . . . . . . . . . . . . . . . . . 5 6. SRLG Set Scoped SRLG TLV . . . . . . . . . . . . . . . . . . 6 7. SRLG Set usage . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Management Considerations . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction IS-IS encodings allow traffic engineering (TE) attributes, such as bandwidth-related parameters and administrative groups, as well as shared risk link groups (SRLGs) to be associated with different links in the network topology. Different applications use these attributes to decide how traffic should be directed across the network. It can be useful for different applications to use different sets of TE attributes and SRLGs to decide how traffic is directed across the network. Existing IS-IS encodings only allow for one set of TE attributes and SRLGs to be associated with a given link. This document specifies encodings that allow different sets of TE attributes and SRLGs to be associated with a given link. 2. Basic assumptions There are several different approaches that one could take to enable this functionality. The approach taken by this document is based on the following assumptions about the use of this encoding. 2.1. Minimize disruption The requirements of many current and future deployments of SR and RSVP can be satisfied using the existing encodings that support a single set of TE attributes and SRLGs. The encodings described here allow the advertisement of multiple sets of TE attributes and SRLGs. Bowers & Hegde Expires January 4, 2018 [Page 2]
Internet-Draft ISIS TE Attribute Sets July 2017 They do so in a way that minimizes the disruption and burden, in terms of interoperability testing, software upgrades, and overall complexity, on deployments that do not need this more complex fucntionality. 2.2. Maximize flexibilty Future applications are difficult to predict, especially as network operators deploy their own customized, centralized controllers. The encodings described here does not try to associate TE attributes and SRLGs with particular applications. Instead, they allow TE attributes and SRLGs to be organized into sets, using groupings that make most sense for the network operator's particular use case. The network advertises these TE attributes and SRLGs with their associated TE attribute and SRLG set identifiers, and different applications use this information as they see fit. The authors believe that this approach provides the greatest flexibility for those networks that are likely to require these more complex capabilities. 3. TE Link Attributes that would benefit from this new functionality There are currently 36 sub-TLVs defined for TLV#22 (as well as TLVs #23, #141, #222, and #223.) We draw a distinction between two types of sub-TLVs in TLV#22. Some sub-TLVs (such as the IPv4 interface address and neighbor address sub-TLVs) are used to identify a link. In this document, we refer to these as TE link identifier sub-TLVs. Below is a complete list of the sub-TLVs in TLV#22 that we classify as TE link identifier sub-TLVs. Type Description ------- ----------------------------- 4 Link Local/Remote Identifiers 6 IPv4 interface address 8 IPv4 neighbor address 12 IPv6 Interface Address 13 IPv6 Neighbor Address sub-TLVs of TLV#22 classified as TE link identifier sub-TLVs Since TE link identifier sub-TLVs are used to identify links, it does not make sense to allow these sub-TLVs to be advertised more than once with different values for a given link. In principle, the remaining 31 sub-TLVs currently defined for TLV#22 are candidates for enabling the advertisment of different values scoped by a TE attribute set identifier. However, for this document Bowers & Hegde Expires January 4, 2018 [Page 3]
Internet-Draft ISIS TE Attribute Sets July 2017 we only specify this new functionality for the following subset of TE link attributes. Type Description ------- ----------------------------- 3 Administrative group (color) 9 Maximum link bandwidth 10 Maximum reservable link bandwidth 11 Unreserved bandwidth 14 Extended Administrative Group 18 TE Default metric 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 Figure 1: TE link attributes sub-TLVs given the ability to be advertised with different values scoped by TE attribute set identifier The new TE Attribute Set Identifier is a 32-bit value that identifies a set of attributes. The TE Attribute Set Identifier with a value of zero is special. Existing encodings for advertising attributes that do not explicitly support the inclusion of the TE Attribute Set Identifier are now understood to implicitly advertise attributes with the TE Attribute Set Identifier set to zero. In this framework, existing implementations using the existing encodings already support the advertisement of attributes with the TE attibute set id = 0. In order to ensure a consistent view of the attribute set scoped attributes, for encodings that explicitly support the TE Attribute Set Identifier, advertising an attribute with TE Attribute Set Identifier set to zero is not allowed. 4. Link Attribute Set sub-TLV The Link Attribute Set sub-TLV is a new sub-TLV for TLVs 22, 23, 141, 222, and 223. It allows multiple values of a given TE link attribute to be advertised for the same link, scoped by the TE Attribute Set ID. Type: To be assigned by IANA (suggested value 101) Length: Number of octets in the value field (1 octet) Bowers & Hegde Expires January 4, 2018 [Page 4]
Internet-Draft ISIS TE Attribute Sets July 2017 Value: TE Attribute Set Identifier: A 32-bit value containing the non- zero TE Attribute Set Identifier that identifies a set of attributes. The Link Attribute Set sub-TLV MUST be ignored if the TE Attribute Set Identifier is zero. This ensures a consistent view of the attribute set scoped link attributes, where the Link Attribute sub-TLVs advertised directly in TLV#22 are now understood to be implicitly advertised with the TE Attribute Set Identifier equal to zero. Link Attribute sub-sub-TLVs: The format of these Link Attribute sub-sub-TLVs matches the existing formats for the Link Attribute sub-TLVs defined in [RFC5305] and [RFC7810]. Each Link Attribute sub-sub-TLV advertised in a given Link Attribute Set sub-TLV is associated with the TE Attribute Set Identifier in the Link Attribute Set sub-TLV. Figure 1 shows the subset of existing Link Attributes sub-TLVs that we are specifying in this document. 5. TE Attribute Set usage The TE attribute set uses a simple substitution semantics. We consider the TE attribute set with identifier=0 to be the default TE attribute set. An application receiving attributes in the default TE attribute set will use those default TE attributes, unless it receives attributes in the one non-default TE attribute set that it has been configured or programmed to consider. In many network scenarios, all of the applications will only need to use a single common set of TE attributes advertised with their existing encodings. In this framework, these applications will all be using TE attribute set = 0, the default TE attribute set. Application Atribute set id ----------- --------------- A 0 (implicit) B 0 (implicit) C 0 (implicit) Scenario where all applications use a single common set of TE attributes In some scenarios, a network operator will need to advertise different values of a given attribute for a given link. Consider a scenario where applications D, E, and F need common values for all TE link attributes, except for sub-TLV#9 (Maximum link bandwidth). Applications D and E use a common value for sub-TLV#9, while Bowers & Hegde Expires January 4, 2018 [Page 5]
Internet-Draft ISIS TE Attribute Sets July 2017 application F needs a different value for sub-TLV#9. This scenario is supported by having each link advertise all sub-TLVs in TLV#22 as they are advertised today. These advertisements are understood to be advertised with the TE attribute set id = 0. Applications D and E only need to use these advertisements. Links also advertise sub-sub- TLV#9 in the TE Atribute Set sub-TLV with TE attribute set id = 1. Application F is configured to use attribute set id = 1. This means that application F first looks for the value of each attribute scoped for TE attribute set = 1. If it is present, application F uses that attribute set scoped value. If it is not present, application F uses the value in the default TE attribute set (id=0). Application Atribute set id ----------- --------------- D 0 (implicit) E 0 (implicit) F 1 Scenario where applications need different values for some attributes From a standardization perspective, there is not intended to be any fixed mapping between a given TE Attribute Set Identifier and a given application. A network operator wishing to advertise different attribute sets could configure the network equipment to advertise attributes with different values of the TE Attribute Set Identifier based on their objectives. The different applications (be they controller-based applications or distributed applications) would make use of the different attribute sets based on convention within that network. 6. SRLG Set Scoped SRLG TLV A new TLV is defined to allow SRLGs to be advertised for a given link and associated with a specific SRLG set identifier. 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: To be assigned by IANA (suggested value 238) Length: Number of octets in the value field (1 octet) Value: Neighbor System-ID + pseudo-node ID (7 octets) Bowers & Hegde Expires January 4, 2018 [Page 6]
Internet-Draft ISIS TE Attribute Sets July 2017 SRLG Set Identifier: A 32-bit value containing the non-zero SRLG Set Identifier that identifies a set of SRLGs. The SRLG Set Scoped SRLG TLV MUST be ignored if the SRLG Set Identifier is zero. This ensures a consistent view of the SRLG set scoped link attributes, where the SRLGs advertised directly in TLV#138 and TLV#139 are now understood to be implicitly advertised with the TE Attribute Set Identifier equal to zero. Length of sub-TLVs in octets (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 only suggested values. The actual values will be assigned by IANA. However, as the formats are identical to existing sub-TLVs defined for TLVs 22, 23, 141, 222, and 223 the assignment of the suggested sub-TLV types is strongly encouraged. Type Description ------- ----------------------------- 4 Link Local/Remote Identifiers 6 IPv4 interface address 8 IPv4 neighbor address 12 IPv6 Interface Address 13 IPv6 Neighbor Address At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST be present. TLVs which do not meet this requirement MUST be ignored. Multiple TLVs for the same link MAY be advertised. 7. SRLG Set usage The new SRLG Set Identifier is a 32-bit value that identifies a set of SRLGs. The SRLG Set Identifier with a value of zero is special. Existing encodings for advertising SRLGs that do not explicitly support the inclusion of the SRLG Set Identifier are now understood to implicitly advertise SRLGs with the SRLG Set Identifier set to zero. In this framework, existing implementations using the existing encodings already support the advertisement of SRLGs with the SRLG set id = 0. In order to ensure a consistent view of the SRLG set scoped SRLGs, for encodings that explicitly support the SRLG Set Identifier, advertising an attribute with SRLG Set Identifier set to zero is not allowed. Bowers & Hegde Expires January 4, 2018 [Page 7]
Internet-Draft ISIS TE Attribute Sets July 2017 The SRLG set uses additive semantics. An application receiving SRLGs scoped with different SRLG set identifiers will take the union of the SRLGs in each SRLG set that the application is programmed to take into consideration. Given the additive semantics of SRLG sets, we do not use the SRLGs with SRLG set identifier = 0 as a default value in the absence of other SRLGs with non-zero SRLG set identifier. The following example illustrates the expected use of the advertising SRLGs scoped with SRLG set identifiers. SRLGs in networks often follow a natural grouping into sets. As a concrete example, assume that one set of SRLGs corresponds to links within a metro area (intra-city SRLGs). A second set of SRLGs corresponds to links between metro area (inter-city SRLGs). A third set of SRLGs corresponds to links between continents on undersea cables (inter- continental SRLGs). A reasonable mapping of these natural SRLG groupings to SRLG set identifier is shown below in Figure 2. The network would be configured to advertise SRLGs scoped with these SRLG set identifiers. Natural SRLG groupings SRLG set id ----------------------- ----------- intra-city SRLGs 1 inter-city SRLGs 2 inter-continental SRLGs 3 Figure 2: Example mapping of natural SRLG groupings to SRLG set identifier Assume that the network operator starts out with two applications. Application G should take into account all three groups of SRLGs as path constraints: intra-city, inter-city, and inter-continental SRLGs. Instead, application H should only take into account inter- city and inter-continental SRLGs. This can be accomplished by having application G use union of SRLG sets 1, 2, and 3, while application H uses the union of SRLG sets 2 and 3, as shown in Figure 3. Application SRLG set ids ----------------------- ------------ G 1+2+3 H 2+3 Figure 3: Example usage of SRLG sets by applications This accomplishes the goals of the network operator in a very natural way. Now suppose that the network operator introduces a third application, application J, that should only take into account intra-city and Bowers & Hegde Expires January 4, 2018 [Page 8]
Internet-Draft ISIS TE Attribute Sets July 2017 inter-city SRLGs. This can be accomplished without modifying any of the SRLG advertisements. The new application J need only be programmed or configured to take use the union of SRLG sets 1 and 2, as as shown in Figure 4. Application SRLG set ids ----------------------- ------------ G 1+2+3 H 2+3 J 1+2 Figure 4: The simplicity of adding a new application If application J is a centralized controller-based application, the new application can be introduced with even touching the network itself. 8. IANA Considerations IANA is requested to create a new sub-TLV, the Link Attribute Set sub-TLV for TLVs 22, 23, 141, 222, and 223. Type Description 22 23 141 222 223 Ref. ------- --------------------------- -- -- --- --- --- ------- TBA1 Link Attribute Set sub-TLV y y y y y [This draft] IANA is requested to create a new TLV, the SRLG Set Scoped SRLG TLV. Type Description IIH SNP LSP Purge Ref. ------- ----------------------- --- --- --- ----- ------ TBA2 TE Attribute Set Scoped n n y n [This SRLG TLV draft] 9. Management Considerations TBD 10. Security Considerations TBD 11. Acknowledgements The basic format for the encoding of the Link Attribute Set sub-TLV and the TE Attribute Set Scoped SRLG TLV follows the basic format of the encodings in [I-D.ginsberg-isis-te-app]. Bowers & Hegde Expires January 4, 2018 [Page 9]
Internet-Draft ISIS TE Attribute Sets July 2017 12. References 12.1. Normative References [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>. [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>. [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, <http://www.rfc-editor.org/info/rfc7810>. 12.2. Informative References [I-D.ginsberg-isis-te-app] Ginsberg, L., Psenak, P., Previdi, S., and W. Henderickx, "IS-IS TE Attributes per application", draft-ginsberg- isis-te-app-00 (work in progress), February 2017. Authors' Addresses Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: cbowers@juniper.net Shraddha Hegde Juniper Networks Embassy Business Park Bangalore, KA 560093 India Email: shraddha@juniper.net Bowers & Hegde Expires January 4, 2018 [Page 10]