idnits 2.17.1 draft-gandhi-spring-ioam-sr-mpls-02.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 (August 22, 2019) is 1707 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: February 23, 2020 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 August 22, 2019 12 Segment Routing with MPLS Data Plane Encapsulation 13 for In-situ OAM Data 14 draft-gandhi-spring-ioam-sr-mpls-02 16 Abstract 18 In-situ Operations, Administration, and Maintenance (IOAM) records 19 operational and telemetry information in the data packet while the 20 packet traverses a path between two nodes in the network. Segment 21 Routing (SR) technology leverages the source routing paradigm. This 22 document defines how IOAM data fields are transported with the 23 Segment Routing with MPLS data plane (SR-MPLS) encapsulation. The 24 procedures defined are also equally applicable to all other MPLS data 25 plane encapsulations. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 63 3. IOAM Data Field Encapsulation in SR-MPLS Header . . . . . . . 3 64 4. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . . . 5 65 4.1. Edge-to-Edge IOAM Indicator Labels . . . . . . . . . . . . 6 66 5. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . . . 7 67 6. Considerations for ECMP . . . . . . . . . . . . . . . . . . . 7 68 7. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 11.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 In-situ Operations, Administration, and Maintenance (IOAM) records 81 operational and telemetry information within the packet while the 82 packet traverses a particular network domain. The term "in-situ" 83 refers to the fact that the IOAM data fields are added to the data 84 packets rather than being sent within the probe packets specifically 85 dedicated to OAM or Performance Measurement (PM). The IOAM data 86 fields are defined in [I-D.ietf-ippm-ioam-data], and can be used for 87 various use-cases for OAM and PM. 89 Segment Routing (SR) technology leverages the source routing paradigm 90 [I-D.ietf-spring-segment-routing-mpls]. A node steers a packet 91 through a controlled set of instructions, called segments, by 92 pre-pending the packet with an SR header. In the MPLS data plane, 93 the SR header is instantiated through a label stack. 95 This document defines how IOAM data fields are transported with the 96 SR with MPLS data plane (SR-MPLS) encapsulation. The procedures 97 defined are also equally applicable to all other MPLS data plane 98 encapsulations. 100 2. Conventions 102 2.1. Requirement Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119] [RFC8174] 107 when, and only when, they appear in all capitals, as shown here. 109 2.2. Abbreviations 111 Abbreviations used in this document: 113 ECMP Equal Cost Multi-Path 115 IOAM In-situ Operations, Administration, and Maintenance 117 MPLS Multiprotocol Label Switching 119 OAM Operations, Administration, and Maintenance 121 PBT Postcard Based Telemetry 123 PM Performance Measurement 125 PoT Proof-of-Transit 127 SR Segment Routing 129 SR-MPLS Segment Routing with MPLS Data plane 131 3. IOAM Data Field Encapsulation in SR-MPLS Header 133 SR-MPLS encapsulation is defined in 134 [I-D.ietf-spring-segment-routing-mpls]. The IOAM data fields are 135 defined in [I-D.ietf-ippm-ioam-data]. IOAM data fields are carried 136 in the SR-MPLS header as shown in Figure 1 and Figure 2. More than 137 one trace options can be present in the IOAM data fields. The 138 Indicator Label is added at the bottom of the MPLS label stack (S 139 flag set to 1) to indicate the presence of the IOAM data field(s) in 140 the MPLS header. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | IOAM Indicator Label TBA1 | TC |1| TTL | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 147 | IOAM-Type | IOAM HDR LEN | RESERVED | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 149 | | O 150 | | A 151 ~ IOAM Option and Data Space ~ M 152 | | | 153 | | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 155 | | 156 | | 157 | Payload + Padding (L2/L3/ESP/...) | 158 | | 159 | | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: IOAM data encapsulation in SR-MPLS Header 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | IOAM and Flow Indicator Label TBA2 | TC |1| TTL | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |0 0 0 0| Flow label | RESERVED | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 172 | IOAM-Type | IOAM HDR LEN | RESERVED | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 174 | | O 175 | | A 176 ~ IOAM Option and Data Space ~ M 177 | | | 178 | | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 180 | | 181 | | 182 | Payload + Padding (L2/L3/ESP/...) | 183 | | 184 | | 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: IOAM data encapsulation with Flow Label in SR-MPLS Header 190 Indicator Label and Flow Label as defined in this document. 192 The fields related to the encapsulation of IOAM data fields in the 193 SR-MPLS header are defined as follows: 195 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 196 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 198 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 199 4-octet units. 201 RESERVED: 8-bit reserved field MUST be set to zero upon 202 transmission and ignored upon receipt. 204 IOAM Option and Data Space: IOAM option header and data is present 205 as defined by the IOAM-Type field, and is defined in Section 4 of 206 [I-D.ietf-ippm-ioam-data]. 208 4. Procedure for Edge-to-Edge IOAM 210 This section summarizes the procedure for data encapsulation and 211 decapsulation for IOAM Edge-to-Edge Option Type 212 [I-D.ietf-ippm-ioam-data] in SR-MPLS header. 214 o The encapsulating node inserts the IOAM Indicator Label or IOAM 215 Flow Indicator Label with Flow Label and one or more IOAM data 216 field(s) in the MPLS header. The procedure to generate the Flow 217 Label is outside the scope of this document. 219 o The decapsulating node "forwards and punts the timestamped copy" 220 of the data packet including IOAM data fields when the node 221 recognizes the IOAM Indicator Label and IOAM Flow Indicator Label. 222 The copy of the data packet is punted to the slow path for OAM 223 processing and is not necessarily punted to the control-plane. 224 The receive timestamp is required by various OAM use-cases. 226 o The decapsulating node processes the IOAM data field(s) using the 227 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 228 IOAM processing may be to export the data fields, send data fields 229 via Telemetry, etc. 231 o The decapsulating node also pops the Indicator Label and the IOAM 232 data fields from the MPLS header. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Segment List(1) | TC |S| TTL | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 . . 240 . . 241 . . 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Segment List(n) | TC |S| TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | PSID | TC |S| TTL | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Packet as shown in Figure 1 or Figure 2 | 248 . . 249 +---------------------------------------------------------------+ 251 Figure 3: Data Packet over SR-MPLS Policy 253 4.1. Edge-to-Edge IOAM Indicator Labels 255 IOAM Indicator Label (value TBA1) and IOAM and Flow Indicator Label 256 (value TBA2) are used to indicate the presence of the IOAM data field 257 in the MPLS header. 259 The Indicator Label with value TBA2 is used to carry a second label 260 underneath with protocol value 0000b and 20-bit Flow Label. The 261 protocol value 0000b allows to avoid incorrect IP header based 262 hashing over ECMP paths that uses the value 0x4 (for IPv4) and value 263 0x6 (for IPv6) [RFC4928]. The Flow Label identifies the traffic flow 264 that can be used for IOAM purpose as well as for hashing over ECMP 265 paths. 267 The IOAM Indicator Label and IOAM and Flow Indicator Label can be 268 allocated using one of the following methods: 270 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 271 Special-Purpose MPLS Values [mpls-spl-terminology]. 273 o Labels allocated by a controller from the global table of the 274 decapsulating node. The controller provisions the label on both 275 encapsulating and decapsulating nodes. 277 o Labels allocated by the decapsulating node. The signaling 278 extension for this is outside the scope of this document. 280 5. Procedure for Hop-by-Hop IOAM 282 The hop-by-hop IOAM includes IOAM-Types IOAM Pre-allocated Trace 283 Option Type, IOAM Incremental Trace Option Type and IOAM POT Option 284 Type. 286 Different Indicator Labels (TBA3 and TBA4) are used for hop-by-hop 287 IOAM. 289 The details for hop-by-hop IOAM will be added in a future version of 290 the document. 292 6. Considerations for ECMP 294 The encapsulating node needs to make sure the IOAM data field does 295 not start with a well known IP protocol value (e.g. 0x4 for IPv4 and 296 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 297 the IP header. This can be achieved by using the IOAM and Flow 298 Indicator Label (value TBA2 and TBA4) that follows by protocol value 299 0000b. This approach is consistent with the use of utilizing 0000b 300 as the first nibble after the MPLS label stack, as described in 301 [RFC4928] [RFC4385]. 303 Note that the hashing function for ECMP that uses the labels from the 304 MPLS header may also now include the Indicator Label. 306 The entropy label can be used for hashing function for ECMP as 307 defined in [RFC6790]. 309 7. Node Capability 311 The decapsulating node that has to pop the Indicator Label, data 312 fields, and perform the IOAM function may not be capable of 313 supporting it. The encapsulating node needs to know if the 314 decapsulating node can support the IOAM function. The signaling 315 extension for this capability exchange is outside the scope of this 316 document. 318 8. IANA Considerations 320 IANA maintains the "Special-Purpose Multiprotocol Label Switching 321 (MPLS) Label Values" registry (see 322 ). IANA is requested to allocate IOAM Indicator Label 324 value and IOAM and Flow Indicator value from the "Extended 325 Special-Purpose MPLS Label Values" registry: 327 +-------------+-----------------------------------+---------------+ 328 | Value | Description | Reference | 329 +-------------+-----------------------------------+---------------+ 330 | TBA1 | E2E IOAM Indicator Label | This document | 331 +-------------+-----------------------------------+---------------+ 332 | TBA2 | E2E IOAM and Flow Indicator Label | This document | 333 +-------------+-----------------------------------+---------------+ 334 | TBA3 | HbH IOAM Indicator Label | This document | 335 +-------------+-----------------------------------+---------------+ 336 | TBA4 | HbH IOAM and Flow Indicator Label | This document | 337 +-------------+-----------------------------------+---------------+ 339 9. Security Considerations 341 The security considerations of SR-MPLS are discussed in 342 [I-D.ietf-spring-segment-routing-mpls], and the security 343 considerations of IOAM in general are discussed in 344 [I-D.ietf-ippm-ioam-data]. 346 IOAM is considered a "per domain" feature, where one or several 347 operators decide on leveraging and configuring IOAM according to 348 their needs. Still, operators need to properly secure the IOAM 349 domain to avoid malicious configuration and use, which could include 350 injecting malicious IOAM packets into a domain. 352 10. Acknowledgements 354 The authors would like to thank Shwetha Bhandari and Vengada Prasad 355 Govindan for the discussions on IOAM. The authors would also like to 356 thank Tarek Saad, Loa Andersson and Cheng Li for providing many 357 useful comments. 359 11. References 361 11.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 365 RFC2119, March 1997. 367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 368 2119 Key Words", RFC 8174, May 2017. 370 [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., 371 Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, 372 "Segment Routing with MPLS data plane", 373 draft-ietf-spring-segment-routing-mpls, work in progress. 375 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, 376 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 377 Mozes, D., Lapukhov, P., Chang, R., and Bernier, D., "Data 378 Fields for In-situ OAM", draft-ietf-ippm-ioam-data, work 379 in progress. 381 11.2. Informative References 383 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 384 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 385 Use over an MPLS PSN", RFC 4385, February 2006. 387 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 388 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 389 4928, June 2007. 391 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 392 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 393 RFC 6790, November 2012. 395 [mpls-spl-terminology] L. Andersson, et al. "Special Purpose Label 396 terminology", draft-ietf-mpls-spl-terminology, work in 397 progress. 399 Contributors 401 Sagar Soni 402 Cisco Systems, Inc. 403 Email: sagsoni@cisco.com 405 Patrick Khordoc 406 Cisco Systems, Inc. 407 Email: pkhordoc@cisco.com 409 Authors' Addresses 410 Rakesh Gandhi (editor) 411 Cisco Systems, Inc. 412 Canada 414 Email: rgandhi@cisco.com 416 Zafar Ali 417 Cisco Systems, Inc. 419 Email: zali@cisco.com 421 Clarence Filsfils 422 Cisco Systems, Inc. 423 Belgium 425 Email: cf@cisco.com 427 Frank Brockners 428 Cisco Systems, Inc. 429 Hansaallee 249, 3rd Floor 430 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 431 Germany 433 Email: fbrockne@cisco.com 435 Bin Wen 436 Comcast 438 Email: Bin_Wen@cable.comcast.com 440 Voitek Kozak 441 Comcast 443 Email: Voitek_Kozak@comcast.com