idnits 2.17.1 draft-gandhi-mpls-ioam-sr-04.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 (November 25, 2020) is 1220 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: May 29, 2021 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 November 25, 2020 12 MPLS Data Plane Encapsulation for In-situ OAM Data 13 draft-gandhi-mpls-ioam-sr-04 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 May 29, 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. IOAM Indicator Labels . . . . . . . . . . . . . . . . . . 5 64 4. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . . . 5 65 4.1. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . 6 66 5. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . . . 6 67 5.1. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . 7 68 6. Considerations for ECMP . . . . . . . . . . . . . . . . . . . 7 69 7. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Data Packets with SR-MPLS Header . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 More than one trace options can be present in the IOAM data fields. 134 The IOAM Indicator Label is added at the bottom of the MPLS label 135 stack (S flag set to 1) and it indicates the presence of the IOAM 136 data field(s) in the MPLS header. 138 The data packets with IOAM data fields carry only one IOAM Indicator 139 Label in the MPLS header. Any intermediate node that adds additional 140 MPLS encapsulation in the MPLS header may further update the IOAM 141 data fields in the header without inserting another IOAM Indicator 142 Label. 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 | Extension Label (15) | TC |0| TTL | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | IOAM Indicator Label | TC |1| TTL | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 151 |0 0 1 0|R|R|R|R| Block Number | IOAM-OPT-Type |IOAM HDR Length| | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 153 | | O 154 | | A 155 ~ IOAM Option and Data Space ~ M 156 | | | 157 | | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 159 | | 160 | | 161 | Payload + Padding | 162 | | 163 | | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: IOAM Encapsulation in MPLS Header 169 IOAM Indicator Label (IIL) (Edge-to-Edge or Hob-By-Hop) as defined in 170 this document. 172 The fields related to the encapsulation of IOAM data fields in the 173 MPLS header are defined as follows: 175 IP Version Number 0010b: The IP Version Number Field 0010b allows to 176 avoid incorrect IP header-based hashing over ECMP paths that uses 177 the value 0x4 (for IPv4) and value 0x6 (for IPv6) [RFC4928]. 179 Block Number: The Block Number can be used to aggregate the IOAM 180 data collected in data plane, e.g. compute measurement metrics for 181 each block of a flow. It is also used to correlate the IOAM data 182 on different nodes. 184 R Bits: Reserved Bits MUST be set to zero upon transmission and 185 ignored upon receipt. 187 IOAM-OPT-Type: 8-bit field defining the IOAM Option type, as defined 188 in Section 8.1 of [I-D.ietf-ippm-ioam-data]. 190 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 191 4-octet units. 193 IOAM Option and Data Space: IOAM option header and data is present 194 as defined by the IOAM-OPT-Type field, and is defined in Section 5 195 of [I-D.ietf-ippm-ioam-data]. 197 3.1. IOAM Indicator Labels 199 IOAM Indicator Label is used to indicate the presence of the IOAM 200 data field in the MPLS header. 202 Different IOAM Indicator Labels are used for E2E and HbH IOAM to 203 optimize processing on transit nodes and for checking if IOAM data 204 fields need to be processed. If only edge nodes need to process IOAM 205 data then E2E IOAM Indicator Label is used so that transit nodes can 206 ignore it. If both edge and transit nodes need to process IOAM data 207 then HbH IOAM Indicator Label is used. 209 The SR path computation needs to know the Maximum SID Depth (MSD) 210 that can be imposed at each node/link of a given SR path [RFC8664]. 211 This ensures that the SID stack depth of a computed path does not 212 exceed the number of SIDs the node is capable of imposing. The MSD 213 used for path computation MUST include the IOAM Indicator Label. 215 4. Procedure for Edge-to-Edge IOAM 217 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 218 Option-Type [I-D.ietf-ippm-ioam-data]. This section summarizes the 219 procedure for data encapsulation and decapsulation for Edge-to-Edge 220 IOAM in MPLS header. 222 o The encapsulating node inserts the E2E IOAM Indicator Label and 223 one or more IOAM data field(s) in the MPLS header. 225 o The decapsulating node "forwards and punts the timestamped copy" 226 of the data packet including IOAM data fields when the node 227 recognizes the E2E IOAM Indicator Label. The copy of the data 228 packet is punted to the slow path for OAM processing and is not 229 necessarily punted to the control-plane. The receive timestamp is 230 required by various E2E OAM use-cases. 232 o The decapsulating node processes the IOAM data field(s) using the 233 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 234 IOAM processing may be to export the data fields, send data fields 235 via Telemetry, etc. 237 o The decapsulating node also pops the E2E IOAM Indicator Label and 238 the IOAM data fields from the MPLS header. 240 4.1. Edge-to-Edge IOAM Indicator Label Allocation 242 E2E IOAM Indicator Label is used to indicate the presence of the E2E 243 IOAM data field in the MPLS header. The E2E IOAM Indicator Label can 244 be allocated using one of the following methods: 246 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 247 Special-Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 249 o Labels allocated by a Controller from the global table of the 250 decapsulating node. The Controller provisions the label on both 251 encapsulating and decapsulating nodes. 253 o Labels allocated by the decapsulating node and signalled or 254 advertised in the network. The signaling and/or advertisement 255 extension for this is outside the scope of this document. 257 5. Procedure for Hop-by-Hop IOAM 259 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM Pre- 260 allocated Trace Option-Type, IOAM Incremental Trace Option-Type and 261 IOAM Proof of Transit (POT) Option-Type [I-D.ietf-ippm-ioam-data]. 262 This section summarizes the procedure for data encapsulation and 263 decapsulation for Hop-by-hop IOAM in MPLS header. 265 o The encapsulating node inserts the HbH IOAM Indicator Label and 266 one or more IOAM data field(s) in the MPLS header. 268 o The intermediate and decapsulating node enabled with IOAM 269 functions "forwards and punts the timestamped copy" of the data 270 packet including IOAM data fields when the node recognizes the HbH 271 IOAM Indicator Label. The copy of the data packet is punted to 272 the slow path for OAM processing and is not necessarily punted to 273 the control-plane. The receive timestamp is required by various 274 hop-by-hop OAM use-cases. 276 o The intermediate and decapsulating node processes the IOAM data 277 field(s) using the procedures defined in 278 [I-D.ietf-ippm-ioam-data]. An example of IOAM processing may be 279 to export the data fields, send data fields via Telemetry, etc. 281 o The decapsulating node pops the HbH IOAM Indicator Label and the 282 IOAM data fields from the MPLS header. 284 5.1. Hop-by-Hop IOAM Indicator Label Allocation 286 HbH IOAM Indicator Label is used to indicate the presence of the HbH 287 IOAM data field in the MPLS header. The HbH IOAM Indicator Label can 288 be allocated using one of the following methods: 290 o Labels assigned by IANA with value TBA2 from the Extended Special- 291 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 293 o Labels allocated by a Controller from the network-wide global 294 table. The Controller provisions the labels on all nodes 295 participating in IOAM functions along the data traffic path. 297 6. Considerations for ECMP 299 The encapsulating node needs to make sure the IOAM data field does 300 not start with a well known IP Version Number (e.g. 0x4 for IPv4 and 301 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 302 the IP header. This is achieved by using the IOAM Indicator Label 303 that followed by IP Version Number 0010b. This approach is 304 consistent with utilizing 0000b or 0001b as the first nibble for IP 305 Version Number after the MPLS label stack, as described in [RFC4928] 306 [RFC4385]. 308 Note that the hashing function for ECMP that uses the labels from the 309 MPLS header may now include the IOAM Indicator Label. 311 When entropy label [RFC6790] is used for hashing function for ECMP, 312 the procedure defined in this document does not alter the hashing 313 function. 315 7. Node Capability 317 The decapsulating node that has to pop the IOAM Indicator Label, data 318 fields, and perform the IOAM function may not be capable of 319 supporting it. The encapsulating node needs to know if the 320 decapsulating node can support the IOAM function. The signaling 321 extension for this capability exchange is outside the scope of this 322 document. 324 The intermediate node that is not capable of supporting the IOAM 325 functions defined in this document, can simply skip the IOAM 326 processing of the MPLS header. 328 8. Data Packets with SR-MPLS Header 330 Segment Routing (SR) technology leverages the source routing paradigm 331 [RFC8660]. A node steers a packet through a controlled set of 332 instructions, called segments, by pre-pending the packet with an SR 333 header. In the SR with MPLS data plane (SR-MPLS), the SR header is 334 instantiated through a label stack. 336 An example of data packet carrying the SR-MPLS header with Path 337 Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] with 338 IOAM encapsulation is shown in Figure 2. The Path Segment Identifier 339 allows to identify the path associated with the data traffic being 340 monitored for IOAM on the decapsulating node. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Label(1) | TC |S| TTL | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 . . 348 . . 349 . . 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Label(n) | TC |S| TTL | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | PSID | TC |S| TTL | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Packet as shown in Figure 1 | 356 . . 357 +---------------------------------------------------------------+ 359 Figure 2: Data Packet with SR-MPLS Header 361 9. Security Considerations 363 The security considerations of SR-MPLS are discussed in [RFC8660], 364 and the security considerations of IOAM in general are discussed in 365 [I-D.ietf-ippm-ioam-data]. 367 IOAM is considered a "per domain" feature, where one or several 368 operators decide on leveraging and configuring IOAM according to 369 their needs. Still, operators need to properly secure the IOAM 370 domain to avoid malicious configuration and use, which could include 371 injecting malicious IOAM packets into a domain. 373 10. IANA Considerations 375 IANA maintains the "Special-Purpose Multiprotocol Label Switching 376 (MPLS) Label Values" registry (see ). IANA is requested to 378 allocate IOAM Indicator Label value from the "Extended Special- 379 Purpose MPLS Label Values" registry: 381 +--------+--------------------------+---------------+ 382 | Value | Description | Reference | 383 +--------+--------------------------+---------------+ 384 | TBA1 | E2E IOAM Indicator Label | This document | 385 +--------+--------------------------+---------------+ 386 | TBA2 | HbH IOAM Indicator Label | This document | 387 +--------+--------------------------+---------------+ 389 IANA maintains IP Version Number Registry (see 390 ). IANA is requested to allocate IP Version Number 0010b 392 for IOAM Data-type from "IP Version Numbers" registry. 394 11. References 396 11.1. Normative References 398 [I-D.ietf-ippm-ioam-data] 399 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 400 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 401 progress), November 2020. 403 [I-D.ietf-ippm-ioam-direct-export] 404 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 405 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 406 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 407 export-02 (work in progress), November 2020. 409 [I-D.ietf-ippm-ioam-flags] 410 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 411 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 412 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 413 (work in progress), October 2020. 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, 417 DOI 10.17487/RFC2119, March 1997, 418 . 420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 421 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 422 May 2017, . 424 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 425 Decraene, B., Litkowski, S., and R. Shakir, "Segment 426 Routing with the MPLS Data Plane", RFC 8660, 427 DOI 10.17487/RFC8660, December 2019, 428 . 430 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 431 and J. Hardwick, "Path Computation Element Communication 432 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 433 DOI 10.17487/RFC8664, December 2019, 434 . 436 11.2. Informative References 438 [I-D.ietf-mpls-spl-terminology] 439 Andersson, L., Kompella, K., and A. Farrel, "Special 440 Purpose Label terminology", draft-ietf-mpls-spl- 441 terminology-05 (work in progress), November 2020. 443 [I-D.ietf-spring-mpls-path-segment] 444 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 445 "Path Segment in MPLS Based Segment Routing Network", 446 draft-ietf-spring-mpls-path-segment-03 (work in progress), 447 September 2020. 449 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 450 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 451 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 452 February 2006, . 454 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 455 Cost Multipath Treatment in MPLS Networks", BCP 128, 456 RFC 4928, DOI 10.17487/RFC4928, June 2007, 457 . 459 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 460 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 461 RFC 6790, DOI 10.17487/RFC6790, November 2012, 462 . 464 Acknowledgements 466 The authors would like to thank Patrick Khordoc, Shwetha Bhandari and 467 Vengada Prasad Govindan for the discussions on IOAM. The authors 468 would also like to thank Tarek Saad, Loa Andersson, Greg Mirsky, and 469 Cheng Li for providing many useful comments. 471 Contributors 473 Sagar Soni 474 Cisco Systems, Inc. 476 Email: sagsoni@cisco.com 478 Authors' Addresses 480 Rakesh Gandhi (editor) 481 Cisco Systems, Inc. 482 Canada 484 Email: rgandhi@cisco.com 486 Zafar Ali 487 Cisco Systems, Inc. 489 Email: zali@cisco.com 491 Clarence Filsfils 492 Cisco Systems, Inc. 493 Belgium 495 Email: cf@cisco.com 497 Frank Brockners 498 Cisco Systems, Inc. 499 Hansaallee 249, 3rd Floor 500 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 501 Germany 503 Email: fbrockne@cisco.com 504 Bin Wen 505 Comcast 507 Email: Bin_Wen@cable.comcast.com 509 Voitek Kozak 510 Comcast 512 Email: Voitek_Kozak@comcast.com