idnits 2.17.1 draft-ietf-isis-mpls-elc-12.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 (April 28, 2020) is 1459 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: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-17 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 3 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: October 30, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco Systems, Inc. 10 M. Bocci 11 Nokia 12 April 28, 2020 14 Signaling Entropy Label Capability and Entropy Readable Label Depth 15 Using IS-IS 16 draft-ietf-isis-mpls-elc-12 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 tunnel. In addition, 26 it 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. 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 October 30, 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 LSPs are used (e.g., SR-MPLS [RFC8660], it would be 91 useful for ingress LSRs to know each intermediate LSR's capability of 92 reading the maximum label stack depth and performing EL-based load- 93 balancing. This capability, referred to as Entropy Readable Label 94 Depth (ERLD) as defined in [RFC8662] may be used by ingress LSRs to 95 determine the position of the EL label in the stack, and whether it's 96 necessary to insert multiple ELs at different positions in the label 97 stack. 99 2. Terminology 101 This memo makes use of the terms defined in [RFC6790], and [RFC8662]. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Advertising ELC Using IS-IS 111 Even though ELC is a property of the node, in some cases it is 112 advantageous to associate and advertise the ELC with a prefix. In a 113 multi-area network, routers may not know the identity of the prefix 114 originator in a remote area, or may not know the capabilities of such 115 originator. Similarly in a multi-domain network, the identity of the 116 prefix originator and its capabilities may not be known to the 117 ingress LSR. 119 Bit 3 in the Prefix Attribute Flags [RFC7794] is used as the ELC Flag 120 (E-flag), as shown in Figure 1. If a router has multiple interfaces, 121 the router MUST NOT announce the ELC for any local host prefixes 122 unless all of its interfaces are capable of processing ELs. If a 123 router supports ELs on all of its interfaces, it SHOULD set the ELC 124 for every local host prefix it advertises in IS-IS. 126 0 1 2 3 4 5 6 7... 127 +-+-+-+-+-+-+-+-+... 128 |X|R|N|E| ... 129 +-+-+-+-+-+-+-+-+... 130 Figure 1: Prefix Attribute Flags 132 E-flag: ELC Flag (Bit 3) - Set for local host prefix of the 133 originating node if it supports ELC on all interfaces. 135 When a router propagates a prefix between ISIS levels ([RFC5302], it 136 MUST preserve the ELC signaling for this prefix. 138 When redistributing a prefix between two IS-IS protocol instances or 139 redistributing from another protocol to an IS-IS protocol instance, a 140 router SHOULD preserve the ELC signaling for that prefix. The exact 141 mechanism used to exchange ELC between protocol instances running on 142 an Autonomous System Boundary Router (ASBR) is outside of the scope 143 of this document. 145 4. Advertising ERLD Using IS-IS 147 A new MSD-type [RFC8491], called ERLD-MSD is defined to advertise the 148 ERLD [RFC8662] of a given router. A MSD-Type code 2 has been 149 assigned by IANA for ERLD-MSD. The MSD-Value field is set to the 150 ERLD in the range between 0 to 255. The scope of the advertisement 151 depends on the application. If a router has multiple interfaces with 152 different capabilities of reading the maximum label stack depth, the 153 router MUST advertise the smallest one. 155 The absence of ERLD-MSD advertisements indicates only that the 156 advertising node does not support advertisement of this capability. 158 The considerations for advertising the ERLD are specified in 159 [RFC8662]. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | MSD-Type=TBD2 | ERLD | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 2: ERLD MSD-Type Format 168 If the ERLD-MSD Type is received in the Link MSD Sub-TLV, it MUST be 169 ignored. 171 5. Signaling ELC and ERLD in BGP-LS 173 The IS-IS extensions defined in this document can be advertised via 174 BGP-LS [RFC7752] using existing BGP-LS TLVs. 176 The ELC is advertised using the Prefix Attribute Flags TLV as defined 177 in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 179 The ERLD-MSD is advertised using the Node MSD TLV as defined in 180 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 182 6. IANA Considerations 184 Early allocation has been done by IANA for this document as follows: 186 - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV 187 registry has been assigned to the ELC Flag. IANA is asked to 188 update the registry to reflect the name used in this document: ELC 189 Flag (E-flag). 191 - Type 2 in the IGP MSD-Types registry has been assigned for the 192 ERLD-MSD. IANA is asked to update the registry to reflect the 193 name used in this document: ERLD-MSD. 195 7. Security Considerations 197 This document specifies the ability to advertise additional node 198 capabilities using IS-IS and BGP-LS. As such, the security 199 considerations as described in [RFC7981], [RFC7752], [RFC7794], 200 [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 201 [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this 202 document. 204 Incorrectly setting the E flag during origination, propagation or 205 redistribution may lead to black-holing of the traffic on the egress 206 node. 208 Incorrectly setting of the ERLD value may lead to poor or no load- 209 balancing of the traffic. 211 8. Contributors 213 The following people contributed to the content of this document and 214 should be considered as co-authors: 216 Gunter Van de Velde (editor) 217 Nokia 218 Antwerp 219 BE 221 Email: gunter.van_de_velde@nokia.com 223 Wim Henderickx 224 Nokia 225 Belgium 227 Email: wim.henderickx@nokia.com 229 Keyur Patel 230 Arrcus 231 USA 233 Email: keyur@arrcus.com 235 9. Acknowledgements 237 The authors would like to thank Yimin Shen, George Swallow, Acee 238 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 239 Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their 240 valuable comments. 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- 256 idr-bgp-ls-segment-routing-msd-17 (work in progress), 257 April 2020. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 265 Distribution with Two-Level IS-IS", RFC 5302, 266 DOI 10.17487/RFC5302, October 2008, 267 . 269 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 270 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 271 RFC 6790, DOI 10.17487/RFC6790, November 2012, 272 . 274 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 275 S. Ray, "North-Bound Distribution of Link-State and 276 Traffic Engineering (TE) Information Using BGP", RFC 7752, 277 DOI 10.17487/RFC7752, March 2016, 278 . 280 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 281 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 282 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 283 March 2016, . 285 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 286 for Advertising Router Information", RFC 7981, 287 DOI 10.17487/RFC7981, October 2016, 288 . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 295 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 296 DOI 10.17487/RFC8491, November 2018, 297 . 299 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 300 Shakir, R., and J. Tantsura, "Entropy Label for Source 301 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 302 DOI 10.17487/RFC8662, December 2019, 303 . 305 10.2. Informative References 307 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 308 Decraene, B., Litkowski, S., and R. Shakir, "Segment 309 Routing with the MPLS Data Plane", RFC 8660, 310 DOI 10.17487/RFC8660, December 2019, 311 . 313 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 314 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 315 Extensions for Segment Routing", RFC 8667, 316 DOI 10.17487/RFC8667, December 2019, 317 . 319 Authors' Addresses 321 Xiaohu Xu 322 Alibaba Inc 324 Email: xiaohu.xxh@alibaba-inc.com 325 Sriganesh Kini 327 Email: sriganeshkini@gmail.com 329 Peter Psenak 330 Cisco Systems, Inc. 331 Eurovea Centre, Central 3 332 Pribinova Street 10 333 Bratislava 81109 334 Slovakia 336 Email: ppsenak@cisco.com 338 Clarence Filsfils 339 Cisco Systems, Inc. 340 Brussels 341 Belgium 343 Email: cfilsfil@cisco.com 345 Stephane Litkowski 346 Cisco Systems, Inc. 347 La Rigourdiere 348 Cesson Sevigne 349 France 351 Email: slitkows@cisco.com 353 Matthew Bocci 354 Nokia 355 Shoppenhangers Road 356 Maidenhead, Berks 357 UK 359 Email: matthew.bocci@nokia.com