idnits 2.17.1 draft-ietf-isis-mpls-elc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2018) is 2040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5305' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC7794' is defined on line 263, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-16 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track S. Kini 5 Expires: March 29, 2019 6 S. Sivabalan 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 September 25, 2018 13 Signaling Entropy Label Capability and Entropy Readable Label Depth 14 Using IS-IS 15 draft-ietf-isis-mpls-elc-06 17 Abstract 19 Multiprotocol Label Switching (MPLS) has defined a mechanism to load 20 balance traffic flows using Entropy Labels (EL). An ingress Label 21 Switching Router (LSR) cannot insert ELs for packets going into a 22 given tunnel unless an egress LSR has indicated via signaling that it 23 has the capability of processing ELs, referred to as Entropy Label 24 Capability (ELC), on that tunnel. In addition, it would be useful 25 for ingress LSRs to know each LSR's capability of reading the maximum 26 label stack depth and performing EL-based load-balancing, referred to 27 as Entropy Readable Label Depth (ERLD), in the cases where stacked 28 LSPs are used for whatever reasons. This document defines mechanisms 29 to signal these two capabilities using IS-IS. These mechanisms are 30 useful when the label advertisement is also done via IS-IS. In 31 addition, this document introduces the Non-IGP Functional 32 Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP 33 functional capabilities. ELC is one of such non-IGP functional 34 capabilities. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 29, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Non-IGP Functional Capabilities Sub-TLV . . . . . . . . . . . 3 73 4. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 4 74 5. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 80 9.2. Informative References . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 [RFC6790] describes a method to load balance Multiprotocol Label 86 Switching (MPLS) traffic flows using Entropy Labels (EL). [RFC6790] 87 introduces the concept of Entropy Label Capability (ELC) and defines 88 the signalings of this capability via MPLS signaling protocols. 89 Recently, mechanisms are being defined to signal labels via link- 90 state Interior Gateway Protocols (IGP) such as IS-IS 91 [I-D.ietf-isis-segment-routing-extensions]. In such scenario, the 92 signaling mechanisms defined in [RFC6790] are inadequate. This draft 93 defines a mechanism to signal the ELC [RFC6790] using IS-IS. This 94 mechanism is useful when the label advertisement is also done via IS- 95 IS. 97 In addition, in the cases where stacked LSPs are used for whatever 98 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 99 would be useful for ingress LSRs to know each intermediate LSR's 100 capability of reading the maximum label stack depth and performing 101 EL-based load-balancing. This capability, referred to as Entropy 102 Readable Label Depth (ERLD) as defined in 103 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 104 determine whether it's necessary to insert an EL for a given LSP of 105 the stacked LSP tunnel in the case where there has already been at 106 least one EL in the label stack [I-D.ietf-mpls-spring-entropy-label]. 108 2. Terminology 110 This memo makes use of the terms defined in [RFC6790] and [RFC4971]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Non-IGP Functional Capabilities Sub-TLV 118 This document defines the Non-IGP Functional Capabilities Sub-TLV 119 with Sub-TLV type of TBD1 within the body of the IS-IS Router 120 Capability TLV. An IS-IS router advertising an IS-IS Router 121 Capability TLV MAY include the Non-IGP Functional Capabilities Sub- 122 TLV. The Sub-TLV MUST reflect the advertising IS-IS router's actual 123 non-IGP functional capabilities in the flooding scope of the 124 containing Router Capability TLV. 126 The format of the Router Non-IGP Functional Capabilities Sub-TLV is 127 as follows: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type=TBD1 | Length=4 | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Non-IGP Functional Capabilities | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: Non-IGP Functional Capabilities Sub-TLV Format 138 Type: TBD1. 140 Length: Indicates the length of the value portion in octets and 141 will be a multiple of 4 octets dependent on the number of 142 capabilities advertised. Initially, the length will be 4, 143 denoting 4 octets of non-IGP functional capability bits. 145 Value: A variable-length sequence of capability bits rounded to a 146 multiple of 4 octets padded with undefined bits. Initially, there 147 are 4 octets of capability bits. Bits are numbered left to right 148 starting with the most significant bit being bit 0. 150 The Non-IGP Functional Capabilities Sub-TLV MAY be followed by 151 optional Sub-TLVs that further specify a non-IGP functional 152 capability. The specifications for non-IGP functional capabilities 153 advertised in this Sub-TLV MUST describe protocol behavior and 154 address backwards compatibility. 156 4. Advertising ELC Using IS-IS 158 One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired) 159 is to be assigned by the IANA for the ELC [RFC6790]. If a router has 160 multiple line cards, the router MUST NOT announce the ELC [RFC6790] 161 unless all of its linecards are capable of processing ELs. 163 How to apply the ELC advertisement to the inter-area, inter-AS and 164 inter-protocol scenarios is outside the scope of this document. 166 5. Advertising ERLD Using IS-IS 168 A new MSD-type of the Node MSD sub-TLV 169 [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to 170 advertise the ERLD of a given router. As shown in Figure 2, it is 171 formatted as described in [I-D.ietf-isis-segment-routing-msd] with a 172 new MSD-Type code to be assigned by IANA (the type code of 2 is 173 desired) and the Value field is set to the ERLD in the range between 174 0 to 255. The scope of the advertisement depends on the application. 175 If a router has multiple linecards with different capabilities of 176 reading the maximum label stack deepth, the router MUST advertise the 177 smallest one. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | MSD-Type=TBD2 | ERLD | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: ERLD MSD-Type Format 186 6. Acknowledgements 188 The authors would like to thank Yimin Shen, George Swallow, Acee 189 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 190 and Carlos Pignataro for their valuable comments. 192 7. IANA Considerations 194 This document requests IANA to allocate one sub-TLV type of the 195 Router Capability TLV registry for the Non-IGP Functional 196 Capabilities Sub-TLV. Futhermore, this document requests IANA to 197 creat a subregistry for "Non-IGP Functional Capability Bits" within 198 the "Interior Gateway Protocol (IGP) Parameters" registry. This 199 subregistry is comprised of the fields Bit Number, Capability Name, 200 and Reference. Initially, one bit is reqested to be assigned for the 201 ELC. The registration procedure is "Expert Review" as defined in 202 [RFC8126]. The following values are defined by this document: 204 Bit No. Capability Name Reference 205 ----- --------------------- ------------- 206 0 ELC This document 207 1-31 Unassigned This document 209 Figure 3: Non-IGP Functional Capability Bits Registry 211 IANA is requested to allocate a MSD type (the type code of 2 is 212 desired) from the "IGP MSD Types" registry for ERLD. 214 8. Security Considerations 216 The security considerations as described in [RFC4971] is applicable 217 to this document. This document does not introduce any new security 218 risk. 220 9. References 222 9.1. Normative References 224 [I-D.ietf-isis-segment-routing-extensions] 225 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 226 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 227 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 228 segment-routing-extensions-19 (work in progress), July 229 2018. 231 [I-D.ietf-isis-segment-routing-msd] 232 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 233 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 234 ietf-isis-segment-routing-msd-16 (work in progress), 235 September 2018. 237 [I-D.ietf-spring-segment-routing-mpls] 238 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 239 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 240 data plane", draft-ietf-spring-segment-routing-mpls-14 241 (work in progress), June 2018. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 249 "Intermediate System to Intermediate System (IS-IS) 250 Extensions for Advertising Router Information", RFC 4971, 251 DOI 10.17487/RFC4971, July 2007, 252 . 254 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 255 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 256 2008, . 258 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 259 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 260 RFC 6790, DOI 10.17487/RFC6790, November 2012, 261 . 263 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 264 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 265 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 266 March 2016, . 268 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 269 Writing an IANA Considerations Section in RFCs", BCP 26, 270 RFC 8126, DOI 10.17487/RFC8126, June 2017, 271 . 273 9.2. Informative References 275 [I-D.ietf-mpls-spring-entropy-label] 276 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 277 Shakir, R., and J. Tantsura, "Entropy label for SPRING 278 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 279 progress), July 2018. 281 Authors' Addresses 283 Xiaohu Xu 284 Alibaba Inc 286 Email: xiaohu.xxh@alibaba-inc.com 288 Sriganesh Kini 290 Email: sriganeshkini@gmail.com 292 Siva Sivabalan 293 Cisco 295 Email: msiva@cisco.com 297 Clarence Filsfils 298 Cisco 300 Email: cfilsfil@cisco.com 302 Stephane Litkowski 303 Orange 305 Email: stephane.litkowski@orange.com