idnits 2.17.00 (12 Aug 2021) /tmp/idnits7653/draft-li-mpls-redefining-eli-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([GOTO], [I-D.gandhi-mpls-ioam], [I-D.jags-mpls-ext-hdr]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 April 2022) is 37 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-bocci-mpls-miad-adi-requirements-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft University of Surrey 5GIC 4 Intended status: Informational J. Drake 5 Expires: 9 October 2022 T. Li 6 Juniper Networks 7 7 April 2022 9 Redefining ELI considered harmful; NPL considered harmful 10 draft-li-mpls-redefining-eli-00 12 Abstract 14 Recent work on MPLS Network Actions (MNA) has produced two drafts 15 that propose to redefine the MPLS Entropy Label Indicator (ELI) for 16 use with MNA. [I-D.jags-mpls-ext-hdr] [I-D.gandhi-mpls-ioam] This 17 work also proposes the use of a Network Programming Label (NPL) as 18 another option for use with MNA. This document considers both of 19 these options harmful in the sense of [GOTO]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 9 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 56 2. On the Redefinition of ELI . . . . . . . . . . . . . . . . . 3 57 2.1. Backward Compatiblity . . . . . . . . . . . . . . . . . . 3 58 2.1.1. Risk of Bit Reuse . . . . . . . . . . . . . . . . . . 3 59 2.1.2. Risk of additional LSEs . . . . . . . . . . . . . . . 3 60 2.1.3. Risk of Bottom of Stack (BOS) data . . . . . . . . . 4 61 2.2. Claim 1: Faster Deployment . . . . . . . . . . . . . . . 4 62 2.3. Claim 2: Smaller label stack . . . . . . . . . . . . . . 5 63 2.4. Claim 3: No new hardware . . . . . . . . . . . . . . . . 5 64 2.5. Claim 4: Save an SPL . . . . . . . . . . . . . . . . . . 6 65 2.6. Claim 5: Consistent hashing . . . . . . . . . . . . . . . 6 66 2.7. Claim 6: Smaller label stack . . . . . . . . . . . . . . 7 67 3. On the use of Network Programming Labels (NPL) . . . . . . . 7 68 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 5.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Recent work on MPLS Network Actions (MNA) has produced two drafts 77 that propose to redefine the MPLS Entropy Label Indicator (ELI) for 78 use with MNA. [I-D.jags-mpls-ext-hdr] [I-D.gandhi-mpls-ioam] This 79 work also proposes the use of a Network Programming Label (NPL) as 80 another option for use with MNA. This document considers both of 81 these options harmful in the sense of [GOTO]. 83 1.1. Requirement Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. On the Redefinition of ELI 93 In [I-D.jags-mpls-ext-hdr], there are six claims of advantages to 94 reusing ELI versus using a new Special Purpose Label (SPL) or a NPL. 96 2.1. Backward Compatiblity 98 An important consideration when contemplating the use of ELI is the 99 question of backward compatibility. There are two risks with reuse 100 of ELI that need to be articulated. 102 2.1.1. Risk of Bit Reuse 104 As part of the proposal to reuse ELI, the TC and TTL fields of the 105 Entropy Label (EL) Label Stack Entry (LSE) will be reused to provide 106 fields for the In-Stack Extension Header Length (IL) and Entropy 107 Label Control fields (ELC). 109 [RFC6790] says the following regarding these fields: 111 The TTL for the EL MUST be zero to ensure that it is not used 112 inadvertently for forwarding. The TC for the EL may be any value. 114 This proposal violates the first constraint. There is a small, but 115 not inconsequential risk that an implementation will actually check 116 the TTL field and change its behavior if the value is non-zero. 118 2.1.2. Risk of additional LSEs 120 [RFC6790] defines the Entropy Label as containing two LSEs, one 121 containing the ELI and one containing the EL. 123 This proposal also suggests adding additional LSEs after these two 124 LSEs. If a legacy Label Switch Router (LSR) sees the ELI and decides 125 to remove it from the label stack, then it will only remove the first 126 two LSEs, leaving any additional LSEs on the label stack and 127 effectively corrupting it, with unknown consequences. 129 This is a significant and unacceptable risk. 131 Signalling the use of the MNA label stack will avoid this problem, 132 but it also implies that the MNA label stack will not be seen by 133 legacy LSRs. 135 2.1.3. Risk of Bottom of Stack (BOS) data 137 If the MNA label stack implies that there is BOS data after the label 138 stack, and a legacy LSR processes the packet, then it will be unaware 139 of the BOS data and risks processing the BOS data as part of the 140 payload. 142 This is another significant and unacceptable risk. 144 2.2. Claim 1: Faster Deployment 146 The first claim is that reusing the ELI will speed deployment: 148 Faster deployment in an existing network that has EL already 149 deployed with an incremental benefit (e.g., incremental signaling 150 extension for ELI capability). 152 To understand this claim, consider the deployment cycle for MNA. The 153 steps that we, as a community, must undertake are: 155 1. Reach rough consensus. We must determine what we will do for 156 MNA. This will become a set of Internet drafts. 158 2. Develop software. We must write forwarding plane and signalling 159 code in accordance with the above drafts. There may be some 160 overlap between draft development and software development. 162 3. Testing. Software for a production network requires a 163 significant testing effort. 165 4. Deployment. Even given production ready software, it must be 166 deployed throughout a substantial portion of an operator network. 167 To have significant field experience, multiple operators will 168 have to do this in parallel. As software upgrades are frequently 169 service impacting, they require scheduling maintenance windows 170 and are not done frequently. Further, systems are typically 171 upgraded individually, as failures from mass upgrades can lead to 172 mass downtime. 174 Based on previous experience, this entire process is likely to take 175 around three to five years, depending on operator urgency. However, 176 the magnitude of this effort is not the issue, the claim is that 177 using ELI would help shorten this process. 179 Using ELI will not help shorten the consensus process appreciably. 180 There are many issues that need to be resolved. Using ELI will not 181 shorten the development cycle at all. Writing code for ELI or 182 another SPL will take the same amount of time. Similarly, there are 183 no advantages to reusing ELI during testing. 185 Finally, we must consider whether using ELI can impact the deployment 186 time scale. As noted in Section 2.1.2 and Section 2.1.3, exposing an 187 ELI label stack with added LSEs or BOS data is not compatible with 188 legacy LSRs. To avoid this, an operator would have to restrict their 189 use of the MNA label stack to only functions that could be encoded 190 without additional LSEs or BOS data. While this is not impossible, 191 it greatly limits the functionality that can be deployed and creates 192 an enormous operational burden on the network operator because they 193 must enable some, but not all MNA related functionality. If they 194 enable the wrong set of functions, their traffic will be lost. This 195 seems very limiting and fragile. 197 This is an unacceptable combination of risk and burden. 199 Signaling cannot alleviate this. Signaling would direct traffic 200 around legacy nodes, which would not be different than using a new 201 SPL. As such, the reuse of the ELI does not seem to add significant 202 benefits to shorten the deployment time cycle. 204 2.3. Claim 2: Smaller label stack 206 The second claim is that reusing the ELI will result in a smaller 207 label stack: 209 Single label for Entropy in the MPLS header which helps with 210 keeping label stack size smaller. 212 If we use a new SPL to indicate a MNA label stack and entropy is one 213 of the defined functions within the MNA label stack, then this is not 214 true. There is no need to have both a MNA label stack and an ELI 215 simultaneously. All proposals on the table are already taking this 216 approach. 218 This claim is false. 220 2.4. Claim 3: No new hardware 222 The third claim is: 224 When EL is already enabled in the network, the proposed scheme 225 does not require hardware to support an additional SPL indicator. 227 This claim is either suggesting that (a) an additional SPL indicator 228 is burdensome, or (b) that hardware is required to support a new SPL 229 indicator, or (c) both. 231 If point (a) is the interpretation, then it must be noted that there 232 are already many SPLs allocated and in use. One more is not a 233 significant difference and this is a trivial claim. 235 If point (b) is the interpretation, then we must consider legacy 236 hardware. Many implementations have used microcode to process the 237 label stack. Adding an additional SPL is a microcode and not a 238 hardware change. There are possibly some implementations that do 239 process a label stack in pure hardware. These implementations would 240 need a spin to support MNA, regardless of whether or not a new SPL is 241 used. We must focus MNA deployment on the microcoded 242 implementations. 244 Claim 3 is irrelevant. 246 2.5. Claim 4: Save an SPL 248 Claim 4 states: 250 Save a new Special Purpose Label and related protocol extensions 251 to signal its capability in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP- 252 LS, etc. 254 This claim makes two sub-claims. First, reusing ELI would save us 255 from allocating another SPL. This is true, but the risks described 256 in Section 2.1.2 and Section 2.1.3 more than offset this small 257 benefit. 259 Second, the claim is that reusing ELI would avoid making a signaling 260 change. The development of MNA will already require that we make 261 signaling changes. To avoid backward compatibility problems, we will 262 end up signaling each and every function explicitly. Saving the 263 signaling effort for a separate SPL is inconsequential in this light. 265 2.6. Claim 5: Consistent hashing 267 Claim 5 states: 269 An intermediate node can compute ECMP hash with the EL field and 270 avoid inconsistent load-balancing of traffic flow that can happen 271 when MPLS Extension Header alters the label stack. 273 If we use a new SPL, this will also be true. The MNA substack will 274 contain support for an entropy action and the ISD will contain an EL 275 field. Transit nodes will be able to hash on this EL field. 277 Claim 5 is incorrect, as it not an advantage. It is exactly the same 278 as a new SPL. 280 2.7. Claim 6: Smaller label stack 282 Claim 6 states: 284 Reduce MPLS Label stack size when EL is enabled for ECMP hashing 285 when MPLS Extension Header is also used. As there is only one 286 field for EL in the MPLS Header, it simplifies the MPLS header 287 processing. 289 Assuming our MNA solution includes EL as part of its label stack, 290 this is always true, regardless of SPL. 292 Claim 6 is false. 294 3. On the use of Network Programming Labels (NPL) 296 NPL is not defined in an IETF document that the authors could find. 297 An external reference [TDC] says: 299 Network programming labels may be allocated from the global SR 300 Global Block (SRGB) for SR Multiprotocol Label Switching (SR-MPLS) 301 by a Software Defined Networking (SDN) controller. 303 This would seem to imply that an NPL is specific to an SR solution. 304 However, the MNA requirements [I-D.bocci-mpls-miad-adi-requirements] 305 section 3.1.1, requirement 12 says: 307 Data plane mechanisms for ADIs MUST be independent of the control 308 plane type (LDP, RSVP, BGP, static, IGP, etc). 310 This would seem to be contradictory. 312 If the NPL is an arbitrary label selected and and configured by the 313 network operator, this would seem to be an undue burden on the 314 operator. The purpose of standards is to avoid having unique items 315 that must be managed intependently. 317 4. Conclusion 319 This document has shown that the use of ELI or NPL to initiate MNA 320 processing has significant risks and limitations. While some may be 321 willing to accept the risks on their behalf, the decisions that must 322 be made will affect all players in the industry and must be 323 commensurate with everyone's risk tolerance. Accordingly, reusing 324 ELI would seem to be a poor choice and that the industry would be 325 better served if we simply used a new SPL. 327 5. References 329 5.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 341 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 342 RFC 6790, DOI 10.17487/RFC6790, November 2012, 343 . 345 [I-D.bocci-mpls-miad-adi-requirements] 346 Bocci, M. and S. Bryant, "Requirements for MPLS Label 347 Stack Indicators and Ancillary Data", Work in Progress, 348 Internet-Draft, draft-bocci-mpls-miad-adi-requirements-02, 349 3 March 2022, . 352 5.2. Informative References 354 [I-D.jags-mpls-ext-hdr] 355 Rajamanickam, J., Gandhi, R., Bhattacharya, J., Decraene, 356 B., Zigler, R., Cheng, W., and L. Jalil, "MPLS Extension 357 Header Encodings", Work in Progress, Internet-Draft, 358 draft-jags-mpls-ext-hdr-00, 2 March 2022, 359 . 362 [I-D.gandhi-mpls-ioam] 363 Gandhi, R., Ali, Z., Brockners, F., Wen, B., Decraene, B., 364 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 365 OAM Data", Work in Progress, Internet-Draft, draft-gandhi- 366 mpls-ioam-04, 2 March 2022, 367 . 370 [GOTO] Dijkstra, E. W., "Go To Statement Considered Harmful", 371 DOI 10.1145/362929.362947, in Communications of The 372 Association for Computing Machinery, volume 11, number 3, 373 pages 147-148, 1968, 374 . 377 [TDC] Filsfils, C. and R. Gandhi, "Network Programming for 378 Performance and Liveness Monitoring In Segment Routing 379 Networks", Technical Disclosure Commons , May 2019, 380 . 383 Authors' Addresses 385 Stewart Bryant 386 University of Surrey 5GIC 387 Email: sb@stewartbryant.com 389 John Drake 390 Juniper Networks 391 Email: jdrake@juniper.net 393 Tony Li 394 Juniper Networks 395 Email: tony.li@tony.li