idnits 2.17.1 draft-gandhi-mpls-ioam-sr-03.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 (September 13, 2020) is 1320 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-01 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: March 17, 2021 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 September 13, 2020 12 MPLS Data Plane Encapsulation for In-situ OAM Data 13 draft-gandhi-mpls-ioam-sr-03 15 Abstract 17 In-situ Operations, Administration, and Maintenance (IOAM) records 18 operational and telemetry information in the data packet while the 19 packet traverses a path between two nodes in the network. This 20 document defines how IOAM data fields are transported using the MPLS 21 data plane encapsulation, including Segment Routing (SR) with MPLS 22 data plane (SR-MPLS). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 17, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 3. IOAM Data Field Encapsulation in MPLS Header . . . . . . . . 3 63 3.1. Indicator Labels . . . . . . . . . . . . . . . . . . . . 6 64 4. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . . . 6 65 4.1. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . 7 66 5. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . . . 7 67 5.1. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . 8 68 6. Considerations for ECMP . . . . . . . . . . . . . . . . . . . 8 69 7. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Data Packets with SR-MPLS Header . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 In-situ Operations, Administration, and Maintenance (IOAM) records 83 operational and telemetry information within the packet while the 84 packet traverses a particular network domain. The term "in-situ" 85 refers to the fact that the IOAM data fields are added to the data 86 packets rather than being sent within the probe packets specifically 87 dedicated to OAM or Performance Measurement (PM). The IOAM data 88 fields are defined in [I-D.ietf-ippm-ioam-data], and can be used for 89 various use-cases for OAM and PM. The IOAM data fields are further 90 updated in [I-D.ietf-ippm-ioam-direct-export] for direct export use- 91 cases and in [I-D.ietf-ippm-ioam-flags] for Loopback and Active 92 flags. 94 This document defines how IOAM data fields are transported using the 95 MPLS data plane encapsulations, including Segment Routing (SR) with 96 MPLS data plane (SR-MPLS). 98 2. Conventions 100 2.1. Requirement Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119] [RFC8174] 105 when, and only when, they appear in all capitals, as shown here. 107 2.2. Abbreviations 109 Abbreviations used in this document: 111 ECMP Equal Cost Multi-Path 113 IOAM In-situ Operations, Administration, and Maintenance 115 MPLS Multiprotocol Label Switching 117 OAM Operations, Administration, and Maintenance 119 PM Performance Measurement 121 POT Proof-of-Transit 123 PSID Path Segment Identifier 125 SR Segment Routing 127 SR-MPLS Segment Routing with MPLS Data plane 129 3. IOAM Data Field Encapsulation in MPLS Header 131 The IOAM data fields defined in [I-D.ietf-ippm-ioam-data] are used. 132 IOAM data fields are carried in the MPLS header as shown in Figure 1 133 and Figure 2. More than one trace options can be present in the IOAM 134 data fields. The Indicator Label is added at the bottom of the MPLS 135 label stack (S flag set to 1) to indicate the presence of the IOAM 136 data field(s) in the MPLS header. 138 The data packets with IOAM data fields carry only one Indicator Label 139 in the MPLS header. Any intermediate node that adds additional MPLS 140 encapsulation in the MPLS header may further update the IOAM data 141 fields in the header without inserting another Indicator Label. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Extension Label (15) | TC |0| TTL | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | IOAM Indicator Label | TC |1| TTL | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 150 | IOAM-Type | IOAM HDR LEN | RESERVED | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 152 | | O 153 | | A 154 ~ IOAM Option and Data Space ~ M 155 | | | 156 | | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 158 | | 159 | | 160 | Payload + Padding | 161 | | 162 | | 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1: IOAM Encapsulation in MPLS Header 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Extension Label (15) | TC |0| TTL | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | IOAM and Flow Indicator Label | TC |1| TTL | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |0 0 1 0| Flow label | Block Number | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 177 | IOAM-Type | IOAM HDR LEN | RESERVED | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 179 | | O 180 | | A 181 ~ IOAM Option and Data Space ~ M 182 | | | 183 | | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 185 | | 186 | | 187 | Payload + Padding | 188 | | 189 | | 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2: IOAM Encapsulation with Flow Label in MPLS Header 195 IOAM Indicator Label (IIL) and IOAM and Flow Indicator Label (IFIL) 196 used are defined in this document. 198 The fields related to the encapsulation of IOAM data fields in the 199 MPLS header are defined as follows: 201 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 202 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 204 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 205 4-octet units. 207 RESERVED: 8-bit reserved field MUST be set to zero upon transmission 208 and ignored upon receipt. 210 IOAM Option and Data Space: IOAM option header and data is present 211 as defined by the IOAM-Type field, and is defined in Section 4 of 212 [I-D.ietf-ippm-ioam-data]. 214 3.1. Indicator Labels 216 IOAM Indicator Label (value TBA1 or TBA3) and IOAM and Flow Indicator 217 Label (value TBA2 or TBA4) are used to indicate the presence of the 218 IOAM data field in the MPLS header. 220 The IOAM and Flow Indicator Label (value TBA2 or TBA4) is used to 221 carry a second label underneath with protocol value 0010b, 20-bit 222 Flow Label and 8-bit Block Number. 224 o The protocol value 0010b allows to avoid incorrect IP header-based 225 hashing over ECMP paths that uses the value 0x4 (for IPv4) and 226 value 0x6 (for IPv6) [RFC4928]. 228 o The Flow Label identifies the traffic flow that can be used for 229 IOAM purpose, e.g. monitoring a specific traffic flow for latency. 231 o The Block Number can be used to aggregate the IOAM data collected 232 in data plane, e.g. compute measurement metrics for each block of 233 a flow. It is also used to correlate the IOAM data on different 234 nodes. 236 Different Indicator Labels are used for E2E and HbH IOAM to optimize 237 processing on transit nodes and for checking if IOAM data fields need 238 to be processed. If only edge nodes need to process IOAM data then 239 E2E Indicator Label is used so that transit nodes can ignore it. If 240 both edge and transit nodes need to process IOAM data then HbH 241 Indicator Label is used. 243 The SR path computation needs to know the Maximum SID Depth (MSD) 244 that can be imposed at each node/link of a given SR path [RFC8664]. 245 This ensures that the SID stack depth of a computed path does not 246 exceed the number of SIDs the node is capable of imposing. The MSD 247 used for path computation MUST include the Indicator Labels. 249 4. Procedure for Edge-to-Edge IOAM 251 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 252 Option-Type [I-D.ietf-ippm-ioam-data]. This section summarizes the 253 procedure for data encapsulation and decapsulation for Edge-to-Edge 254 IOAM in MPLS header. 256 o The encapsulating node inserts the IOAM Indicator Label or IOAM 257 Flow Indicator Label with Flow Label and one or more IOAM data 258 field(s) in the MPLS header. The procedure to generate the Flow 259 Label is outside the scope of this document. 261 o The decapsulating node "forwards and punts the timestamped copy" 262 of the data packet including IOAM data fields when the node 263 recognizes the IOAM Indicator Label and IOAM Flow Indicator Label. 264 The copy of the data packet is punted to the slow path for OAM 265 processing and is not necessarily punted to the control-plane. 266 The receive timestamp is required by various E2E OAM use-cases. 268 o The decapsulating node processes the IOAM data field(s) using the 269 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 270 IOAM processing may be to export the data fields, send data fields 271 via Telemetry, etc. 273 o The decapsulating node also pops the Indicator Label and the IOAM 274 data fields from the MPLS header. 276 4.1. Edge-to-Edge IOAM Indicator Label Allocation 278 IOAM Indicator Label (value TBA1) and IOAM and Flow Indicator Label 279 (value TBA2) are used to indicate the presence of the E2E IOAM data 280 field in the MPLS header. The E2E IOAM Indicator Label and IOAM and 281 Flow Indicator Label can be allocated using one of the following 282 methods: 284 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 285 Special-Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 287 o Labels allocated by a Controller from the global table of the 288 decapsulating node. The Controller provisions the label on both 289 encapsulating and decapsulating nodes. 291 o Labels allocated by the decapsulating node. The signaling 292 extension for this is outside the scope of this document. 294 5. Procedure for Hop-by-Hop IOAM 296 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM Pre- 297 allocated Trace Option-Type, IOAM Incremental Trace Option-Type and 298 IOAM Proof of Transit (POT) Option-Type [I-D.ietf-ippm-ioam-data]. 299 This section summarizes the procedure for data encapsulation and 300 decapsulation for Hop-by-hop IOAM in MPLS header. 302 o The encapsulating node inserts the IOAM Indicator Label or IOAM 303 Flow Indicator Label with Flow Label and one or more IOAM data 304 field(s) in the MPLS header. The procedure to generate the Flow 305 Label is outside the scope of this document. 307 o The intermediate and decapsulating node enabled with IOAM 308 functions "forwards and punts the timestamped copy" of the data 309 packet including IOAM data fields when the node recognizes the 310 IOAM Indicator Label and IOAM Flow Indicator Label. The copy of 311 the data packet is punted to the slow path for OAM processing and 312 is not necessarily punted to the control-plane. The receive 313 timestamp is required by various hop-by-hop OAM use-cases. 315 o The intermediate and decapsulating node processes the IOAM data 316 field(s) using the procedures defined in 317 [I-D.ietf-ippm-ioam-data]. An example of IOAM processing may be 318 to export the data fields, send data fields via Telemetry, etc. 320 o The decapsulating node pops the Indicator Label and the IOAM data 321 fields from the MPLS header. 323 5.1. Hop-by-Hop IOAM Indicator Label Allocation 325 IOAM Indicator Label (value TBA3) and IOAM and Flow Indicator Label 326 (value TBA4) are used to indicate the presence of the HbH IOAM data 327 field in the MPLS header. The HbH IOAM Indicator Label and IOAM and 328 Flow Indicator Label can be allocated using one of the following 329 methods: 331 o Labels assigned by IANA with value TBA3 and TBA4 from the Extended 332 Special-Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 334 o Labels allocated by a Controller from the network-wide global 335 table. The Controller provisions the labels on all nodes 336 participating in IOAM functions along the data traffic path. 338 6. Considerations for ECMP 340 The encapsulating node needs to make sure the IOAM data field does 341 not start with a well known IP protocol value (e.g. 0x4 for IPv4 and 342 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 343 the IP header. This can be achieved by using the IOAM and Flow 344 Indicator Label (value TBA2 and TBA4) that follows by protocol value 345 0010b. This approach is consistent with utilizing 0000b or 0001b as 346 the first nibble after the MPLS label stack, as described in 347 [RFC4928] [RFC4385]. 349 Note that the hashing function for ECMP that uses the labels from the 350 MPLS header may now include the Indicator Label. 352 When entropy label [RFC6790] is used for hashing function for ECMP, 353 the procedure defined in this document does not alter the hashing 354 function. 356 7. Node Capability 358 The decapsulating node that has to pop the Indicator Label, data 359 fields, and perform the IOAM function may not be capable of 360 supporting it. The encapsulating node needs to know if the 361 decapsulating node can support the IOAM function. The signaling 362 extension for this capability exchange is outside the scope of this 363 document. 365 The intermediate node that is not capable of supporting the IOAM 366 functions defined in this document, can simply skip the IOAM 367 processing of the MPLS header. 369 8. Data Packets with SR-MPLS Header 371 Segment Routing (SR) technology leverages the source routing paradigm 372 [RFC8660]. A node steers a packet through a controlled set of 373 instructions, called segments, by pre-pending the packet with an SR 374 header. In the SR with MPLS data plane (SR-MPLS), the SR header is 375 instantiated through a label stack. 377 An example of data packet carrying the SR-MPLS header with Path 378 Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] with 379 IOAM encapsulation is shown in Figure 3. The Path Segment Identifier 380 allows to identify the path associated with the data traffic being 381 monitored for IOAM on the decapsulating node. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Label(1) | TC |S| TTL | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 . . 389 . . 390 . . 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Label(n) | TC |S| TTL | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | PSID | TC |S| TTL | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Packet as shown in Figure 1 or Figure 2 | 397 . . 398 +---------------------------------------------------------------+ 400 Figure 3: Data Packet with SR-MPLS Header 402 9. Security Considerations 404 The security considerations of SR-MPLS are discussed in [RFC8660], 405 and the security considerations of IOAM in general are discussed in 406 [I-D.ietf-ippm-ioam-data]. 408 IOAM is considered a "per domain" feature, where one or several 409 operators decide on leveraging and configuring IOAM according to 410 their needs. Still, operators need to properly secure the IOAM 411 domain to avoid malicious configuration and use, which could include 412 injecting malicious IOAM packets into a domain. 414 10. IANA Considerations 416 IANA maintains the "Special-Purpose Multiprotocol Label Switching 417 (MPLS) Label Values" registry (see ). IANA is requested to 419 allocate IOAM Indicator Label value and IOAM and Flow Indicator value 420 from the "Extended Special-Purpose MPLS Label Values" registry: 422 +--------+-----------------------------------+---------------+ 423 | Value | Description | Reference | 424 +--------+-----------------------------------+---------------+ 425 | TBA1 | E2E IOAM Indicator Label | This document | 426 +--------+-----------------------------------+---------------+ 427 | TBA2 | E2E IOAM and Flow Indicator Label | This document | 428 +--------+-----------------------------------+---------------+ 429 | TBA3 | HbH IOAM Indicator Label | This document | 430 +--------+-----------------------------------+---------------+ 431 | TBA4 | HbH IOAM and Flow Indicator Label | This document | 432 +--------+-----------------------------------+---------------+ 434 11. References 436 11.1. Normative References 438 [I-D.ietf-ippm-ioam-data] 439 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 440 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 441 progress), July 2020. 443 [I-D.ietf-ippm-ioam-direct-export] 444 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 445 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 446 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 447 export-01 (work in progress), August 2020. 449 [I-D.ietf-ippm-ioam-flags] 450 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 451 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 452 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 453 (work in progress), July 2020. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 462 May 2017, . 464 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 465 Decraene, B., Litkowski, S., and R. Shakir, "Segment 466 Routing with the MPLS Data Plane", RFC 8660, 467 DOI 10.17487/RFC8660, December 2019, 468 . 470 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 471 and J. Hardwick, "Path Computation Element Communication 472 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 473 DOI 10.17487/RFC8664, December 2019, 474 . 476 11.2. Informative References 478 [I-D.ietf-mpls-spl-terminology] 479 Andersson, L., Kompella, K., and A. Farrel, "Special 480 Purpose Label terminology", draft-ietf-mpls-spl- 481 terminology-03 (work in progress), August 2020. 483 [I-D.ietf-spring-mpls-path-segment] 484 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 485 "Path Segment in MPLS Based Segment Routing Network", 486 draft-ietf-spring-mpls-path-segment-02 (work in progress), 487 February 2020. 489 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 490 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 491 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 492 February 2006, . 494 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 495 Cost Multipath Treatment in MPLS Networks", BCP 128, 496 RFC 4928, DOI 10.17487/RFC4928, June 2007, 497 . 499 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 500 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 501 RFC 6790, DOI 10.17487/RFC6790, November 2012, 502 . 504 Acknowledgements 506 The authors would like to thank Patrick Khordoc, Shwetha Bhandari and 507 Vengada Prasad Govindan for the discussions on IOAM. The authors 508 would also like to thank Tarek Saad, Loa Andersson, Greg Mirsky, and 509 Cheng Li for providing many useful comments. 511 Contributors 513 Sagar Soni 514 Cisco Systems, Inc. 516 Email: sagsoni@cisco.com 518 Authors' Addresses 520 Rakesh Gandhi (editor) 521 Cisco Systems, Inc. 522 Canada 524 Email: rgandhi@cisco.com 526 Zafar Ali 527 Cisco Systems, Inc. 529 Email: zali@cisco.com 531 Clarence Filsfils 532 Cisco Systems, Inc. 533 Belgium 535 Email: cf@cisco.com 536 Frank Brockners 537 Cisco Systems, Inc. 538 Hansaallee 249, 3rd Floor 539 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 540 Germany 542 Email: fbrockne@cisco.com 544 Bin Wen 545 Comcast 547 Email: Bin_Wen@cable.comcast.com 549 Voitek Kozak 550 Comcast 552 Email: Voitek_Kozak@comcast.com