idnits 2.17.00 (12 Aug 2021) /tmp/idnits47455/draft-song-mpls-eh-indicator-01.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 (March 10, 2021) is 437 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-song-mpls-extension-header-02 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: September 11, 2021 T. Zhou 6 Huawei 7 L. Andersson 8 Bronze Dragon Consulting 9 March 10, 2021 11 Options for MPLS Extension Header Indicator 12 draft-song-mpls-eh-indicator-01 14 Abstract 16 This document describes the schemes that indicates the presence of 17 the MPLS extension header(s) following the MPLS label stack. After a 18 thorough evaluation of these options by comparing their pros and 19 cons, one should be chosen as the final scheme for MPLS extension 20 header indicator. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119][RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 11, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified 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 . 3 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 . . . . . . . . . . . . 4 71 4. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 5 72 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 7 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 11.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The document [I-D.song-mpls-extension-header] presents the 86 motivation, specification, and use cases of MPLS Extension Header 87 (EH). However, multiple options are possible to indicate the 88 presence of the extension header(s). 90 We propound three categories of methods which can be further 91 partitioned into five unique schemes. Four of them use explicit data 92 plane encoding to indicate the EH and the last one implies the EH 93 through control plane configuration. This document details and 94 compares these schemes, in order to foster further discussions until 95 a final decision is made. 97 2. Dedicated Extension Header Label 99 A straightforward method is to directly encode an Extension Header 100 Label (EHL) in the MPLS label stack. Two derived schemes are as 101 follows. 103 2.1. Special Purpose Label 105 A new special purpose label, EHL, can be used to indicate EHs. As 106 specified in [RFC7274], so far eight special purpose label values are 107 still left unsigned by IANA (which are 4 to 6 and 8 to 12). This 108 single label scheme is elegant but arguably demands a scarce 109 resource. We cannot rule out the possibility of requiring more than 110 one label value to differentiate EH classes (e.g., Hop-by-Hop, End- 111 to-End, or both). If this happens, it can only aggravate the 112 situation. 114 Another benefit of this scheme is that an EHL can potentially be 115 located anywhere in an MPLS label stack. It is easier and quicker 116 for a router to figure out the existence of extension header(s) if 117 the EHL is close to or at the top of the label stack. However, if 118 there are legacy devices which can reach the EHL but do not recognize 119 it in a network, then for backward compatibility, the EHL must be 120 located at the bottom of the stack (i.e., only the MPLS tunnel ends 121 and EHL-aware nodes will look up and process it). 123 The format of an EHL is the same as an MPLS label. The first 20-bit 124 label value will be assigned by IANA. The BoS bit is used to 125 indicate the location of the label. The other fields, CoS and TTL, 126 currently have no use in the context of EHL. However, these two 127 fields can potentially be used to encode other information, which is 128 beyond the scope of this document. 130 2.2. Extension Label plus an Extended Special Purpose Label 132 [RFC7274] specifies the Extension Label (XL) with the value of 15. 133 An extended special purpose label (ESPL) following XL can be used as 134 EHL. A large number of ESPL values are available for allocation. 135 The XL+EHL scheme eases the concern on the reserved label space at 136 the cost of one more label in the label stack. 138 Except for the fact that one more label is needed, The XL+EHL scheme 139 shares the same property as the single special purpose EHL scheme. 141 3. Generic Associated Channel Extension 143 The similar "header extension" requirement for MPLS has led to some 144 proposals before. A special Generic Associated Channel Label (GAL) 145 [RFC5586] with the value of 13 has been assigned to support the 146 identification of an Associated Channel Header (ACH). We can extend 147 this existing mechanism to encode the MPLS EH indicator. 149 3.1. GAL and Associated Channel Header 151 The ACH is located below the bottom label. It has a 16-bit Channel 152 Type field which provides abundant space to encode the MPLS EH 153 indicator. This scheme has the same header overhead as the XL+EHL 154 scheme. The format is depicted in Figure 1. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | GAL (13) | EXP |1| TTL | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |0 0 0 1|Version| Reserved | Extension Header Indicator | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 | HEH and EH(s) | 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: Associated Channel Header as Extension Header Indicator 170 GAL has several applications already yet its heritage also has 171 several limitations. The GAL must be located at the bottom of a 172 label stack for its chief use cases such as MPLS-TP. So a router 173 needs to search the entire label stack for the BoS bit and check if 174 the corresponding label is GAL. This can impact the performance when 175 the label stack is deep. A more serious concern is that [RFC5586] 176 states that GAL+ACH MUST NOT be used to transport user traffic and an 177 ACH is supposed to be followed by a non-service payload. 179 None of these is insurmountable but it does require an overhaul of 180 the existing RFC in order to extend the usage of GAL. 182 3.2. GAL and a Different Nibble Value 184 To avoid changing the established semantics of ACH, a variation can 185 be used. ACH starts with a nibble value "0001". A different nibble 186 value may be used to redefine the remaining part of the word. The 187 idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define 188 a Metadata Channel Header (MCH) with the leading nibble value "0000". 190 Similarly, we can use another nibble value (e.g., "0010") to define a 191 new header, namely the MPLS Extension Header Indicator (EHI). 193 The format of the GAL and EHI is depicted in Figure 2. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | GAL (13) | EXP |1| TTL | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |0 0 1 0|Version| Reserved | Extension Header Class |<-EHI 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | HEH and EH(s) | 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2: Extension Header Indicator Format 209 The Extension Header Class field in EHI is used to differentiate the 210 extension headers. Potentially there are three classes: Hop-by-Hop 211 (HbH), End-to-End (E2E), or both. If finally we decide to not 212 differentiate the extension headers, we have the opportunity to merge 213 the HEH (see [I-D.song-mpls-extension-header] for details) into EHI, 214 so we can reduce the header overhead by four bytes. The header 215 format is depicted in Figure 3. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | GAL (13) | EXP |1| TTL | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |0 0 1 0| EHCNT | EHTLEN | NH |<-HEH 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 | EH(s) | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 3: Merge HEH to EHI 231 4. Configured FEC Labels 233 It is also possible to use FEC labels to indicate the presence of 234 extension headers. An FEC label has the same forwarding semantics as 235 the original label, but it also means that one or more extension 236 headers exist below the label stack. 238 Although this approach avoids the need of new header encoding 239 standards, it introduces a good deal of complexity into the control 240 plane. Since every label needs an FEC label to indicate EH, this 241 scheme also significantly reduces the available label space. Another 242 issue is that this solution may not work for incremental deployment 243 where some legacy routers cannot understand and apply the FEC labels 244 for EH. Moreover, this configuration-based solution certainly makes 245 the cross-domain interoperability more difficult. Hence, this is the 246 least preferred option. We only include it here for the completeness 247 of the discussion. 249 5. Summary 251 Evidenced by the existing and emerging use cases, MPLS networks need 252 a standard way to support extension headers. In Figure 4, we 253 summarize the potential schemes that allow MPLS packets to carry 254 extension headers and list the main pros and cons for each scheme. 256 +---+---------------------------+---------------------------------+ 257 |No.| Description | Pros and Cons | 258 +---+---------------------------+---------------------------------+ 259 | 1 | Special purpose EHL |+ Single label | 260 | | |+ Location freedom | 261 | | |- Need standard extension | 262 | | |- Use scarce resource | 263 +---+---------------------------+---------------------------------+ 264 | 2 | XL(15) + EHL |+ Location freedom | 265 | | |+ Established mechanism | 266 | | |+ Abundant resource | 267 | | |- One extra label than Optiona 1 | 268 | | |- Need standard extension | 269 +---+---------------------------+---------------------------------+ 270 | 3 | GAL + ACH with channel |+ Reuse existing mechanism | 271 | | type extension |+ Abundant resource | 272 | | |- Label location limitation | 273 | | |- One more word than Option 1 | 274 | | |- Not for user traffic | 275 | | |- Need standard extension/update | 276 +---+---------------------------+---------------------------------+ 277 | 4 | GAL + another nibble value|+ No change to ACH semantics | 278 | | to indicate EHs (e.g., |+ Potential overhead saving | 279 | | "0010") |- Label location limitation | 280 | | |- Hack scarce resource (nibble) | 281 | | |- Need standard extension | 282 +---+---------------------------+---------------------------------+ 283 | 5 | FEC label as EH indicator |+ No need for header standard | 284 | | |- Complex control plane | 285 | | |- Cross-domain interoperability | 286 | | |- Label space issue | 287 | | |- Not for incremental deployment | 288 +---+---------------------------+---------------------------------+ 290 Figure 4: Potential Schemes for MPLS Extension Headers 292 Through comprehensive considerations on the pros and cons of each 293 scheme, we expect a working group consensus can be reached to pick 294 the final winner. 296 6. Considerations of EHI 298 The existence of Extension Headers will make the ECMP based on inner 299 IP packet header impossible or harder. If legacy routers need to 300 conduct this kind of ECMP, the process either fails or generates 301 unexpected results. EH-aware routers can do this kind of ECMP but 302 they need to skip all the EHs in order to access the inner packet 303 header which may not be efficient. In this case, the Entropy Label 304 (EL) is preferred for ECMP. The Entropy Label Indicator (ELI) and EL 305 should be put in front of the EHI to avoid confusing the legacy 306 routers. 308 7. Security Considerations 310 TBD 312 8. IANA Considerations 314 If the EHL approach is adopted to indicate the presence of MPLS 315 extension header(s), this document requests IANA to assign one or 316 more new Special-Purpose MPLS Label Values from the Special-Purpose 317 Multiprotocol Label Switching (MPLS) Label Values Registry of 318 "Extension Header Label (EHL)". 320 9. Contributors 322 The other contributors of this document are listed as follows. 324 o James Guichard 326 o Stewart Bryant 328 10. Acknowledgments 330 TBD. 332 11. References 334 11.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 342 "MPLS Generic Associated Channel", RFC 5586, 343 DOI 10.17487/RFC5586, June 2009, 344 . 346 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 347 and Retiring Special-Purpose MPLS Labels", RFC 7274, 348 DOI 10.17487/RFC7274, June 2014, 349 . 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 353 May 2017, . 355 11.2. Informative References 357 [I-D.guichard-sfc-mpls-metadata] 358 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 359 "Carrying Metadata in MPLS Networks", draft-guichard-sfc- 360 mpls-metadata-00 (work in progress), September 2013. 362 [I-D.song-mpls-extension-header] 363 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 364 Extension Header", draft-song-mpls-extension-header-02 365 (work in progress), February 2019. 367 Authors' Addresses 369 Haoyu Song (editor) 370 Futurewei Technologies 371 2330 Central Expressway 372 Santa Clara 373 USA 375 Email: haoyu.song@huawei.com 377 Zhenbin Li 378 Huawei 379 156 Beiqing Road 380 Beijing, 100095 381 P.R. China 383 Email: lizhenbin@huawei.com 385 Tianran Zhou 386 Huawei 387 156 Beiqing Road 388 Beijing, 100095 389 P.R. China 391 Email: zhoutianran@huawei.com 392 Loa Andersson 393 Bronze Dragon Consulting 395 Stockholm 396 Sweden 398 Email: loa@pi.nu