idnits 2.17.1 draft-kbbma-mpls-1stnibble-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC8469], [RFC4928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (27 April 2022) is 728 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) == Missing Reference: 'X' is mentioned on line 200, but not defined == Missing Reference: 'Y' is mentioned on line 200, but not defined == Missing Reference: 'A' is mentioned on line 199, but not defined == Missing Reference: 'C' is mentioned on line 200, but not defined == Missing Reference: 'RFC4448' is mentioned on line 320, but not defined Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group K. Kompella, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Bryant 5 Expires: 29 October 2022 University of Surrey 5GIC 6 M. Bocci 7 Nokia 8 G. Mirsky 9 Ericsson 10 L. Andersson 11 Bronze Dragon Consulting 12 27 April 2022 14 IANA Registry for the First Nibble Following a Label Stack 15 draft-kbbma-mpls-1stnibble-01 17 Abstract 19 The goal of this memo is to create a new IANA registry (called the 20 MPLS First Nibble registry) for the first nibble (4-bit field) 21 immediately following an MPLS label stack. The memo offers a 22 rationale for such a registry, describes how the registry should be 23 managed, and provides some initial entries. Furthermore, this memo 24 sets out some documentation requirements for registering new values. 25 Finally, it provides some recommendations that makes processing MPLS 26 packets easier and more robust. 28 There is an important caveat on the use of this registry versus the 29 IP version number registry. 31 This memo, if published, would update [RFC4928] and [RFC8469]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 29 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 68 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Why Look at the First Nibble . . . . . . . . . . . . . . 6 70 2.1.1. Load Balancing . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Requirement . . . . . . . . . . . . . . . . . . . . . 8 72 2.1.3. Recommendation . . . . . . . . . . . . . . . . . . . 8 73 2.1.4. Parsing the Post-stack Header . . . . . . . . . . . . 9 74 2.2. Why Create a Registry . . . . . . . . . . . . . . . . . . 9 75 2.3. Caveat . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. MPLS First Nibble Registry . . . . . . . . . . . . . . . 10 78 3.1.1. Allocation Policy . . . . . . . . . . . . . . . . . . 10 79 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 4.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 An MPLS packet consists of a label stack, an optional "post-stack 87 header" and an optional embedded packet (in that order). However, in 88 the data plane, there are scant clues regarding the post-stack 89 header, and no clue as to the type of embedded packet; this 90 information is communicated via other means, such as the routing 91 protocols that signal the labels in the stack. Nonetheless, in order 92 to better handle an MPLS packet in the data plane, it is common 93 practice for network equipment to "guess" the type of embedded 94 packet. Such equipment may also need to process the post-stack 95 header. Both of these require parsing the data after the label 96 stack. To do this, the "first nibble" (the top four bits of the 97 first octet following the label stack) is often used. 99 The semantics and usage of the first nibble is not well documented, 100 nor are the assignments of values. This memo serves three purposes: 102 * To document the assignments already made 104 * To provide for the clear documentation of future assignments 105 through the creation of an "MPLS First Nibble registry" 107 * Provide a method to tracking usage by requiring more consistent 108 documentation 110 1.1. Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 LSR: label switching router. 120 MPLS packet: one whose Layer 2 header declares the type to be MPLS. 121 For Ethernet, that means the Ethertype is 0x8847 or 0x8848. 123 Label Stack: (of an MPLS packet) all labels (four octet fields) 124 after the Layer 2 header, up to and including the label with the 125 BoS bit set ([RFC3032]). 127 MPLS First Nibble (MFN): the most significant four bits of the first 128 octet following the label stack. 130 MPLS Payload: all data after the label stack, including the MFN, an 131 optional post-stack header and the embedded packet. 133 Post-stack Header (PSH): optional field of interest to the egress 134 LSR (and possibly to transit LSRs). Examples include a control 135 word or an associated channel. The PSH MUST indicate its length, 136 so that a parser knows where the embedded packet starts. 138 Embedded Packet: All octets beyond the PSH (if any). This could be 139 an IPv4 or IPv6 packet (e.g., for traffic engineering of IP 140 packets, or for a Layer 3 VPN [RFC4364]), an Ethernet packet (for 141 VPLS ([RFC4761], [RFC4762]) or EVPN [RFC7432]), or some other type 142 of Layer 2 frame [RFC4446]. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 147 X | Layer 2 Header | | 148 | | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 150 TC S TTL 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 152 Y | Label-1 | TC |0| TTL | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Label-2 | TC |0| TTL | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ... | TC |0| TTL | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Label-n | TC |1| TTL | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 161 Figure 1: Example of an MPLS Packet With Label Stack 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 164 A | (MFN) | IP packet | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | data | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | end of IP packet | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 174 B | (MFN) | non-IP packet | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | data | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | end of non-IP packet | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 184 C | (MFN) | PSH | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | PSH | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 ... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | end of PSH | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | embedded packet | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 195 Figure 2: Three Examples of MPLS Payloads 197 Figure 1 shows an MPLS packet with Layer 2 header X and a label stack 198 Y ending with Label-n. Figure 2 shows three examples of an MPLS 199 payload, A, B and C. The full MPLS packets thus are: [X, Y, A], [X, 200 Y, B], and [X, Y, C]. 202 A. The first payload is a bare IP packet, i.e., no PSH. The MFN 203 (MPLS First Nibble) in this case overlaps with the IP version number. 205 B. The next payload is a bare non-IP packet; again, no PSH. The MFN 206 here is the first nibble of the payload, whatever it happens to be. 208 C. The last example is an MPLS Payload that starts with a PSH 209 followed by the embedded packet. 211 2. Rationale 213 2.1. Why Look at the First Nibble 215 An MPLS packet can contain many types of embedded packet. The most 216 common types are: 218 1. An IPv4 packet (whose IP header has version number 4). 220 2. An IPv6 packet (whose IP header has version number 6). 222 3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the 223 Start frame delimiter), starting with the destination MAC 224 address. 226 Many other packet types are possible, and in principle, any Layer 2 227 embedded packet is permissible; indeed, in the past, PPP, Frame Relay 228 and ATM packets were reasonably common. 230 In addition, there may be a post-stack header ahead of the embedded 231 packet, and this needs be to parsed. The MPLS First Nibble is 232 currently used for both of these purposes. 234 2.1.1. Load Balancing 236 There are four common ways to load balance an MPLS packet: 238 1. One can use the top label alone. 240 2. One can do better by using all the (non-SPL) labels in the stack. 242 3. One can do even better by "divining" the type of embedded packet, 243 and using fields from the guessed header. 245 4. One can do best by using either an Entropy Label [RFC6790] or a 246 FAT Pseudowire Label [RFC6391]; see Section 2.1.3.) 248 Load balancing based on just the top label means that all packets 249 with that top label will go the same way -- this is far from ideal. 250 Load balancing based on the entire label stack (not including SPLs) 251 is better, but may still be uneven. If, however, the embedded packet 252 is an IP packet, then the combination of (, , , , and ) 254 from the IP header of the embedded packet forms an excellent basis 255 for load balancing. This is what is typically used for load 256 balancing IP packets. 258 An MPLS packet doesn't, however, carry a payload type identifier. 259 There is a simple heuristic that is commonly used to guess the type 260 of the embedded packet. The first nibble, i.e., the four most 261 significant bits of the first octet, of an IP header contains the IP 262 version number. This in turn indicates where to find the relevant 263 fields for load balancing. The heuristic goes roughly as follows: 265 2.1.1.1. Heuristic for Load Balancing 267 1. If the MFN is 0x4 (0100b), treat the payload as an IPv4 packet, 268 and find the relevant fields for load balancing on that basis. 270 2. If the MFN is 0x6 (0101b), treat the payload as an IPv6 packet, 271 and find the relevant fields for load balancing on that basis. 273 3. If the MFN is anything else, the MPLS payload is not an IP 274 packet; fall back to load balancing using the label stack. 276 This heuristic has been implemented in many (legacy) routers, and 277 performs well in the case of Figure 1, A. However, this heuristic 278 can work very badly for Figure 1, B. For example, if payload B is an 279 Ethernet frame, then the MFN is the first nibble of the OUI of the 280 destination MAC address, which can be 0x4 or 0x6, and if so would 281 lead to very bad load balancing. This behavior can happen to other 282 types of non-IP payload as well. 284 This in turn led to the idea of inserting a PSH (e.g., a pseudowire 285 control word [RFC4385], a DetNet control word [RFC8964] or a BIER 286 header [RFC8296]) where the MPLS First Nibble is NOT 0x4 or 0x6, to 287 explicitly prevent forwarding engines from confusing the MPLS payload 288 with an IP packet. [RFC8469] recommends the use of a control word 289 when the embedded packet is an Ethernet frame. RFC 8469 was 290 published at the request of the operator community and the IEEE RAC 291 as a result of operational difficulties with pseudowires that did not 292 contain the control word. 294 This memo introduces a requirement and a recommendation, the first 295 building on the above; the second deprecating the use of the 296 heuristic in Section 2.1.1.1. The intent of both of these is that 297 legacy routers continue to operate as they have, with no new problems 298 introduced as a result of this memo. However, new implementations 299 SHOULD follow these recommendations for more robust operation. 301 2.1.2. Requirement 303 Going forward, network equipment MUST use a post-stack header with an 304 MPLS First Nibble value that is not 0x4 or 0x6 in all cases when the 305 MPLS payload is not an IP packet. Effectively, Figure 1, B is 306 disallowed. [AGREED???] 308 This replaces the following text from [RFC4928], section 3, paragraph 309 3: 311 "It is REQUIRED, however, that applications depend upon in-order 312 packet delivery restrict the first nibble values to 0x0 and 0x1. 313 This will ensure that their traffic flows will not be affected if 314 some future routing equipment does similar snooping on some future 315 version(s) of IP." 317 This also replaces the following text from [RFC8469], section 4, 318 paragraph 1: 320 "This document updates [RFC4448] to state that both the ingress 321 provider edge (PE) and the egress PE SHOULD support the Ethernet PW 322 CW and that, if supported, the CW MUST be used." 324 2.1.3. Recommendation 326 It is RECOMMENDED that, going forward, if good load balancing of MPLS 327 packets is desired, either an Entropy Label or a FAT Pseudowire Label 328 SHOULD be used; furthermore, going forward, the heuristic in 329 Section 2.1.1.1 MUST NOT be used. [AGREED???] 331 A consequence of Recommendation 2 is that, while legacy routers may 332 look for a MPLS First Nibble of 0x4 or 0x6, no router will look for a 333 MPLS First Nibble of 0x7 (or whatever the next IP version number will 334 be) for load balancing purposes. This means that the values 0x4 and 335 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 336 packets, but no other First Nibble values will be used to identify IP 337 packets. 339 This obviates the need for paragraph 4, section 3 in [RFC4928]: 341 "This behavior implies that if in the future an IP version is defined 342 with a version number of 0x0 or 0x1, then equipment complying with 343 this BCP would be unable to look past one or more MPLS headers, and 344 loadsplit traffic from a single LSP across multiple paths based on a 345 hash of specific fields in the IPv0 or IPv1 headers. That is, IP 346 traffic employing these version numbers would be safe from 347 disturbances caused by inappropriate loadsplitting, but would also 348 not be able to get the performance benefits." 350 This also expands the MFN Registry to all 16 possible values, not 351 just 0x0 and 0x1. 353 2.1.4. Parsing the Post-stack Header 355 Given the above recommendations on the use of a post-stack header and 356 future non-use of the heuristic (Section 2.1.1.1) via the use of 357 Entropy or FAT Pseudowire Labels, the main reason for creating a 358 First Nibble registry is to document the types of post-stack headers 359 that may follow a label stack, and to simplify their parsing. 361 2.2. Why Create a Registry 363 The MPLS WG is currently engaged in updating the MPLS architecture; 364 part of this work involves the use of post-stack headers. This is 365 not possible if post-stack header values are allocated on an ad hoc 366 basis, and their parsing and semantics is ill-specified. Consider 367 that the MPLS First Nibble value of 0x0 has two different formats, 368 depending on whether the post-stack header is a pseudowire control 369 word or a DetNet control word; disambiguation requires the context of 370 the service label. This was a considered decision; documenting this 371 would be helpful to future implementors. 373 With a registy, post-stack headers become easier to parse; the values 374 are unique, not needing means outside the data plane to interpret 375 them correctly; and their semantics and usage are documented. (Thank 376 you, IANA!) 378 2.3. Caveat 380 The use of the MPLS First Nibble stemmed from the desire to 381 heuristically identify IP packets for load balancing purposes. It 382 was then discovered that non-IP packets, misidentified as IP when the 383 heuristic failed, were being badly load balanced, leading to 384 [RFC4928]. This situation may confuse some as to relationship 385 between the MPLS First Nibble Registry and the IP Version Numbers 386 registry. These registries are quite different: 388 1. The IP Version Numbers registry's explicit purpose is to track IP 389 version numbers in an IP header. 391 2. The MPLS First Nibble registry's purpose is to track post-stack 392 header types. 394 The only intersection points between the two registries is for values 395 0x4 and 0x6 (for backward compatibility). There is no need to track 396 future IP version number allocations in the MPLS First Nibble 397 registry. 399 3. IANA Considerations 401 3.1. MPLS First Nibble Registry 403 This memo recommends the creation of an IANA registry called "The 404 MPLS First Nibble Registry" with the following values: 406 +=======+========================+===========+===================+ 407 | Value | Meaning | Reference | Allocation Policy | 408 +=======+========================+===========+===================+ 409 | 0x0 | PW Control Word | RFC 4385 | | 410 +-------+------------------------+-----------+-------------------+ 411 | 0x0 | DetNet Control Word | RFC 8964 | | 412 +-------+------------------------+-----------+-------------------+ 413 | 0x1 | PW Assoc Channel | RFC 4385 | | 414 +-------+------------------------+-----------+-------------------+ 415 | 0x2 | Unallocated | | Standards Action | 416 +-------+------------------------+-----------+-------------------+ 417 | 0x3 | Unallocated | | Standards Action | 418 +-------+------------------------+-----------+-------------------+ 419 | 0x4 | IPv4 header | RFC 791 | | 420 +-------+------------------------+-----------+-------------------+ 421 | 0x5 | BIER header | RFC 8296 | | 422 +-------+------------------------+-----------+-------------------+ 423 | 0x6 | IPv6 header | RFC 8200 | | 424 +-------+------------------------+-----------+-------------------+ 425 | 0x7-e | Unallocated | | Standards Action | 426 +-------+------------------------+-----------+-------------------+ 427 | 0xf | Reserved for expansion | | Standards Action | 428 +-------+------------------------+-----------+-------------------+ 430 Table 1: MPLS First Nibble Values 432 3.1.1. Allocation Policy 434 All new values registered here MUST use the Standards Action policy 435 [RFC8126]. 437 4. References 439 4.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 447 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 448 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 449 . 451 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 452 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 453 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 454 February 2006, . 456 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 457 Cost Multipath Treatment in MPLS Networks", BCP 128, 458 RFC 4928, DOI 10.17487/RFC4928, June 2007, 459 . 461 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 462 Regan, J., and S. Amante, "Flow-Aware Transport of 463 Pseudowires over an MPLS Packet Switched Network", 464 RFC 6391, DOI 10.17487/RFC6391, November 2011, 465 . 467 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 468 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 469 RFC 6790, DOI 10.17487/RFC6790, November 2012, 470 . 472 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 473 Writing an IANA Considerations Section in RFCs", BCP 26, 474 RFC 8126, DOI 10.17487/RFC8126, June 2017, 475 . 477 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 478 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 479 May 2017, . 481 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 482 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 483 for Bit Index Explicit Replication (BIER) in MPLS and Non- 484 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 485 2018, . 487 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 488 Use the Ethernet Control Word", RFC 8469, 489 DOI 10.17487/RFC8469, November 2018, 490 . 492 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 493 S., and J. Korhonen, "Deterministic Networking (DetNet) 494 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 495 2021, . 497 4.2. Informative References 499 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 500 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 501 2006, . 503 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 504 Emulation (PWE3)", BCP 116, RFC 4446, 505 DOI 10.17487/RFC4446, April 2006, 506 . 508 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 509 LAN Service (VPLS) Using BGP for Auto-Discovery and 510 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 511 . 513 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 514 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 515 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 516 . 518 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 519 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 520 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 521 2015, . 523 Authors' Addresses 524 Kireeti Kompella (editor) 525 Juniper Networks 526 1133 Innovation Way 527 Sunnyvale, 94089 528 United States of America 529 Phone: +1-408-745-2000 530 Email: kireeti.ietf@gmail.com 532 Stewart Bryant 533 University of Surrey 5GIC 534 Email: sb@stewartbryant.com 536 Matthew Bocci 537 Nokia 538 Email: matthew.bocci@nokia.com 540 Greg Mirsky 541 Ericsson 542 Email: gregimirsky@gmail.com 544 Lars Olaf (Loa) Andersson 545 Bronze Dragon Consulting 546 Email: loa@pi.nu