idnits 2.17.1 draft-ietf-isis-mpls-elc-08.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 3, 2019) is 1697 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 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 2 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 6, 2020 6 P. Psenak 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 September 3, 2019 13 Signaling Entropy Label Capability and Entropy Readable Label Depth 14 Using IS-IS 15 draft-ietf-isis-mpls-elc-08 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 Label Switched Path (LSP) unless an egress LSR has indicated 23 via signaling that it has the capability to process ELs, referred to 24 as Entropy Label Capability (ELC), on that tunnel. In addition, it 25 would be useful for ingress LSRs to know each LSR's capability for 26 reading the maximum label stack depth and performing EL-based load- 27 balancing, referred to as Entropy Readable Label Depth (ERLD). This 28 document defines a mechanism to signal these two capabilities using 29 IS-IS. These mechanisms are particularly useful, where label 30 advertisements are done via protocols like 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 March 6, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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 ERLD Using IS-IS . . . . . . . . . . . . . . . . 3 69 4. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 71 6. BGP-LS Extension . . . . . . . . . . . . . . . . . . . . . . 4 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 [RFC6790] describes a method to load-balance Multiprotocol Label 80 Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use 81 of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the 82 concept of Entropy Label Capability (ELC) and defines the signalings 83 of this capability via MPLS signaling protocols. Recently, 84 mechanisms have been defined to signal labels via link-state Interior 85 Gateway Protocols (IGP) such as IS-IS 86 [I-D.ietf-isis-segment-routing-extensions]. In such scenarios, the 87 defined signaling mechanisms are inadequate. This draft defines a 88 mechanism to signal the ELC using IS-IS. This mechanism is useful 89 when the label advertisement is also done via IS-IS. 91 In addition, in the cases where LSPs are used for whatever reasons 92 (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be 93 useful for ingress LSRs to know each intermediate LSR's capability of 94 reading the maximum label stack depth and performing EL-based load- 95 balancing. This capability, referred to as Entropy Readable Label 96 Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may 97 be used by ingress LSRs to determine the position of the EL label in 98 the stack, and whether it's necessary to insert multiple ELs at 99 different positions in the label stack. 101 2. Terminology 103 This memo makes use of the terms defined in [RFC6790] and [RFC4971]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Advertising ERLD Using IS-IS 113 A new MSD-type of the Node MSD sub-TLV [RFC8491], called ERLD is 114 defined to advertise the ERLD of a given router. As shown in 115 Figure 2, it is formatted as described in [RFC8491] with a new MSD- 116 Type code to be assigned by IANA (the type code of 2 is desired) and 117 the Value field is set to the ERLD in the range between 0 to 255. 118 The scope of the advertisement depends on the application. If a 119 router has multiple line-cards with different capabilities of reading 120 the maximum label stack depth, the router MUST advertise the smallest 121 one. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | MSD-Type=TBD2 | ERLD | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 2: ERLD MSD-Type Format 130 4. Advertising ELC Using IS-IS 132 Even though ELC is a property of the node, in some cases it is 133 advantageous to associate and advertise the ELC with a prefix. In a 134 multi-area network, routers may not know the identity of the prefix 135 originator in a remote area, or may not know the capabilities of such 136 originator. Similarly in a multi-domain network, the identity of the 137 prefix originator and its capabilities may not be known to the 138 ingress LSR. 140 One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV" 141 registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by 142 the IANA for the ELC. If a router has multiple line cards, the 143 router MUST NOT announce the ELC for any prefixes that are locally 144 attached unless all of its line-cards are capable of processing ELs. 146 If a router supports ELs on all of its line-cards, it SHOULD set the 147 ELC for every local host prefix it advertises in IS-IS. 149 When a router leaks a prefix between two levels (upwards or 150 downwards), it MUST preserve the ELC signaling for this prefix. 152 0 1 2 3 4 5 6 7... 153 +-+-+-+-+-+-+-+-+... 154 |X|R|N|E| ... 155 +-+-+-+-+-+-+-+-+... 157 When redistributing a prefix between two IS-IS protocol instances or 158 redistributing from another protocol to an IS-IS protocol instance, a 159 router SHOULD preserve the ELC signaling for that prefix. The exact 160 mechanism used to exchange ELC between protocol instances running on 161 an ASBR is outside of the scope of this document and is 162 implementation specific. 164 5. Acknowledgements 166 The authors would like to thank Yimin Shen, George Swallow, Acee 167 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene 168 Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their 169 valuable comments. 171 6. BGP-LS Extension 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 Flag included in the Prefix Attribute Flags sub-TLV, as 177 defined in Section 4, is advertised using the Prefix Attribute Flags 178 TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as 179 defined in section 2.3.2 of 180 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 182 The ERLD MSD-type introduced for IS-IS in Section 3 is advertised 183 using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as 184 defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 186 7. IANA Considerations 188 IANA is requested to allocate the E-bit (bit position 3 is desired) 189 from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. 191 IANA is requested to allocate a MSD type (the type code of 2 is 192 desired) from the "IGP MSD Types" registry for ERLD. 194 8. Security Considerations 196 The security considerations as described in [RFC4971] nd 197 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 199 Incorrectly setting the E flag (ELC capable) (during origination, 200 leaking or redistribution) may lead to black-holing of the traffic on 201 the egress node. 203 9. Normative References 205 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 206 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 207 and M. Chen, "BGP Link-State extensions for Segment 208 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 209 (work in progress), June 2019. 211 [I-D.ietf-isis-segment-routing-extensions] 212 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 213 Gredler, H., and B. Decraene, "IS-IS Extensions for 214 Segment Routing", draft-ietf-isis-segment-routing- 215 extensions-25 (work in progress), May 2019. 217 [I-D.ietf-mpls-spring-entropy-label] 218 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 219 Shakir, R., and J. Tantsura, "Entropy label for SPRING 220 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 221 progress), July 2018. 223 [I-D.ietf-spring-segment-routing-mpls] 224 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 225 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 226 data plane", draft-ietf-spring-segment-routing-mpls-22 227 (work in progress), May 2019. 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 235 "Intermediate System to Intermediate System (IS-IS) 236 Extensions for Advertising Router Information", RFC 4971, 237 DOI 10.17487/RFC4971, July 2007, 238 . 240 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 241 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 242 RFC 6790, DOI 10.17487/RFC6790, November 2012, 243 . 245 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 246 S. Ray, "North-Bound Distribution of Link-State and 247 Traffic Engineering (TE) Information Using BGP", RFC 7752, 248 DOI 10.17487/RFC7752, March 2016, 249 . 251 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 252 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 253 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 254 March 2016, . 256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 258 May 2017, . 260 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 261 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 262 DOI 10.17487/RFC8491, November 2018, 263 . 265 Authors' Addresses 267 Xiaohu Xu 268 Alibaba Inc 270 Email: xiaohu.xxh@alibaba-inc.com 272 Sriganesh Kini 274 Email: sriganeshkini@gmail.com 276 Peter Psenak 277 Cisco 279 Email: ppsenak@cisco.com 281 Clarence Filsfils 282 Cisco 284 Email: cfilsfil@cisco.com 285 Stephane Litkowski 286 Orange 288 Email: stephane.litkowski@orange.com