idnits 2.17.1 draft-ietf-isis-mpls-elc-07.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 14, 2019) is 1809 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) == Unused Reference: 'RFC5305' is defined on line 216, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 230, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-24 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 4 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: November 15, 2019 6 P. Psenak 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 May 14, 2019 13 Signaling Entropy Label Capability and Entropy Readable Label Depth 14 Using IS-IS 15 draft-ietf-isis-mpls-elc-07 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 of processing ELs, referred 24 to as Entropy Label Capability (ELC), on that tunnel. In addition, 25 it would be useful for ingress LSRs to know each LSR's capability of 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 November 15, 2019. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 [RFC6790] describes a method to load-balance Multiprotocol Label 79 Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use 80 of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the 81 concept of Entropy Label Capability (ELC) and defines the signalings 82 of this capability via MPLS signaling protocols. Recently, 83 mechanisms have been defined to signal labels via link-state Interior 84 Gateway Protocols (IGP) such as IS-IS 85 [I-D.ietf-isis-segment-routing-extensions]. In such scenario, the 86 defined signaling mechanisms are inadequate. This draft defines a 87 mechanism to signal the ELC using IS-IS. This mechanism is useful 88 when the label advertisement is also done via IS-IS. 90 In addition, in the cases where stacked LSPs are used for whatever 91 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 92 would be useful for ingress LSRs to know each intermediate LSR's 93 capability of reading the maximum label stack depth and performing 94 EL-based load-balancing. This capability, referred to as Entropy 95 Readable Label Depth (ERLD) as defined in 96 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 97 determine whether it's necessary to insert an EL for a given LSP in 98 the case where there has already been at least one EL in the label 99 stack [I-D.ietf-mpls-spring-entropy-label]. 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 linecards 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 the remote area, or may not know the capabilities of 136 such originator. Similarly in a multi-domain network, the identity 137 of the 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 linecards are capable of processing ELs. 146 If a router supports ELs on all of its linecards, 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 signalling 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 redistributed from another protocol to an IS-IS protocol instance, a 159 router SHOULD preserve the ELC signalling for that prefix. The exact 160 mechanism on how to exchange ELC between protocol instances running 161 on 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. IANA Considerations 173 IANA is requested to allocate the E-bit (bit position 3 is desired) 174 from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. 176 IANA is requested to allocate a MSD type (the type code of 2 is 177 desired) from the "IGP MSD Types" registry for ERLD. 179 7. Security Considerations 181 The security considerations as described in [RFC4971] are applicable 182 to this document. This document does not introduce any new security 183 risks. 185 8. Normative References 187 [I-D.ietf-isis-segment-routing-extensions] 188 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 189 Gredler, H., and B. Decraene, "IS-IS Extensions for 190 Segment Routing", draft-ietf-isis-segment-routing- 191 extensions-24 (work in progress), April 2019. 193 [I-D.ietf-mpls-spring-entropy-label] 194 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 195 Shakir, R., and J. Tantsura, "Entropy label for SPRING 196 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 197 progress), July 2018. 199 [I-D.ietf-spring-segment-routing-mpls] 200 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 201 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 202 data plane", draft-ietf-spring-segment-routing-mpls-22 203 (work in progress), May 2019. 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, 207 DOI 10.17487/RFC2119, March 1997, 208 . 210 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 211 "Intermediate System to Intermediate System (IS-IS) 212 Extensions for Advertising Router Information", RFC 4971, 213 DOI 10.17487/RFC4971, July 2007, 214 . 216 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 217 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 218 2008, . 220 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 221 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 222 RFC 6790, DOI 10.17487/RFC6790, November 2012, 223 . 225 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 226 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 227 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 228 March 2016, . 230 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 231 Writing an IANA Considerations Section in RFCs", BCP 26, 232 RFC 8126, DOI 10.17487/RFC8126, June 2017, 233 . 235 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 236 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 237 May 2017, . 239 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 240 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 241 DOI 10.17487/RFC8491, November 2018, 242 . 244 Authors' Addresses 246 Xiaohu Xu 247 Alibaba Inc 249 Email: xiaohu.xxh@alibaba-inc.com 251 Sriganesh Kini 253 Email: sriganeshkini@gmail.com 255 Peter Psenak 256 Cisco 258 Email: ppsenak@cisco.com 260 Clarence Filsfils 261 Cisco 263 Email: cfilsfil@cisco.com 265 Stephane Litkowski 266 Orange 268 Email: stephane.litkowski@orange.com