idnits 2.17.1 draft-bryant-mpls-dev-primer-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 (December 24, 2021) is 826 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-architecture-02 == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-label-stack-operations-02 == Outdated reference: A later version (-01) exists of draft-bryant-mpls-aux-data-pointer-00 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-inband-pm-encapsulation-02 == Outdated reference: A later version (-03) exists of draft-kompella-mpls-mspl4fa-01 == Outdated reference: A later version (-04) exists of draft-kompella-mpls-nffrr-02 == Outdated reference: A later version (-03) exists of draft-li-mpls-enhanced-vpn-vtn-id-01 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-05 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft University of Surrey 4 Intended status: Informational December 24, 2021 5 Expires: June 27, 2022 7 A Primer on the Development of MPLS 8 draft-bryant-mpls-dev-primer-01 10 Abstract 12 There has been significant recent interest in developing MPLS to 13 address new needs. This memo collects together various documents 14 that together describe the key aspects of the MPLS architecture 15 together with the development proposals that the author is aware of. 17 The purpose of this document is to bring everyone up to speed on the 18 rational for the existing design and to alert them to the new 19 proposals. 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 June 27, 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Background Documents . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Multiprotocol Label Switching Architecture (RFC 3031) . . 3 58 2.2. MPLS Label Stack Encoding (RFC 3032) . . . . . . . . . . 4 59 2.3. Control Word for Use over an MPLS PSN (RFC5586) . . . . . 4 60 2.4. Avoiding Equal Cost Multipath (ECMP) Treatment in MPLS 61 Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Synonymous Flow Labels . . . . . . . . . . . . . . . . . 5 63 2.6. Residence Time Measurement in MPLS Networks . . . . . . . 5 64 3. Other Observations Received . . . . . . . . . . . . . . . . . 5 65 4. New Proposals . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. MPLS Extension Header Architecture . . . . . . . . . . . 7 67 4.2. MPLS Label Operations in MPLS EH capable networks . . . . 8 68 4.3. Encapsulation For MPLS Performance Measurement with 69 Alternate Marking . . . . . . . . . . . . . . . . . . . . 8 70 4.4. MPLS Data Plane Encapsulation for In-situ OAM Data . . . 9 71 4.5. Multi-purpose Special Purpose Label for Forwarding 72 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.6. No Further Fast Reroute . . . . . . . . . . . . . . . . . 9 74 4.7. Carrying Virtual Transport Network Identifier in MPLS 75 Packet . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.8. Segment Routed Time Sensitive Networking . . . . . . . . 10 77 4.9. Options for MPLS Extension Header Indicator . . . . . . . 10 78 4.10. MPLS Extension Header . . . . . . . . . . . . . . . . . . 11 79 4.11. MPLS Payload Protocol Identifier . . . . . . . . . . . . 11 80 4.12. Generic Transport Functions . . . . . . . . . . . . . . . 11 81 4.13. Use of an MPLS LSE as an Ancillary Data Pointer . . . . . 12 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 7.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 There has been significant recent interest in developing the MPLS 92 data plane to address new needs. This memo collects together various 93 documents that together describe the key aspects of the MPLS 94 architecture together with the development proposals that the author 95 is aware of. 97 The intent of this work is to bring everyone up to speed on the 98 rational for the existing design and to alert them to the new 99 proposals. If I have missed any proposals, then please accept my 100 apologies for the oversight, let me know and I will include it in the 101 list. 103 I do not anticipate that this memo will progress to become an RFC. 105 The interest in this work to develop MPLS was noted by the Chairs of 106 the DETNET, MPLS, PALS, and SPRING IETF working groups who called a 107 joint meeting at IETF 110. The agenda, slides notes etc of the 108 meeting are currently at https://datatracker.ietf.org/meeting/agenda/ 110 Editor's note the above URL will change when the meeting is included 111 in the IETF Proceedings. 113 A video recording of the meeting is to be found at https://youtu.be/ 114 rt_vQTToO1s 116 2. Background Documents 118 2.1. Multiprotocol Label Switching Architecture (RFC 3031) 120 [RFC3031] describes the base architecture of MPLS. This is updated 121 by: 123 o [RFC6178] which describes label edge router forwarding of IPv4 124 option packets and is not relevant to this discussion. 126 o [RFC6790] which describes the use of entropy labels in MPLS 127 forwarding. The entropy label is a two stack entry tuple that 128 consists of a special purpose label (SPL) followed by a label 129 stack entry (LSE) who's label is pure entropy to be applied to the 130 selection of a path from the Equal Cost Multi-Path (ECMP) set. 131 Its use in choosing the ECMP member is optional. This was the 132 first formal introduction of the concept of an MPLS forwarder 133 needing to parse below the top of the label stack. 135 Prior to the introduction of RFC 6790 it was already common practice 136 for LSRs to scan the label stack to the bottom of stack (a simple 137 task requiring the checking of a single bit in each LSE) to 138 heuristically check that the packet was IP and if so to hash the five 139 tuple to determine the ECMP path to use. 141 This approach worked well until Ethernet addresses were 142 (legitimately) deployed that confused these forwarders into thinking 143 that Ethernet packets were IP packets ((RFC8469}}. 145 2.2. MPLS Label Stack Encoding (RFC 3032) 147 [RFC3032] Specifies the encoding of an MPLS LSE. This has been 148 updated by: 150 o [RFC3443] describes the two models of TTL handling in MPLS. In 151 addition that it should be noted that some LSR decrement the TTL 152 of the TOP label _before_ inspecting the label in the top LSE. 154 o [RFC3270] describes the application of diffserv to MPLS and the 155 pipe vs uniform models. It may apply to this work if we are 156 popping xSPLs. 158 EDITOR'S NOTE need to think about [RFC3270] some more. 160 o [RFC5129] describes Explicit Congestion Marking in MPLS. It is 161 not clear how widely this is deployed. This is something that 162 needs to be thought through when re-purposing the TC bits as has 163 been proposed in some of the drafts listed below. 165 o [RFC5462] renames the EXP field to TC field. This is a naming 166 convention and not a technology change. 168 o [RFC5586] defines the Generic Associated Channel (see later). 170 o [RFC7274] defines the process for allocating and retiring special 171 purpose labels (SPLs) (formerly known as Reserved Labels). It 172 also creates the extended special purpose labels (eSPLs). eSPLs 173 are another instance of a twin label in the stack, with the first 174 label (15) from the SPL range followed by another label that 175 specifies the function of the twin labels. 177 2.3. Control Word for Use over an MPLS PSN (RFC5586) 179 [RFC5586] describes the first use of a type of meta-data between the 180 bottom of the MPLS label stack and the packet payload. The 181 pseudowire (PW) control word (CW) is used to carry additional 182 information that the egress Provider Edge (PE) LSR needs to construct 183 the outgoing packet. It also tells the forwarder that the packet is 184 not an IP packet and so should not be subjected to ECMP. 186 [RFC8469] is an update to the Ethernet PW specification [RFC4448] to 187 strongly encourage the use of the CW for Ethernet PWs. All other PWs 188 that have been defined require the use of the CW. 190 2.4. Avoiding Equal Cost Multipath (ECMP) Treatment in MPLS Network 192 [RFC4928] describes the issue of accidental ECMP of packets not carry 193 IP. This arises because some forwarders accidentally mistake a non- 194 IP packet for an IP packet. They use a heuristic method of 195 determining that the packet is IP. They sometimes get this wrong 196 causing a misordered the delivery of some of the packets. [RFC4928] 197 formally introduces the concept of using the first nibble of 0b0000 198 to avoid this. Note that the technique is actually older than this 199 having been introduced in [RFC4385]. 201 2.5. Synonymous Flow Labels 203 [RFC8957] describes a technique whereby additional labels are 204 introduced to an MPLS network that mimic the behavior of other MPLS 205 labels but also introduce new properties to the FEC. The main use is 206 to trigger OAM actions, but the method can be used to trigger other 207 agreed actions. 209 2.6. Residence Time Measurement in MPLS Networks 211 [RFC8169] describes a method of measuring the dwell or residence time 212 of a packet in a router. The time is accumulated in a G-ACh packet 213 carried below the label stack. Note that the G-ACh uses first nibble 214 = 0b0001. This is the first instance of a G-ACh packet being 215 specified for operation on a user data packet. 217 The data packet is carried over an RSVP-TE path and thus the top of 218 stack label indicates to the forwarder both the next-hop and outgoing 219 label, but also indicates the presence of the G-ACh and the need to 220 perform the residence time accumulation. 222 The RFC predates segment routing (SR) and does not mention Software 223 Defined Networks (SDNS), but the method could be used in those 224 environments. 226 3. Other Observations Received 228 The following comments were received and are included for the benefit 229 of the reader. 231 Some of these comments should probably me moved to a requirements 232 draft. 234 For better of worse, passive taps and splitters are universally 235 deployed for various monitoring purposes, the resulting feed is a 236 direct copy of the traffic on the wire; active monitoring within the 237 network element is equally widely deployed. Neither of these 238 mechanisms have insight into the FEC context. This would imply that 239 the encapsulation is deterministic - i.e. it needs to be possible for 240 the packet to be unambiguously decoded by such a side observer. 242 Filters for monitored traffic also need to be created somehow, this 243 implies that an LSE and the new header wire format needs to be 244 unambiguous in the context that does not have access to endpoints. 246 The amount of state that needs to be distributed across the domain, 247 the rate of such state change and state accumulation points needs to 248 be understood. If information needs to be signaled end to end, what 249 is the impact on the transit nodes and what is the impact of the 250 total state that is kept within a domain. An example is MSD 251 propagation - while it is on the order of a rounding error for an IGP 252 to propagate, a generic realization would require maintaining all of 253 that state for whole domain in every node, and realistically that 254 will be on the order of a few tens of MSD entries per page. While 255 not a problem for platforms with wide address space, 32 bit address 256 space systems are widely deployed and will stay in a foreseeable 257 future - this increase of state is not free in their context. 259 From the practical implementation point of view, there appear to be 260 three large groups 262 o hardware implementations 264 o scalar software 266 o vector software implementations 268 Vector implementations are the fastest growing ones, both by the 269 addressable market and by the performance benefits. However, those 270 benefits can easily be written off if data formats are in direct 271 opposition to vector processing rules. vertical processing within a 272 lane is what vector implementations assume, with reasonably good 273 support for horizontal operations within lanes/ However support for 274 anything that does not align uniformly to all lanes is quite poor. 275 Variable length headers with fields being spread across various lane 276 positions are a bad match for this technology. If it is within a 277 cache line the penalty is still reasonable but quickly approaches the 278 point where the benefits of vector processing are over-shadowed by 279 the additional processing required to get data in the right order. 281 While MPLS-TP and MPLS have the same data plane encapsulation, they 282 do not necessarily make practical use of the same data plane instance 283 - it is a basic network design aspect to separate different classes 284 of traffic in different layers. 286 There are many design issues to look at, but before we go too far 287 with the new proposals we need to understand the practical uses of 288 the technology and the practical limitations of the methods of 289 implementation. 291 EDITOR'S NOTE add in illustration label stacks for major 292 encapsulations - single and multiple label IPv4/IPv6, and packet 293 pseudowires - the encapsulations that make the dominant part of 294 traffic. Something similar to what extended headers document has for 295 showing wire image, but for current encapsulation - to have an 296 illustratory view of which node needs to lookup what and how deep. 298 4. New Proposals 300 This section catalogues new proposals for how metadata is carried and 301 how its presence is indicated to the forwarder. 303 4.1. MPLS Extension Header Architecture 305 [I-D.andersson-mpls-eh-architecture] specifies an architecture for 306 the extension of MPLS to include Extension Headers (EH). The 307 proposal is for the EHs to carry information on in-network services 308 and functions in an MPLS network. The extension headers are carried 309 after the MPLS Label Stack, and the presence of EHs are indicated in 310 the label stack by an Extension Header Indicator (EHI). 312 Proposed use cases are: 314 o In-situ OAM 316 o Network Telemetry and Measurement 318 o Network Security 320 o Segment Routing 322 o Network Programming 324 The draft calls two types of EH: 326 o "hop-by-hop" (HBH) 328 o "End to end" (E2E). 330 The draft proposes to indicate the presence of the EH via the FEC. 331 The ability of a router on the LSP to process a packet correctly is 332 advertised in the routing protocol. 334 4.2. MPLS Label Operations in MPLS EH capable networks 336 [I-D.andersson-mpls-eh-label-stack-operations] provides the operating 337 procedures for EH-capable and non-EH-capable LSRs where MPLS 338 Extension Headers (EH) are carried below the MPLS label stack. 339 Further this describes how MPLS EHs can be gradually introduced into 340 an existing MPLS network. The capability to handle EHs is announced 341 throughout the MPLS network, and LSRs that don't understand this 342 information simply ignore it. 344 The extension headers are carried after the MPLS Label Stack, and the 345 presence of EHs are indicate in the label stack by a Extended Special 346 Purpose label called Extension Header Indicator (EHI) in the label 347 stack. 349 The EH(s) are carried over a G-ACh. Three ACHs are suggested E2E, 350 HBH, Both. A number of EHs can be accommodated with the number being 351 indicated by a parameter in the ACH. 353 The draft considers the stack structure in a number of cases such as 354 VPN (and presumably PW) and non-VPN (native IP payload) cases. 356 The draft shows how RSVP-TE signaling would work. 358 4.3. Encapsulation For MPLS Performance Measurement with Alternate 359 Marking 361 [I-D.ietf-mpls-inband-pm-encapsulation] shows how a flow ID can be 362 carried in a packet. The application is Alternate Marking (AM) for 363 performance monitoring of the network. 365 It proposes the use of an eSPL (two LSEs) preceding a third LSE which 366 the flow ID in its label field. 368 This LSE triplet can occur more than once in the label stack and can 369 occur at any position within the label stack. If it is used for two 370 different purposes in the stack the Flow ID must be different. 372 Where Alternate Marking is used two method of creating the 373 alternating pairs are proposed, using two Flow IDs which will have 374 ECMP implications possibly requiring the including of an entropy 375 label pair, or using the TC bits which may effect queue priority on 376 the egress LSR when the Flow ID is bottom of stack. 378 Considerations of maximum stack depth apply. 380 4.4. MPLS Data Plane Encapsulation for In-situ OAM Data 382 [I-D.gandhi-mpls-ioam-sr] shows how the IOAM data fields defined in 383 [I-D.ietf-ippm-ioam-data] could be carried in MPLS. It carries the 384 OAM data in an G-Ach and specifies both hop-by-hop and end-to-end 385 versions. 387 The OAM present/type indicator is an e(SPL) at the bottom of the MPLS 388 label stack requiring a P-router to scan the stack to find the label. 390 The draft proposes the stacking of G-Ach blocks at the bottom of 391 stack with the IOAM G-Ach first and any subsequent G-Ach located 392 through the use of a length field in the IOAM G-Ach. 394 4.5. Multi-purpose Special Purpose Label for Forwarding Actions 396 [I-D.kompella-mpls-mspl4fa] notes that the forwarder does not need to 397 use the TC, or TTL fields in an LSE that does not become top of 398 stack. It proposes to exploit these fields as indicators of 399 forwarding actions, by modifying the semantics of these fields. 401 There are a number of key proposals in the draft: 403 o Using the "spare bits" as forwarding indicator flags to specify 404 actions or in some cases inactions 406 o Using the method to multi-purpose SPLs and thus expand the number 407 of single label SPLs available to the IETF. 409 o Reusing the Entropy Label fields to carry additional data needed 410 by the forwarder. This latter point could be adopted by any eSPL. 411 One use for this additional data that was proposed (certainly in 412 discussion but I cannot see it in the draft) was the use of this 413 facility to carry a network slice identifier. 415 4.6. No Further Fast Reroute 417 [I-D.kompella-mpls-nffrr] proposes the use of an SPL (note not an 418 eSPL) to indicate that a fast re-route action is not to be undertaken 419 on the packet. 421 Uses an SPL for this single purpose 423 4.7. Carrying Virtual Transport Network Identifier in MPLS Packet 425 [I-D.li-mpls-enhanced-vpn-vtn-id] is a method of carrying a virtual 426 network identifier in an MPLS packet. It does this by carrying meta- 427 data below the MPLS label stack. It does not use the G-ACh but 428 instead a new design with a first nibble value of 0b0011. 430 Note that when we define new first nibbles we are technically taking 431 IP versions away from the IETF Internet Area. When PWE3 first 432 proposed this we agreed with the IETF of the day that we would only 433 take 0b0000 and 0b0001. I am looking to see if this agreement was 434 documented. 436 The presence of the VTN is indicted by an SPL (note not an eSPL) 437 somewhere in the label stack. The draft discusses how multiple VTNs 438 can be placed in the packet, but not how multiple types of meta-data 439 are to be carried. 441 4.8. Segment Routed Time Sensitive Networking 443 [I-D.stein-srtsn] describes how information can be encoded in the 444 MPLS label stack to inform the forwarder when a time sensitive packet 445 should be sent. Each LSE becomes 64 bits, the first 32 bits a 446 conventional MPLS label and the second part contains dispatch time 447 information. 449 Note that as far as I can see there is no provision for an S bit 450 making label stack scanning for other information liable to make a 451 mistake. 453 There is no information that I can see stating how the LSR knows that 454 the LSE is in this format and so I assume that it knows from the FEC. 456 4.9. Options for MPLS Extension Header Indicator 458 [I-D.song-mpls-extension-header] provides a catalogue of methods of 459 identifying the presence of presence of an extension header after the 460 label stack. The methods could of course be used for identifying the 461 presence of some other structure after the label stack. 463 The methods listed are: 465 o A special purpose label 467 o An extended special purpose label pair 469 o A GAL and an associated channel header 471 o A GAL followed by a structure with a different first nibble value 473 o The use of a new FEC 475 4.10. MPLS Extension Header 477 [I-D.song-mpls-extension-header] describes a design for an MPLS 478 extension header to be placed after the MPLS label stack. The Header 479 of Extension Headers (HEH) specifies the number of extension headers 480 that follow. The HEH has the four bit ECMP defeat nibble, a count of 481 number of extension headers, the length of the set of extension 482 headers and the type of the following extension header. An Extension 483 Header (EH) starts with the type of the header that follows this EH, 484 the length of this EH followed by the EH data/payload. 486 Two generic types of EH as specified, End to End and Hop by Hop. 488 4.11. MPLS Payload Protocol Identifier 490 [I-D.xu-mpls-payload-protocol-identifier] describes a method of 491 adding a protocol identifier (PID) to an MPLS packet. 493 A 16 bit PID is carried in a 32 bit structure following the label 494 stack. The structure just has an ECMP defeat nibble 0b000 and the 495 PID. 497 Presence of the PID is indicated by an SPL or an eSPL at the bottom 498 of stack. 500 An alternative method of indicating the PIL is also proposed by using 501 a first nibble of 0b1111. Note that this might be defeated by an 502 MPLS payload other than IP. For reasons discussed in [RFC8469] in 503 this arrangement the PIL could not be used at a mid-point, but would 504 be safe at an endpoint. The first nibble comments in {#VTN} also 505 apply to this proposal. 507 No provision is made for carrying other data beyond the bottom of 508 stack, and there is no discussion on how this works with VPNs and 509 PWs. 511 4.12. Generic Transport Functions 513 [I-D.zzhang-tsvwg-generic-transport-functions] describes a method of 514 adding fragmentation to a number of protocols including MPLS. The 515 fragmentation header follows the end of stack. It does not take any 516 ECMP precautions through the first nibble. Some mitigation could be 517 achieved by the use of the ELI/EL where the P routers can support 518 this. 520 Indication of the fragmentation header is indicated by the FEC. 522 Note that the draft referenced pseudowires (PWs) and that PWs have a 523 fragmentation method [RFC4623]. However this feature is not thought 524 to be widely implemented. 526 4.13. Use of an MPLS LSE as an Ancillary Data Pointer 528 [I-D.bryant-mpls-aux-data-pointer] described how Label Stack Entries 529 (LSEs) can be used to point to ancillary data carried below the MPLS 530 label stack. This allows the stack to explicitly direct the 531 forwarder to specific items of ancillary (meta) data, thereby 532 reducing the ambiguity of the various implicit systems proposed. 533 Thus, as an example it is possible to specify a latency requirement 534 on a path segment rather than requiring the forwarder to determine 535 which of several latency specifations are applicable to it. 537 A difficulty with the pointer approach occurs if the packet is ever 538 expanded, for example as a result of the use of an iOAM incremental 539 trace approach [I-D.ietf-ippm-ioam-data] adapted for MPLS. It is not 540 clear how widely deployed such an approach will be. A mitigation 541 approach is expected to be proposed in he next version of 542 [I-D.bryant-mpls-aux-data-pointer]. 544 5. Security Considerations 546 Any changes to the MPLS security model as a result of a change will 547 need to be considered within the proposals themselves. This document 548 is a catalog of existing RFCs and design proposals and does not 549 itself modify the security of MPLS networks. 551 6. IANA Considerations 553 This document has no IANA requests. 555 7. References 557 7.1. Normative References 559 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 560 Label Switching Architecture", RFC 3031, 561 DOI 10.17487/RFC3031, January 2001, 562 . 564 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 565 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 566 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 567 . 569 7.2. Informative References 571 [I-D.andersson-mpls-eh-architecture] 572 Andersson, L., Guichard, J. N., Song, H., and S. Bryant, 573 "MPLS Extension Header Architecture", draft-andersson- 574 mpls-eh-architecture-02 (work in progress), October 2021. 576 [I-D.andersson-mpls-eh-label-stack-operations] 577 Andersson, L., Guichard, J. N., Song, H., and S. Bryant, 578 "MPLS Label Operations in MPLS EH capable networks", 579 draft-andersson-mpls-eh-label-stack-operations-02 (work in 580 progress), October 2021. 582 [I-D.bryant-mpls-aux-data-pointer] 583 Bryant, S., Clemm, A., and T. Eckert, "Use of an MPLS LSE 584 as an Ancillary Data Pointer", draft-bryant-mpls-aux-data- 585 pointer-00 (work in progress), May 2021. 587 [I-D.gandhi-mpls-ioam-sr] 588 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 589 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 590 OAM Data", draft-gandhi-mpls-ioam-sr-06 (work in 591 progress), February 2021. 593 [I-D.ietf-ippm-ioam-data] 594 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 595 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 596 progress), December 2021. 598 [I-D.ietf-mpls-inband-pm-encapsulation] 599 Cheng, W., Min, X., Zhou, T., Dong, X., and Y. Peleg, 600 "Encapsulation For MPLS Performance Measurement with 601 Alternate Marking Method", draft-ietf-mpls-inband-pm- 602 encapsulation-02 (work in progress), October 2021. 604 [I-D.kompella-mpls-mspl4fa] 605 Kompella, K., Beeram, V. P., Saad, T., and I. Meilik, 606 "Multi-purpose Special Purpose Label for Forwarding 607 Actions", draft-kompella-mpls-mspl4fa-01 (work in 608 progress), July 2021. 610 [I-D.kompella-mpls-nffrr] 611 Kompella, K. and W. Lin, "No Further Fast Reroute", draft- 612 kompella-mpls-nffrr-02 (work in progress), July 2021. 614 [I-D.li-mpls-enhanced-vpn-vtn-id] 615 Li, Z. and J. Dong, "Carrying Virtual Transport Network 616 Identifier in MPLS Packet", draft-li-mpls-enhanced-vpn- 617 vtn-id-01 (work in progress), April 2021. 619 [I-D.song-mpls-extension-header] 620 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 621 "MPLS Extension Header", draft-song-mpls-extension- 622 header-05 (work in progress), July 2021. 624 [I-D.stein-srtsn] 625 Stein, Y. (., "Segment Routed Time Sensitive Networking", 626 draft-stein-srtsn-01 (work in progress), August 2021. 628 [I-D.xu-mpls-payload-protocol-identifier] 629 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 630 Protocol Identifier", draft-xu-mpls-payload-protocol- 631 identifier-09 (work in progress), September 2021. 633 [I-D.zzhang-tsvwg-generic-transport-functions] 634 Zhang, Z., Bonica, R., and K. Kompella, "Generic Transport 635 Functions", draft-zzhang-tsvwg-generic-transport- 636 functions-00 (work in progress), November 2020. 638 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 639 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 640 Protocol Label Switching (MPLS) Support of Differentiated 641 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 642 . 644 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 645 in Multi-Protocol Label Switching (MPLS) Networks", 646 RFC 3443, DOI 10.17487/RFC3443, January 2003, 647 . 649 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 650 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 651 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 652 February 2006, . 654 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 655 "Encapsulation Methods for Transport of Ethernet over MPLS 656 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 657 . 659 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 660 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 661 DOI 10.17487/RFC4623, August 2006, 662 . 664 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 665 Cost Multipath Treatment in MPLS Networks", BCP 128, 666 RFC 4928, DOI 10.17487/RFC4928, June 2007, 667 . 669 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 670 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 671 2008, . 673 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 674 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 675 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 676 2009, . 678 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 679 "MPLS Generic Associated Channel", RFC 5586, 680 DOI 10.17487/RFC5586, June 2009, 681 . 683 [RFC6178] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Label 684 Edge Router Forwarding of IPv4 Option Packets", RFC 6178, 685 DOI 10.17487/RFC6178, March 2011, 686 . 688 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 689 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 690 RFC 6790, DOI 10.17487/RFC6790, November 2012, 691 . 693 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 694 and Retiring Special-Purpose MPLS Labels", RFC 7274, 695 DOI 10.17487/RFC7274, June 2014, 696 . 698 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 699 and A. Vainshtein, "Residence Time Measurement in MPLS 700 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 701 . 703 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 704 Use the Ethernet Control Word", RFC 8469, 705 DOI 10.17487/RFC8469, November 2018, 706 . 708 [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 709 Mirsky, "Synonymous Flow Label Framework", RFC 8957, 710 DOI 10.17487/RFC8957, January 2021, 711 . 713 Author's Address 715 Stewart Bryant 716 University of Surrey 718 Email: sb@stewartbryant.com