idnits 2.17.1 draft-song-mpls-eh-indicator-04.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 (3 January 2022) is 844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS H. Song, Ed. 3 Internet-Draft Futurewei Technologies 4 Intended status: Informational Z. Li 5 Expires: 7 July 2022 T. Zhou 6 Huawei 7 L. Andersson 8 Bronze Dragon Consulting 9 3 January 2022 11 Options for MPLS Extension Header Indicator 12 draft-song-mpls-eh-indicator-04 14 Abstract 16 The intention of this document is to enumerate and describe the 17 candidate schemes that can be used to indicate the presence of the 18 MPLS extension header(s) following the MPLS label stack. After a 19 careful evaluation of these options by comparing their pros and cons, 20 it is expected that one should be chosen as the final standard scheme 21 for MPLS extension header indicator. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119][RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 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 7 July 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Dedicated Extension Header Label . . . . . . . . . . . . . . 3 66 2.1. Special Purpose Label . . . . . . . . . . . . . . . . . . 3 67 2.2. Extension Label plus an Extended Special Purpose Label . 4 68 3. Generic Associated Channel Extension . . . . . . . . . . . . 4 69 3.1. GAL and Associated Channel Header . . . . . . . . . . . . 4 70 3.2. GAL and a Different Nibble Value . . . . . . . . . . . . 5 71 4. Extend MPLS Entropy Label . . . . . . . . . . . . . . . . . . 6 72 5. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 7 73 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 12.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The document [I-D.song-mpls-extension-header] presents the 87 motivation, specification, and use cases of MPLS Extension Header 88 (EH). An indicator is needed in the MPLS label stack to indicate the 89 presence of the extension header(s). Multiple options are possible 90 for this purpose. As the discussion progresses, more options could 91 emerge. 93 In this document, we propound three categories of methods which can 94 be further partitioned into five unique schemes. Four of them use 95 explicit data plane encoding to indicate the EH and the last one 96 implies the EH through control plane configuration. This document 97 details and compares these schemes, in order to foster further 98 discussions until a final decision is made. 100 2. Dedicated Extension Header Label 102 A straightforward method is to directly encode an Extension Header 103 Label (EHL) in the MPLS label stack. Two derived schemes are as 104 follows. 106 2.1. Special Purpose Label 108 A new special purpose label, EHL, can be used to indicate EHs. As 109 specified in [RFC7274], so far eight special purpose label values are 110 still left unsigned by IANA (which are 4 to 6 and 8 to 12). This 111 single label scheme is elegant but arguably demands a scarce 112 resource. We cannot rule out the possibility of requiring more than 113 one label value to differentiate EH classes (e.g., Hop-by-Hop, End- 114 to-End, or both). If this happens, it can only aggravate the 115 situation. 117 Another benefit of this scheme is that an EHL can potentially be 118 located anywhere in an MPLS label stack. It is easier and quicker 119 for a router to figure out the existence of extension header(s) if 120 the EHL is close to or at the top of the label stack. However, if 121 there are legacy devices which can reach the EHL but do not recognize 122 it in a network, then for backward compatibility, the EHL must be 123 located at the bottom of the stack (i.e., only the MPLS tunnel ends 124 and EHL-aware nodes will look up and process it). 126 The format of an EHL is the same as an MPLS label. The first 20-bit 127 label value will be assigned by IANA. The BoS bit is used to 128 indicate the location of the label. The other fields, CoS and TTL, 129 currently have no use in the context of EHL. However, these two 130 fields can potentially be used to encode other information. If such 131 code points are open for other purpose, it will make the single EHL 132 idea more compelling. E.g., the EH category and/or other 133 information, if needed, can be encoded in these fields, so that only 134 one special label value is needed. 136 The following figure shows a potential scheme in which one bit from 137 the CoS field ('H') is used to indicate the presence of HbH EHs in 138 the packet. If 'H' bit is 0, it means no HbH EH follows so a 139 P-router will not need to check the EH. The last 8 bits can be used 140 to find the location of the extension headers (i.e., the first byte 141 after the MPLS label stack). This information can help to avoid the 142 scan of the label stack in case the extension headers need to be 143 accessed. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | EHL (TBD) |H| |S| Offset | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: Special EHL with EH Category Encoding 153 Note that the Cos/TTL fields can be encoded to include more 154 information. For example, in addition to indicate the EH, it can 155 also indicate the presence of some other label-based services (e.g., 156 EL). If we want to explore such possibilities, we have 11 bits in 157 total at our disposal. 159 2.2. Extension Label plus an Extended Special Purpose Label 161 [RFC7274] specifies the Extension Label (XL) with the value of 15. 162 An extended special purpose label (ESPL) following XL can be used as 163 EHL. A large number of ESPL values are available for allocation. 164 The XL+EHL scheme eases the concern on the reserved label space at 165 the cost of one more label in the label stack. 167 Except for the fact that one more label is needed, The XL+EHL scheme 168 shares the same property as the single special purpose EHL scheme. 170 3. Generic Associated Channel Extension 172 The similar "header extension" requirement for MPLS has led to some 173 proposals before. A special Generic Associated Channel Label (GAL) 174 [RFC5586] with the value of 13 has been assigned to support the 175 identification of an Associated Channel Header (ACH). We can extend 176 this existing mechanism to encode the MPLS EH indicator. 178 3.1. GAL and Associated Channel Header 180 The ACH is located below the bottom label. It has a 16-bit Channel 181 Type field which provides abundant space to encode the MPLS EH 182 indicator. This scheme has the same header overhead as the XL+EHL 183 scheme. The format is depicted in Figure 2. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | GAL (13) | EXP |1| TTL | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |0 0 0 1|Version| Reserved | Extension Header Indicator | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 | HEH and EH(s) | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: Associated Channel Header as Extension Header Indicator 199 GAL has several applications already yet its heritage also has 200 several limitations. The GAL must be located at the bottom of a 201 label stack for its chief use cases such as MPLS-TP. So a router 202 needs to search the entire label stack for the BoS bit and check if 203 the corresponding label is GAL. This can impact the performance when 204 the label stack is deep. A more serious concern is that [RFC5586] 205 states that GAL+ACH MUST NOT be used to transport user traffic and an 206 ACH is supposed to be followed by a non-service payload. 208 None of these is insurmountable but it does require an overhaul of 209 the existing RFC in order to extend the usage of GAL. 211 3.2. GAL and a Different Nibble Value 213 To avoid changing the established semantics of ACH, a variation can 214 be used. ACH starts with a nibble value "0001". A different nibble 215 value may be used to redefine the remaining part of the word. The 216 idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define 217 a Metadata Channel Header (MCH) with the leading nibble value "0000". 218 Similarly, we can use another nibble value (e.g., "0010") to define a 219 new header, namely the MPLS Extension Header Indicator (EHI). 221 The format of the GAL and EHI is depicted in Figure 3. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | GAL (13) | EXP |1| TTL | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |0 0 1 0|Version| Reserved | Extension Header Class |<-EHI 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | HEH and EH(s) | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 3: Extension Header Indicator Format 237 The Extension Header Class field in EHI is used to differentiate the 238 extension headers. Potentially there are three classes: Hop-by-Hop 239 (HbH), End-to-End (E2E), or both. If finally we decide to not 240 differentiate the extension headers, we have the opportunity to merge 241 the HEH (see [I-D.song-mpls-extension-header] for details) into EHI, 242 so we can reduce the header overhead by four bytes. The header 243 format is depicted in Figure 4. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | GAL (13) | EXP |1| TTL | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |0 0 1 0| EHCNT | EHTLEN | NH |<-HEH 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | EH(s) | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 4: Merge HEH to EHI 259 4. Extend MPLS Entropy Label 261 Instead of introducing a new SPL as the EH indicator, we can 262 piggyback the indicator in some existing SPL to avoid claiming extra 263 SPL resource and save a label overhead. The best candidate is the 264 entropy label (EL) [RFC6790]. If we can make EL default for every 265 MPLS packet, we can encode the EH indicator in the unused ELI/EL 266 label fields such as CoS and TTL. 268 In Figure 5 we show a possible encoding method, in which the first 269 bit of the CoS field in ELI is used to indicate the presence of EH 270 and the TTL field in ELI can be used to indicate the location of the 271 EH. Note that the CoS field of the EL can also be used to encode 272 other information, if necessary. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ELI (7) |I| |S| Offset | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | EL | |S| 0 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 5: Special EHL with EH Category Encoding 284 5. Configured FEC Labels 286 It is also possible to use FEC labels to indicate the presence of 287 extension headers. An FEC label has the same forwarding semantics as 288 the original label, but it also means that one or more extension 289 headers exist below the label stack. 291 Although this approach avoids the need of new header encoding 292 standards, it introduces a good deal of complexity into the control 293 plane. Since every label needs an FEC label to indicate EH, this 294 scheme also significantly reduces the available label space. Another 295 issue is that this solution may not work for incremental deployment 296 where some legacy routers cannot understand and apply the FEC labels 297 for EH. Moreover, this configuration-based solution certainly makes 298 the cross-domain interoperability more difficult. Hence, this is the 299 least preferred option. We only include it here for the completeness 300 of the discussion. 302 6. Summary 304 Evidenced by the existing and emerging use cases, MPLS networks need 305 a standard way to support extension headers. In Figure 6, we 306 summarize the potential schemes that allow MPLS packets to carry 307 extension headers and list the main pros and cons for each scheme. 309 +---+---------------------------+---------------------------------+ 310 |No.| Description | Pros and Cons | 311 +---+---------------------------+---------------------------------+ 312 | 1 | Special purpose EHL |+ Single label | 313 | | |+ Location freedom | 314 | | |- Need standard extension | 315 | | |- Use scarce resource | 316 +---+---------------------------+---------------------------------+ 317 | 2 | XL(15) + EHL |+ Location freedom | 318 | | |+ Established mechanism | 319 | | |+ Abundant resource | 320 | | |- One extra label than Option 1 | 321 | | |- Need standard extension | 322 +---+---------------------------+---------------------------------+ 323 | 3 | GAL + ACH with channel |+ Reuse existing mechanism | 324 | | type extension |+ Abundant resource | 325 | | |- Label location limitation | 326 | | |- One more word than Option 1 | 327 | | |- Not for user traffic | 328 | | |- Need standard extension/update | 329 +---+---------------------------+---------------------------------+ 330 | 4 | GAL + another nibble value|+ No change to ACH semantics | 331 | | to indicate EHs (e.g., |+ Potential overhead saving | 332 | | "0010") |- Label location limitation | 333 | | |- Hack scarce resource (nibble) | 334 | | |- Need standard extension | 335 +---+---------------------------+---------------------------------+ 336 | 5 | Extend ELI/EL |+ No need for new label | 337 | | |- Need standard update | 338 | | |- Need to make EL mandatory | 339 | | |- One extra label than Option 1 | 340 +---+---------------------------+---------------------------------+ 341 | 6 | FEC label as EH indicator |+ No need for header standard | 342 | | |- Complex control plane | 343 | | |- Cross-domain interoperability | 344 | | |- Label space issue | 345 | | |- Not for incremental deployment | 346 +---+---------------------------+---------------------------------+ 348 Figure 6: Potential Schemes for MPLS Extension Headers 350 Basically we have three groups of solutions. The scheme 1 and 2 351 introduce new labels, the scheme 3, 4, and 5 extend the existing 352 solutions, and the scheme 6 relies on the control plane. Through 353 comprehensive considerations on the pros and cons of each scheme, we 354 expect a working group consensus can be reached to pick the final 355 winner. 357 7. Considerations of EHI 359 The existence of Extension Headers will make the ECMP based on inner 360 IP packet header impossible or harder. If legacy routers need to 361 conduct this kind of ECMP, the process either fails or generates 362 unexpected results. EH-aware routers can do this kind of ECMP but 363 they need to skip all the EHs in order to access the inner packet 364 header which may not be efficient (we make provision in HEH to help 365 accelerate this process). In this case, the Entropy Label (EL) is 366 preferred for ECMP. The Entropy Label Indicator (ELI) and EL should 367 be put in front of the EHI to avoid confusing the legacy routers. 369 8. Security Considerations 371 TBD 373 9. IANA Considerations 375 If the EHL approach is adopted to indicate the presence of MPLS 376 extension header(s), this document requests IANA to assign one or 377 more new Special-Purpose MPLS Label Values from the Special-Purpose 378 Multiprotocol Label Switching (MPLS) Label Values Registry of 379 "Extension Header Label (EHL)". 381 10. Contributors 383 The other contributors of this document are listed as follows. 385 * James Guichard 387 * Stewart Bryant 389 * Bruno Decraene 391 11. Acknowledgments 393 TBD. 395 12. References 397 12.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 405 "MPLS Generic Associated Channel", RFC 5586, 406 DOI 10.17487/RFC5586, June 2009, 407 . 409 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 410 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 411 RFC 6790, DOI 10.17487/RFC6790, November 2012, 412 . 414 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 415 and Retiring Special-Purpose MPLS Labels", RFC 7274, 416 DOI 10.17487/RFC7274, June 2014, 417 . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 12.2. Informative References 425 [I-D.guichard-sfc-mpls-metadata] 426 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 427 "Carrying Metadata in MPLS Networks", Work in Progress, 428 Internet-Draft, draft-guichard-sfc-mpls-metadata-00, 27 429 September 2013, . 432 [I-D.song-mpls-extension-header] 433 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 434 "MPLS Extension Header", Work in Progress, Internet-Draft, 435 draft-song-mpls-extension-header-05, 10 July 2021, 436 . 439 Authors' Addresses 441 Haoyu Song (editor) 442 Futurewei Technologies 443 2330 Central Expressway 444 Santa Clara, 445 United States of America 447 Email: haoyu.song@futurewei.com 448 Zhenbin Li 449 Huawei 450 156 Beiqing Road 451 Beijing, 100095 452 P.R. China 454 Email: lizhenbin@huawei.com 456 Tianran Zhou 457 Huawei 458 156 Beiqing Road 459 Beijing, 100095 460 P.R. China 462 Email: zhoutianran@huawei.com 464 Loa Andersson 465 Bronze Dragon Consulting 466 Stockholm 467 Sweden 469 Email: loa@pi.nu