idnits 2.17.1 draft-gandhi-mpls-ioam-sr-05.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 (January 09, 2021) is 1203 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-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-03 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 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: July 13, 2021 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 January 09, 2021 12 MPLS Data Plane Encapsulation for In-situ OAM Data 13 draft-gandhi-mpls-ioam-sr-05 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 with MPLS data 21 plane encapsulation using new Generic Associated Channel (G-ACh), 22 including Segment Routing (SR) with MPLS 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 July 13, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 4. Edge-to-Edge IOAM . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Edge-to-Edge IOAM Indicator Label . . . . . . . . . . . . 5 65 4.2. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . 5 66 4.3. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . 6 67 5. Hop-by-Hop IOAM . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Hop-by-Hop IOAM Indicator Label . . . . . . . . . . . . . 6 69 5.2. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . 7 70 5.3. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . 8 71 6. Considerations for IOAM Indicator Label . . . . . . . . . . . 8 72 6.1. Considerations for ECMP . . . . . . . . . . . . . . . . . 8 73 6.2. Node Capability . . . . . . . . . . . . . . . . . . . . . 8 74 6.3. MSD Considerations . . . . . . . . . . . . . . . . . . . 9 75 6.4. Nested MPLS Encapsulation . . . . . . . . . . . . . . . . 9 76 7. SR-MPLS Header with IOAM . . . . . . . . . . . . . . . . . . 9 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 10.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 In-situ Operations, Administration, and Maintenance (IOAM) records 89 operational and telemetry information within the packet while the 90 packet traverses a particular network domain. The term "in-situ" 91 refers to the fact that the IOAM data fields are added to the data 92 packets rather than being sent within the probe packets specifically 93 dedicated to OAM or Performance Measurement (PM). The IOAM data 94 fields are defined in [I-D.ietf-ippm-ioam-data], and can be used for 95 various use-cases for OAM and PM. The IOAM data fields are further 96 updated in [I-D.ietf-ippm-ioam-direct-export] for direct export use- 97 cases and in [I-D.ietf-ippm-ioam-flags] for Loopback and Active 98 flags. 100 This document defines how IOAM data fields are transported with MPLS 101 data plane encapsulations using new Generic Associated Channel 102 (G-ACh), including Segment Routing (SR) with MPLS data plane (SR- 103 MPLS). 105 2. Conventions 107 2.1. Requirement Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] [RFC8174] 112 when, and only when, they appear in all capitals, as shown here. 114 2.2. Abbreviations 116 Abbreviations used in this document: 118 ECMP Equal Cost Multi-Path 120 G-ACh Generic Associated Channel 122 IOAM In-situ Operations, Administration, and Maintenance 124 MPLS Multiprotocol Label Switching 126 OAM Operations, Administration, and Maintenance 128 PM Performance Measurement 130 POT Proof-of-Transit 132 PSID Path Segment Identifier 134 SR Segment Routing 136 SR-MPLS Segment Routing with MPLS Data plane 138 3. IOAM Data Field Encapsulation in MPLS Header 140 The IOAM data fields defined in [I-D.ietf-ippm-ioam-data] are used. 141 IOAM data fields are carried in the MPLS header as shown in Figure 1. 142 More than one trace options can be present in the IOAM data fields. 143 G-ACh [RFC5586] provides a mechanism to transport OAM and other 144 control messages over MPLS data plane. The IOAM G-ACh header 146 [RFC5586] with new IOAM G-ACh type is added immediately after the the 147 MPLS label stack in the MPLS header as shown in Figure 1, before the 148 IOAM data field(s). 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 153 |0 0 0 1|Version| Reserved | IOAM G-ACh | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 155 | Reserved | Block Number | IOAM-OPT-Type |IOAM HDR Length| | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 157 | | O 158 | | A 159 ~ IOAM Option and Data Space ~ M 160 | | | 161 | | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 163 | | 164 | | 165 | Payload + Padding | 166 | | 167 | | 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: IOAM Encapsulation in MPLS Header 173 The fields related to the encapsulation of IOAM data fields in the 174 MPLS header are defined as follows: 176 IP Version Number 0001b: The first four octets are IP Version Field 177 part of a G-ACh header [RFC5586]. 179 Version: The Version field is set to 0, as defined in [RFC4385]. 181 IOAM G-ACh: Generic Associated Channel (G-ACh) Type (value TBA3) for 182 IOAM [RFC5586]. 184 Reserved: Reserved Bits MUST be set to zero upon transmission and 185 ignored upon receipt. 187 Block Number: The Block Number can be used to aggregate the IOAM 188 data collected in data plane, e.g. compute measurement metrics for 189 each block of a flow. It is also used to correlate the IOAM data 190 on different nodes. 192 IOAM-OPT-Type: 8-bit field defining the IOAM Option type, as defined 193 in Section 8.1 of [I-D.ietf-ippm-ioam-data]. 195 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 196 4-octet units. 198 IOAM Option and Data Space: IOAM option header and data is present 199 as defined by the IOAM-OPT-Type field, and is defined in Section 5 200 of [I-D.ietf-ippm-ioam-data]. 202 4. Edge-to-Edge IOAM 204 4.1. Edge-to-Edge IOAM Indicator Label 206 The E2E IOAM Indicator Label is used to indicate the presence of the 207 E2E IOAM data field in the MPLS header as shown in Figure 2. If only 208 edge nodes need to process IOAM data then E2E IOAM Indicator Label is 209 used so that transit nodes can ignore it. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Label(1) | TC |S| TTL | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 . . 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Label(n) | TC |S| TTL | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Extension Label (15) | TC |S| TTL | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | E2E IOAM Indicator Label | TC |1| TTL | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Packet as shown in Figure 1 | 225 . . 226 +---------------------------------------------------------------+ 228 Figure 2: E2E IOAM Encapsulation in MPLS Header 230 4.2. Procedure for Edge-to-Edge IOAM 232 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 233 Option-Type [I-D.ietf-ippm-ioam-data]. This section summarizes the 234 procedure for data encapsulation and decapsulation for Edge-to-Edge 235 IOAM in MPLS header. 237 o The encapsulating node inserts the E2E IOAM Indicator Label and 238 one or more IOAM data field(s) in the MPLS header. 240 o The decapsulating node "punts the timestamped copy" of the 241 received data packet as is including IOAM data fields when the 242 node recognizes the IOAM Indicator Label. It is punted with 243 receive timestamp to the slow path for IOAM processing. The 244 receive timestamp is required by various E2E OAM use-cases, 245 including streaming telemetry. Note that it is not necessarily 246 punted to the control-plane. 248 o The decapsulating node processes the IOAM data field(s) using the 249 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 250 IOAM processing is to export the data fields, send data fields via 251 streaming telemetry, etc. 253 o The decapsulating node also pops the IOAM Indicator Label and the 254 IOAM data fields from received packet. A copy of the decapsulated 255 data packet is forwarded downstream or terminated locally similar 256 to the regular data packets. 258 4.3. Edge-to-Edge IOAM Indicator Label Allocation 260 The E2E IOAM Indicator Label is used to indicate the presence of the 261 E2E IOAM data field in the MPLS header. The E2E IOAM Indicator Label 262 can be allocated using one of the following methods: 264 o Label assigned by IANA with value TBA1 from the Extended Special- 265 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 267 o Label allocated by a Controller from the global table of the 268 decapsulating node. The Controller provisions the label on both 269 encapsulating and decapsulating nodes. 271 o Label allocated by the decapsulating node and signalled or 272 advertised in the network. The signaling and/or advertisement 273 extension for this is outside the scope of this document. 275 5. Hop-by-Hop IOAM 277 5.1. Hop-by-Hop IOAM Indicator Label 279 The HbH IOAM Indicator Label is used to indicate the presence of the 280 HbH IOAM data field in the MPLS header as shown in Figure 3. 282 Different IOAM Indicator Labels are used for E2E and HbH IOAM to 283 optimize processing on transit nodes and for checking if IOAM data 284 fields need to be processed on transit nodes. If only edge nodes 285 need to process IOAM data then E2E IOAM Indicator Label is used so 286 that transit nodes can ignore it. If both edge and transit nodes 287 need to process IOAM data then HbH IOAM Indicator Label is used. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Label(1) | TC |S| TTL | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 . . 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Label(n) | TC |S| TTL | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Extension Label (15) | TC |S| TTL | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | HbH IOAM Indicator Label | TC |1| TTL | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Packet as shown in Figure 1 | 303 . . 304 +---------------------------------------------------------------+ 306 Figure 3: HbH IOAM Encapsulation in MPLS Header 308 5.2. Procedure for Hop-by-Hop IOAM 310 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM Pre- 311 allocated Trace Option-Type, IOAM Incremental Trace Option-Type and 312 IOAM Proof of Transit (POT) Option-Type [I-D.ietf-ippm-ioam-data]. 313 This section summarizes the procedure for data encapsulation and 314 decapsulation for Hop-by-hop IOAM in MPLS header. 316 o The encapsulating node inserts the HbH IOAM Indicator Label and 317 one or more IOAM data field(s) in the MPLS header. 319 o The intermediate node enabled with HbH IOAM functions processes 320 the data packet including IOAM data fields as defined in 321 [I-D.ietf-ippm-ioam-data] when the node recognizes the HbH IOAM 322 Indicator Label present in the MPLS header. The intermediate node 323 may 'punt the timestamped copy' of the received data packet 324 including the IOAM data fields as required by the IOAM data field 325 processing. It is punted with receive timestamp to the slow path 326 for IOAM processing. 328 o The intermediate node forwards a copy of the processsed data 329 packet downstream. 331 o The decapsulating node "punts the timestamped copy" of the 332 received data packet as is including IOAM data fields when the 333 node recognizes the IOAM Indicator Label. It is punted with 334 receive timestamp to the slow path for IOAM processing. The 335 receive timestamp is required by various E2E OAM use-cases, 336 including streaming telemetry. Note that it is not necessarily 337 punted to the control-plane. 339 o The decapsulating node processes the IOAM data field(s) using the 340 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 341 IOAM processing is to export the data fields, send data fields via 342 streaming telemetry, etc. 344 o The decapsulating node also pops the IOAM Indicator Label and the 345 IOAM data fields from received packet. A copy of the decapsulated 346 data packet is forwarded downstream or terminated locally similar 347 to the regular data packets. 349 5.3. Hop-by-Hop IOAM Indicator Label Allocation 351 The HbH IOAM Indicator Label is used to indicate the presence of the 352 HbH IOAM data field in the MPLS header. The HbH IOAM Indicator Label 353 can be allocated using one of the following methods: 355 o Label assigned by IANA with value TBA2 from the Extended Special- 356 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 358 o Label allocated by a Controller from the network-wide global 359 table. The Controller provisions the labels on all nodes 360 participating in IOAM functions along the data traffic path. 362 6. Considerations for IOAM Indicator Label 364 6.1. Considerations for ECMP 366 The encapsulating node needs to make sure the IOAM data field does 367 not start with a well known IP Version Number (e.g. 0x4 for IPv4 and 368 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 369 the IP header. This is achieved by using the IOAM G-ACh with IP 370 Version Number 0001b after the MPLS label stack [RFC5586]. 372 Note that the hashing function for ECMP that uses the labels from the 373 MPLS header may now include the IOAM Indicator Label. 375 When entropy label [RFC6790] is used for hashing function for ECMP, 376 the procedure defined in this document does not alter the hashing 377 function. 379 6.2. Node Capability 381 The decapsulating node that has to pop the IOAM Indicator Label, data 382 fields, and perform the IOAM function may not be capable of 383 supporting it. The encapsulating node needs to know if the 384 decapsulating node can support the IOAM function. The signaling 385 extension for this capability exchange is outside the scope of this 386 document. 388 The intermediate node that is not capable of supporting the IOAM 389 functions defined in this document, can simply skip the IOAM 390 processing of the MPLS header. 392 6.3. MSD Considerations 394 The SR path computation needs to know the Maximum SID Depth (MSD) 395 that can be imposed at each node/link of a given SR path [RFC8664]. 396 This ensures that the SID stack depth of a computed path does not 397 exceed the number of SIDs the node is capable of imposing. The MSD 398 used for path computation MUST include the IOAM Indicator Label. 400 6.4. Nested MPLS Encapsulation 402 The data packets with IOAM data fields carry only one IOAM Indicator 403 Label in the MPLS header. Any intermediate node that adds additional 404 MPLS encapsulation in the MPLS header may further update the IOAM 405 data fields in the header without inserting another IOAM Indicator 406 Label. 408 7. SR-MPLS Header with IOAM 410 Segment Routing (SR) technology leverages the source routing paradigm 411 [RFC8660]. A node steers a packet through a controlled set of 412 instructions, called segments, by pre-pending the packet with an SR 413 header. In the SR with MPLS data plane (SR-MPLS), the SR header is 414 instantiated through a label stack. 416 An example of data packet carrying the SR-MPLS header with Path 417 Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] and E2E 418 IOAM encapsulation is shown in Figure 4. The Path Segment Identifier 419 allows to identify the path associated with the data traffic being 420 monitored for IOAM on the decapsulating node. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Label(1) | TC |S| TTL | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 . . 428 . . 429 . . 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Label(n) | TC |S| TTL | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | PSID | TC |S| TTL | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Extension Label (15) | TC |S| TTL | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | E2E IOAM Indicator Label | TC |1| TTL | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Packet as shown in Figure 1 | 440 . . 441 +---------------------------------------------------------------+ 443 Figure 4: Example SR-MPLS Header with E2E IOAM 445 8. Security Considerations 447 The security considerations of SR-MPLS are discussed in [RFC8660], 448 and the security considerations of IOAM in general are discussed in 449 [I-D.ietf-ippm-ioam-data]. 451 IOAM is considered a "per domain" feature, where one or several 452 operators decide on leveraging and configuring IOAM according to 453 their needs. Still, operators need to properly secure the IOAM 454 domain to avoid malicious configuration and use, which could include 455 injecting malicious IOAM packets into a domain. 457 Routers that support G-ACh are subject to the same security 458 considerations as defined in [RFC4385] and [RFC5586]. 460 9. IANA Considerations 462 IANA maintains the "Special-Purpose Multiprotocol Label Switching 463 (MPLS) Label Values" registry (see ). IANA is requested to 465 allocate IOAM Indicator Label value from the "Extended Special- 466 Purpose MPLS Label Values" registry: 468 +--------+--------------------------+---------------+ 469 | Value | Description | Reference | 470 +--------+--------------------------+---------------+ 471 | TBA1 | E2E IOAM Indicator Label | This document | 472 +--------+--------------------------+---------------+ 473 | TBA2 | HbH IOAM Indicator Label | This document | 474 +--------+--------------------------+---------------+ 476 IANA maintains G-ACh Type Registry (see 477 ). IANA is requested to allocate a value for IOAM 479 G-ACh Type from "MPLS Generalized Associated Channel (G-ACh) Types 480 (including Pseudowire Associated Channel Types)" registry. 482 +-------+-----------------+---------------+ 483 | Value | Description | Reference | 484 +-------+-----------------+---------------+ 485 | TBA3 | IOAM G-ACh Type | This document | 486 +-------+-----------------+---------------+ 488 Table 1: IOAM G-ACh Type 490 10. References 492 10.1. Normative References 494 [I-D.ietf-ippm-ioam-data] 495 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 496 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 497 progress), November 2020. 499 [I-D.ietf-ippm-ioam-direct-export] 500 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 501 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 502 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 503 export-02 (work in progress), November 2020. 505 [I-D.ietf-ippm-ioam-flags] 506 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 507 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 508 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 509 (work in progress), October 2020. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 517 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 518 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 519 February 2006, . 521 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 522 "MPLS Generic Associated Channel", RFC 5586, 523 DOI 10.17487/RFC5586, June 2009, 524 . 526 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 527 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 528 May 2017, . 530 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 531 Decraene, B., Litkowski, S., and R. Shakir, "Segment 532 Routing with the MPLS Data Plane", RFC 8660, 533 DOI 10.17487/RFC8660, December 2019, 534 . 536 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 537 and J. Hardwick, "Path Computation Element Communication 538 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 539 DOI 10.17487/RFC8664, December 2019, 540 . 542 10.2. Informative References 544 [I-D.ietf-mpls-spl-terminology] 545 Andersson, L., Kompella, K., and A. Farrel, "Special 546 Purpose Label terminology", draft-ietf-mpls-spl- 547 terminology-05 (work in progress), November 2020. 549 [I-D.ietf-spring-mpls-path-segment] 550 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 551 "Path Segment in MPLS Based Segment Routing Network", 552 draft-ietf-spring-mpls-path-segment-03 (work in progress), 553 September 2020. 555 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 556 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 557 RFC 6790, DOI 10.17487/RFC6790, November 2012, 558 . 560 Acknowledgements 562 The authors would like to thank Patrick Khordoc, Shwetha Bhandari and 563 Vengada Prasad Govindan for the discussions on IOAM. The authors 564 would also like to thank Tarek Saad, Loa Andersson, Greg Mirsky, 565 Stewart Bryant, and Cheng Li for providing many useful comments. The 566 authors would also like to thank Mach Chen, Andrew Malis, Matthew 567 Bocci, and Nick Delregno for the MPLS-RT reviews. 569 Contributors 571 Sagar Soni 572 Cisco Systems, Inc. 574 Email: sagsoni@cisco.com 576 Authors' Addresses 578 Rakesh Gandhi (editor) 579 Cisco Systems, Inc. 580 Canada 582 Email: rgandhi@cisco.com 584 Zafar Ali 585 Cisco Systems, Inc. 587 Email: zali@cisco.com 589 Clarence Filsfils 590 Cisco Systems, Inc. 591 Belgium 593 Email: cf@cisco.com 595 Frank Brockners 596 Cisco Systems, Inc. 597 Hansaallee 249, 3rd Floor 598 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 599 Germany 601 Email: fbrockne@cisco.com 602 Bin Wen 603 Comcast 605 Email: Bin_Wen@cable.comcast.com 607 Voitek Kozak 608 Comcast 610 Email: Voitek_Kozak@comcast.com