idnits 2.17.00 (12 Aug 2021) /tmp/idnits26654/draft-ietf-isis-mpls-elc-13.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 (May 28, 2020) is 716 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 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track S. Kini 5 Expires: November 29, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco Systems, Inc. 10 M. Bocci 11 Nokia 12 May 28, 2020 14 Signaling Entropy Label Capability and Entropy Readable Label Depth 15 Using IS-IS 16 draft-ietf-isis-mpls-elc-13 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 the Entropy Label Capability (ELC), on that LSP. 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 and BGP-LS. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 29, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3 69 4. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4 70 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 10.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 [RFC6790] describes a method to load-balance Multiprotocol Label 83 Switching (MPLS) traffic flows using Entropy Labels (EL). It also 84 introduces the concept of Entropy Label Capability (ELC) and defines 85 the signaling of this capability via MPLS signaling protocols. 86 Recently, mechanisms have been defined to signal labels via link- 87 state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667]. This 88 draft defines a mechanism to signal the ELC using IS-IS. 90 In cases where Segment Routing (SR) is used with the MPLS Data Plane 91 (e.g., SR-MPLS [RFC8660]), it would be useful for ingress LSRs to 92 know each intermediate LSR's capability of reading the maximum label 93 stack depth and performing EL-based load-balancing. This capability, 94 referred to as Entropy Readable Label Depth (ERLD) as defined in 95 [RFC8662], may be used by ingress LSRs to determine the position of 96 the EL label in the stack, and whether it's necessary to insert 97 multiple ELs at different positions in the label stack. This 98 document defines a mechanism to signal the ERLD using IS-IS. 100 2. Terminology 102 This memo makes use of the terms defined in [RFC6790], and [RFC8662]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 3. Advertising ELC Using IS-IS 112 Even though ELC is a property of the node, in some cases it is 113 advantageous to associate and advertise the ELC with a prefix. In a 114 multi-area network, routers may not know the identity of the prefix 115 originator in a remote area, or may not know the capabilities of such 116 originator. Similarly, in a multi-domain network, the identity of 117 the prefix originator and its capabilities may not be known to the 118 ingress LSR. 120 Bit 3 in the Prefix Attribute Flags [RFC7794] is used as the ELC Flag 121 (E-flag), as shown in Figure 1. If a router has multiple interfaces, 122 the router MUST NOT announce the ELC for any local host prefixes 123 unless all of its interfaces are capable of processing ELs. If a 124 router supports ELs on all of its interfaces, it SHOULD set the ELC 125 for every local host prefix it advertises in IS-IS. 127 0 1 2 3 4 5 6 7... 128 +-+-+-+-+-+-+-+-+... 129 |X|R|N|E| ... 130 +-+-+-+-+-+-+-+-+... 131 Figure 1: Prefix Attribute Flags 133 E-flag: ELC Flag (Bit 3) - Set for local host prefix of the 134 originating node if it supports ELC on all interfaces. 136 The ELC signaling MUST be preserved when a router propagates a prefix 137 between ISIS levels [RFC5302]. 139 When redistributing a prefix between two IS-IS protocol instances or 140 redistributing from another protocol to an IS-IS protocol instance, a 141 router SHOULD preserve the ELC signaling for that prefix if it 142 exists. The exact mechanism used to exchange ELC between protocol 143 instances running on an Autonomous System Boundary Router is outside 144 of the scope of this document. 146 4. Advertising ERLD Using IS-IS 148 A new MSD-Type [RFC8491], called ERLD-MSD, is defined to advertise 149 the ERLD [RFC8662] of a given router. A MSD-Type code 2 has been 150 assigned by IANA for ERLD-MSD. The MSD-Value field is set to the 151 ERLD in the range between 0 to 255. The scope of the advertisement 152 depends on the application. If a router has multiple interfaces with 153 different capabilities of reading the maximum label stack depth, the 154 router MUST advertise the smallest value found across all its 155 interfaces. 157 The absence of ERLD-MSD advertisements indicates only that the 158 advertising node does not support advertisement of this capability. 160 The considerations for advertising the ERLD are specified in 161 [RFC8662]. 163 If the ERLD-MSD Type is received in the Link MSD Sub-TLV, it MUST be 164 ignored. 166 5. Signaling ELC and ERLD in BGP-LS 168 The IS-IS extensions defined in this document can be advertised via 169 BGP-LS (Distribution of Link-State and TE Information Using BGP) 170 [RFC7752] using existing BGP-LS TLVs. 172 The ELC is advertised using the Prefix Attribute Flags TLV as defined 173 in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 175 The ERLD-MSD is advertised using the Node MSD TLV as defined in 176 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 178 6. IANA Considerations 180 Early allocation has been done by IANA for this document as follows: 182 - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV 183 registry has been assigned to the ELC Flag. IANA is asked to 184 update the registry to reflect the name used in this document: ELC 185 Flag (E-flag). 187 - Type 2 in the IGP MSD-Types registry has been assigned for the 188 ERLD-MSD. IANA is asked to update the registry to reflect the 189 name used in this document: ERLD-MSD. 191 7. Security Considerations 193 This document specifies the ability to advertise additional node 194 capabilities using IS-IS and BGP-LS. As such, the security 195 considerations as described in [RFC7981], [RFC7752], [RFC7794], 196 [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 197 [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this 198 document. 200 Incorrectly setting the E flag during origination, propagation or 201 redistribution may lead to poor or no load-balancing of the MPLS 202 traffic or black-holing of the MPLS traffic on the egress node. 204 Incorrectly setting of the ERLD value may lead to poor or no load- 205 balancing of the MPLS traffic. 207 8. Contributors 209 The following people contributed to the content of this document and 210 should be considered as co-authors: 212 Gunter Van de Velde (editor) 213 Nokia 214 Antwerp 215 BE 217 Email: gunter.van_de_velde@nokia.com 219 Wim Henderickx 220 Nokia 221 Belgium 223 Email: wim.henderickx@nokia.com 225 Keyur Patel 226 Arrcus 227 USA 229 Email: keyur@arrcus.com 231 9. Acknowledgements 233 The authors would like to thank Yimin Shen, George Swallow, Acee 234 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 235 Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their 236 valuable comments. 238 10. References 240 10.1. Normative References 242 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 243 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 244 and M. Chen, "BGP Link-State extensions for Segment 245 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 246 (work in progress), June 2019. 248 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 249 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 250 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 251 using Border Gateway Protocol - Link State", draft-ietf- 252 idr-bgp-ls-segment-routing-msd-18 (work in progress), May 253 2020. 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 261 Distribution with Two-Level IS-IS", RFC 5302, 262 DOI 10.17487/RFC5302, October 2008, 263 . 265 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 266 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 267 RFC 6790, DOI 10.17487/RFC6790, November 2012, 268 . 270 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 271 S. Ray, "North-Bound Distribution of Link-State and 272 Traffic Engineering (TE) Information Using BGP", RFC 7752, 273 DOI 10.17487/RFC7752, March 2016, 274 . 276 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 277 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 278 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 279 March 2016, . 281 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 282 for Advertising Router Information", RFC 7981, 283 DOI 10.17487/RFC7981, October 2016, 284 . 286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 288 May 2017, . 290 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 291 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 292 DOI 10.17487/RFC8491, November 2018, 293 . 295 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 296 Shakir, R., and J. Tantsura, "Entropy Label for Source 297 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 298 DOI 10.17487/RFC8662, December 2019, 299 . 301 10.2. Informative References 303 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 304 Decraene, B., Litkowski, S., and R. Shakir, "Segment 305 Routing with the MPLS Data Plane", RFC 8660, 306 DOI 10.17487/RFC8660, December 2019, 307 . 309 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 310 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 311 Extensions for Segment Routing", RFC 8667, 312 DOI 10.17487/RFC8667, December 2019, 313 . 315 Authors' Addresses 317 Xiaohu Xu 318 Alibaba Inc 320 Email: xiaohu.xxh@alibaba-inc.com 321 Sriganesh Kini 323 Email: sriganeshkini@gmail.com 325 Peter Psenak 326 Cisco Systems, Inc. 327 Eurovea Centre, Central 3 328 Pribinova Street 10 329 Bratislava 81109 330 Slovakia 332 Email: ppsenak@cisco.com 334 Clarence Filsfils 335 Cisco Systems, Inc. 336 Brussels 337 Belgium 339 Email: cfilsfil@cisco.com 341 Stephane Litkowski 342 Cisco Systems, Inc. 343 La Rigourdiere 344 Cesson Sevigne 345 France 347 Email: slitkows@cisco.com 349 Matthew Bocci 350 Nokia 351 Shoppenhangers Road 352 Maidenhead, Berks 353 UK 355 Email: matthew.bocci@nokia.com