idnits 2.17.00 (12 Aug 2021) /tmp/idnits12747/draft-ietf-isis-mpls-elc-10.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 (October 21, 2019) is 943 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) == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-ext has been published as RFC 9085 == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-msd has been published as RFC 8814 == Outdated reference: draft-ietf-mpls-spring-entropy-label has been published as RFC 8662 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 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: April 23, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco Systems, Inc. 10 M. Bocci 11 Nokia 12 October 21, 2019 14 Signaling Entropy Label Capability and Entropy Readable Label Depth 15 Using IS-IS 16 draft-ietf-isis-mpls-elc-10 18 Abstract 20 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 21 balance traffic flows using Entropy Labels (EL). An ingress Label 22 Switching Router (LSR) cannot insert ELs for packets going into a 23 given Label Switched Path (LSP) unless an egress LSR has indicated 24 via signaling that it has the capability to process ELs, referred to 25 as Entropy Label Capability (ELC), on that tunnel. In addition, it 26 would be useful for ingress LSRs to know each LSR's capability for 27 reading the maximum label stack depth and performing EL-based load- 28 balancing, referred to as Entropy Readable Label Depth (ERLD). This 29 document defines a mechanism to signal these two capabilities using 30 IS-IS. These mechanisms are particularly useful, where label 31 advertisements are done via protocols like IS-IS. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 23, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4 72 6. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 10.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 [RFC6790] describes a method to load-balance Multiprotocol Label 84 Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use 85 of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the 86 concept of Entropy Label Capability (ELC) and defines the signalings 87 of this capability via MPLS signaling protocols. Recently, 88 mechanisms have been defined to signal labels via link-state Interior 89 Gateway Protocols (IGP) such as IS-IS 90 [I-D.ietf-isis-segment-routing-extensions]. In such scenarios, the 91 defined signaling mechanisms are inadequate. This draft defines a 92 mechanism to signal the ELC using IS-IS. This mechanism is useful 93 when the label advertisement is also done via IS-IS. 95 In addition, in the cases where LSPs are used for whatever reasons 96 (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be 97 useful for ingress LSRs to know each intermediate LSR's capability of 98 reading the maximum label stack depth and performing EL-based load- 99 balancing. This capability, referred to as Entropy Readable Label 100 Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may 101 be used by ingress LSRs to determine the position of the EL label in 102 the stack, and whether it's necessary to insert multiple ELs at 103 different positions in the label stack. 105 2. Terminology 107 This memo makes use of the terms defined in [RFC6790], [RFC4971] and 108 [I-D.ietf-mpls-spring-entropy-label]. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Advertising ELC Using IS-IS 118 Even though ELC is a property of the node, in some cases it is 119 advantageous to associate and advertise the ELC with a prefix. In a 120 multi-area network, routers may not know the identity of the prefix 121 originator in a remote area, or may not know the capabilities of such 122 originator. Similarly in a multi-domain network, the identity of the 123 prefix originator and its capabilities may not be known to the 124 ingress LSR. 126 One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV" 127 registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by 128 the IANA for the ELC. If a router has multiple line cards, the 129 router MUST NOT announce the ELC for any prefixes that are locally 130 attached unless all of its line-cards are capable of processing ELs. 131 If a router supports ELs on all of its line-cards, it SHOULD set the 132 ELC for every local host prefix it advertises in IS-IS. 134 0 1 2 3 4 5 6 7... 135 +-+-+-+-+-+-+-+-+... 136 |X|R|N|E| ... 137 +-+-+-+-+-+-+-+-+... 138 Figure 1: Prefix Attribute Flags 140 E-flag: ELC Flag (Bit 3) 141 Set for local host prefix of the originating node 142 if it supports ELC. 144 When a router leaks a prefix between two levels (upwards or 145 downwards), it MUST preserve the ELC signaling for this prefix. 147 When redistributing a prefix between two IS-IS protocol instances or 148 redistributing from another protocol to an IS-IS protocol instance, a 149 router SHOULD preserve the ELC signaling for that prefix. The exact 150 mechanism used to exchange ELC between protocol instances running on 151 an ASBR is outside of the scope of this document and is 152 implementation specific. 154 4. Acknowledgements 156 The authors would like to thank Yimin Shen, George Swallow, Acee 157 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 158 Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their 159 valuable comments. 161 5. Advertising ERLD Using IS-IS 163 A new MSD-type of the Node MSD ((Maximum SID Depth) sub-TLV 164 [RFC8491], called ERLD is defined to advertise the ERLD of a given 165 router. As shown in Figure 2, it is formatted as described in 166 [RFC8491] with a new MSD-Type code to be assigned by IANA (the type 167 code of 2 is desired) and the Value field is set to the ERLD in the 168 range between 0 to 255. The scope of the advertisement depends on 169 the application. If a router has multiple line-cards with different 170 capabilities of reading the maximum label stack depth, the router 171 MUST advertise the smallest one. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | MSD-Type=TBD2 | ERLD | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 2: ERLD MSD-Type Format 180 When the ERLD MSD-Type is received in the Link MSD Sub-TLV, it MUST 181 be ignored. 183 6. Signaling ELC and ERLD in BGP-LS 185 The IS-IS extensions defined in this document can be advertised via 186 BGP-LS [RFC7752] using existing BGP-LS TLVs. 188 The ELC Flag included in the Prefix Attribute Flags sub-TLV, as 189 defined in Section 3, is advertised using the Prefix Attribute Flags 190 TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as 191 defined in section 2.3.2 of 192 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 194 The ERLD MSD-type introduced for IS-IS in Section 5 is advertised 195 using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as 196 defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 198 7. IANA Considerations 200 IANA is requested to allocate the E-bit (bit position 3 is desired) 201 from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. 203 IANA is requested to allocate a MSD type (the type code of 2 is 204 desired) from the "IGP MSD Types" registry for ERLD. 206 8. Security Considerations 208 The security considerations as described in [RFC4971] nd 209 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 211 Incorrectly setting the E flag (ELC capable) (during origination, 212 leaking or redistribution) may lead to black-holing of the traffic on 213 the egress node. 215 Incorrectly setting of the ERLD value may lead to poor load-balancing 216 of the traffic. 218 9. Contributors 220 The following people contributed to the content of this document and 221 should be considered as co-authors: 223 Gunter Van de Velde (editor) 224 Nokia 225 Antwerp 226 BE 228 Email: gunter.van_de_velde@nokia.com 230 Wim Henderickx 231 Nokia 232 Belgium 234 Email: wim.henderickx@nokia.com 236 Keyur Patel 237 Arrcus 238 USA 240 Email: keyur@arrcus.com 242 10. References 244 10.1. Normative References 246 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 247 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 248 and M. Chen, "BGP Link-State extensions for Segment 249 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 250 (work in progress), June 2019. 252 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 253 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 254 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 255 using Border Gateway Protocol Link-State", draft-ietf-idr- 256 bgp-ls-segment-routing-msd-09 (work in progress), October 257 2019. 259 [I-D.ietf-mpls-spring-entropy-label] 260 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 261 Shakir, R., and J. Tantsura, "Entropy label for SPRING 262 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 263 progress), July 2018. 265 [I-D.ietf-spring-segment-routing-mpls] 266 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 267 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 268 data plane", draft-ietf-spring-segment-routing-mpls-22 269 (work in progress), May 2019. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 277 "Intermediate System to Intermediate System (IS-IS) 278 Extensions for Advertising Router Information", RFC 4971, 279 DOI 10.17487/RFC4971, July 2007, 280 . 282 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 283 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 284 RFC 6790, DOI 10.17487/RFC6790, November 2012, 285 . 287 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 288 S. Ray, "North-Bound Distribution of Link-State and 289 Traffic Engineering (TE) Information Using BGP", RFC 7752, 290 DOI 10.17487/RFC7752, March 2016, 291 . 293 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 294 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 295 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 296 March 2016, . 298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 300 May 2017, . 302 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 303 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 304 DOI 10.17487/RFC8491, November 2018, 305 . 307 10.2. Informative References 309 [I-D.ietf-isis-segment-routing-extensions] 310 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 311 Gredler, H., and B. Decraene, "IS-IS Extensions for 312 Segment Routing", draft-ietf-isis-segment-routing- 313 extensions-25 (work in progress), May 2019. 315 Authors' Addresses 317 Xiaohu Xu 318 Alibaba Inc 320 Email: xiaohu.xxh@alibaba-inc.com 322 Sriganesh Kini 324 Email: sriganeshkini@gmail.com 326 Peter Psenak 327 Cisco Systems, Inc. 328 Eurovea Centre, Central 3 329 Pribinova Street 10 330 Bratislava 81109 331 Slovakia 333 Email: ppsenak@cisco.com 335 Clarence Filsfils 336 Cisco Systems, Inc. 337 Brussels 338 Belgium 340 Email: cfilsfil@cisco.com 342 Stephane Litkowski 343 Cisco Systems, Inc. 344 La Rigourdiere 345 Cesson Sevigne 346 France 348 Email: slitkows@cisco.com 349 Matthew Bocci 350 Nokia 351 Shoppenhangers Road 352 Maidenhead, Berks 353 UK 355 Email: matthew.bocci@nokia.com