idnits 2.17.1 draft-ietf-isis-mpls-elc-09.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 4, 2019) is 1666 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-08 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 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: April 6, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco 10 October 4, 2019 12 Signaling Entropy Label Capability and Entropy Readable Label Depth 13 Using IS-IS 14 draft-ietf-isis-mpls-elc-09 16 Abstract 18 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 19 balance traffic flows using Entropy Labels (EL). An ingress Label 20 Switching Router (LSR) cannot insert ELs for packets going into a 21 given Label Switched Path (LSP) unless an egress LSR has indicated 22 via signaling that it has the capability to process ELs, referred to 23 as Entropy Label Capability (ELC), on that tunnel. In addition, it 24 would be useful for ingress LSRs to know each LSR's capability for 25 reading the maximum label stack depth and performing EL-based load- 26 balancing, referred to as Entropy Readable Label Depth (ERLD). This 27 document defines a mechanism to signal these two capabilities using 28 IS-IS. These mechanisms are particularly useful, where label 29 advertisements are done via protocols like IS-IS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 6, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4 70 6. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 9.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 [RFC6790] describes a method to load-balance Multiprotocol Label 81 Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use 82 of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the 83 concept of Entropy Label Capability (ELC) and defines the signalings 84 of this capability via MPLS signaling protocols. Recently, 85 mechanisms have been defined to signal labels via link-state Interior 86 Gateway Protocols (IGP) such as IS-IS 87 [I-D.ietf-isis-segment-routing-extensions]. In such scenarios, the 88 defined signaling mechanisms are inadequate. This draft defines a 89 mechanism to signal the ELC using IS-IS. This mechanism is useful 90 when the label advertisement is also done via IS-IS. 92 In addition, in the cases where LSPs are used for whatever reasons 93 (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be 94 useful for ingress LSRs to know each intermediate LSR's capability of 95 reading the maximum label stack depth and performing EL-based load- 96 balancing. This capability, referred to as Entropy Readable Label 97 Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may 98 be used by ingress LSRs to determine the position of the EL label in 99 the stack, and whether it's necessary to insert multiple ELs at 100 different positions in the label stack. 102 2. Terminology 104 This memo makes use of the terms defined in [RFC6790], [RFC4971] and 105 [I-D.ietf-mpls-spring-entropy-label]. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. Advertising ELC Using IS-IS 115 Even though ELC is a property of the node, in some cases it is 116 advantageous to associate and advertise the ELC with a prefix. In a 117 multi-area network, routers may not know the identity of the prefix 118 originator in a remote area, or may not know the capabilities of such 119 originator. Similarly in a multi-domain network, the identity of the 120 prefix originator and its capabilities may not be known to the 121 ingress LSR. 123 One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV" 124 registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by 125 the IANA for the ELC. If a router has multiple line cards, the 126 router MUST NOT announce the ELC for any prefixes that are locally 127 attached unless all of its line-cards are capable of processing ELs. 128 If a router supports ELs on all of its line-cards, it SHOULD set the 129 ELC for every local host prefix it advertises in IS-IS. 131 0 1 2 3 4 5 6 7... 132 +-+-+-+-+-+-+-+-+... 133 |X|R|N|E| ... 134 +-+-+-+-+-+-+-+-+... 135 Figure 1: Prefix Attribute Flags 137 E-flag: ELC Flag (Bit 3) 138 Set for local host prefix of the originating node 139 if it supports ELC. 141 When a router leaks a prefix between two levels (upwards or 142 downwards), it MUST preserve the ELC signaling for this prefix. 144 When redistributing a prefix between two IS-IS protocol instances or 145 redistributing from another protocol to an IS-IS protocol instance, a 146 router SHOULD preserve the ELC signaling for that prefix. The exact 147 mechanism used to exchange ELC between protocol instances running on 148 an ASBR is outside of the scope of this document and is 149 implementation specific. 151 4. Acknowledgements 153 The authors would like to thank Yimin Shen, George Swallow, Acee 154 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 155 Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their 156 valuable comments. 158 5. Advertising ERLD Using IS-IS 160 A new MSD-type of the Node MSD ((Maximum SID Depth) sub-TLV 161 [RFC8491], called ERLD is defined to advertise the ERLD of a given 162 router. As shown in Figure 2, it is formatted as described in 163 [RFC8491] with a new MSD-Type code to be assigned by IANA (the type 164 code of 2 is desired) and the Value field is set to the ERLD in the 165 range between 0 to 255. The scope of the advertisement depends on 166 the application. If a router has multiple line-cards with different 167 capabilities of reading the maximum label stack depth, the router 168 MUST advertise the smallest one. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | MSD-Type=TBD2 | ERLD | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2: ERLD MSD-Type Format 177 When the ERLD MSD-Type is received in the Link MSD Sub-TLV, it MUST 178 be ignored. 180 6. Signaling ELC and ERLD in BGP-LS 182 The IS-IS extensions defined in this document can be advertised via 183 BGP-LS [RFC7752] using existing BGP-LS TLVs. 185 The ELC Flag included in the Prefix Attribute Flags sub-TLV, as 186 defined in Section 3, is advertised using the Prefix Attribute Flags 187 TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as 188 defined in section 2.3.2 of 189 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 191 The ERLD MSD-type introduced for IS-IS in Section 5 is advertised 192 using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as 193 defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 195 7. IANA Considerations 197 IANA is requested to allocate the E-bit (bit position 3 is desired) 198 from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. 200 IANA is requested to allocate a MSD type (the type code of 2 is 201 desired) from the "IGP MSD Types" registry for ERLD. 203 8. Security Considerations 205 The security considerations as described in [RFC4971] nd 206 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 208 Incorrectly setting the E flag (ELC capable) (during origination, 209 leaking or redistribution) may lead to black-holing of the traffic on 210 the egress node. 212 Incorrectly setting of the ERLD value may lead to poor load-balancing 213 of the traffic. 215 9. References 217 9.1. Normative References 219 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 220 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 221 and M. Chen, "BGP Link-State extensions for Segment 222 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 223 (work in progress), June 2019. 225 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 226 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 227 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 228 using Border Gateway Protocol Link-State", draft-ietf-idr- 229 bgp-ls-segment-routing-msd-08 (work in progress), 230 September 2019. 232 [I-D.ietf-mpls-spring-entropy-label] 233 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 234 Shakir, R., and J. Tantsura, "Entropy label for SPRING 235 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 236 progress), July 2018. 238 [I-D.ietf-spring-segment-routing-mpls] 239 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 240 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 241 data plane", draft-ietf-spring-segment-routing-mpls-22 242 (work in progress), May 2019. 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 250 "Intermediate System to Intermediate System (IS-IS) 251 Extensions for Advertising Router Information", RFC 4971, 252 DOI 10.17487/RFC4971, July 2007, 253 . 255 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 256 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 257 RFC 6790, DOI 10.17487/RFC6790, November 2012, 258 . 260 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 261 S. Ray, "North-Bound Distribution of Link-State and 262 Traffic Engineering (TE) Information Using BGP", RFC 7752, 263 DOI 10.17487/RFC7752, March 2016, 264 . 266 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 267 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 268 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 269 March 2016, . 271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 273 May 2017, . 275 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 276 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 277 DOI 10.17487/RFC8491, November 2018, 278 . 280 9.2. Informative References 282 [I-D.ietf-isis-segment-routing-extensions] 283 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 284 Gredler, H., and B. Decraene, "IS-IS Extensions for 285 Segment Routing", draft-ietf-isis-segment-routing- 286 extensions-25 (work in progress), May 2019. 288 Authors' Addresses 290 Xiaohu Xu 291 Alibaba Inc 293 Email: xiaohu.xxh@alibaba-inc.com 295 Sriganesh Kini 297 Email: sriganeshkini@gmail.com 299 Peter Psenak 300 Cisco 302 Email: ppsenak@cisco.com 304 Clarence Filsfils 305 Cisco 307 Email: cfilsfil@cisco.com 309 Stephane Litkowski 310 Cisco 312 Email: sslitkows@cisco.com