idnits 2.17.1 draft-gandhi-mpls-ioam-sr-00.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 (October 18, 2019) is 1645 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 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: April 20, 2020 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 October 18, 2019 12 Segment Routing with MPLS Data Plane Encapsulation 13 for In-situ OAM Data 14 draft-gandhi-mpls-ioam-sr-00 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 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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. The IOAM data fields are further 88 updated in draft-ioamteam-ippm-ioam-direct-export for direct export 89 use-cases and in draft-ietf-ippm-ioam-flags for loopback and active 90 measurements. 92 Segment Routing (SR) technology leverages the source routing paradigm 94 [I-D.ietf-spring-segment-routing-mpls]. A node steers a packet 95 through a controlled set of instructions, called segments, by 96 pre-pending the packet with an SR header. In the MPLS data plane, 97 the SR header is instantiated through a label stack. 99 This document defines how IOAM data fields are transported with the 100 SR with MPLS data plane (SR-MPLS) encapsulation. The procedures 101 defined are also equally applicable to all other MPLS data plane 102 encapsulations. 104 2. Conventions 106 2.1. Requirement Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119] [RFC8174] 111 when, and only when, they appear in all capitals, as shown here. 113 2.2. Abbreviations 115 Abbreviations used in this document: 117 ECMP Equal Cost Multi-Path 119 IOAM In-situ Operations, Administration, and Maintenance 121 MPLS Multiprotocol Label Switching 123 OAM Operations, Administration, and Maintenance 125 PM Performance Measurement 127 POT Proof-of-Transit 129 PSID Path Segment Identifier 131 SR Segment Routing 133 SR-MPLS Segment Routing with MPLS Data plane 135 3. IOAM Data Field Encapsulation in MPLS Header 137 The IOAM data fields defined in [I-D.ietf-ippm-ioam-data] are used. 138 IOAM data fields are carried in the MPLS header as shown in Figure 1 139 and Figure 2. More than one trace options can be present in the IOAM 140 data fields. The Indicator Label is added at the bottom of the MPLS 141 label stack (S flag set to 1) to indicate the presence of the IOAM 142 data field(s) in the MPLS header. 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 | IOAM Indicator Label TBA1 | TC |1| TTL | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 149 | IOAM-Type | IOAM HDR LEN | RESERVED | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 151 | | O 152 | | A 153 ~ IOAM Option and Data Space ~ M 154 | | | 155 | | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 157 | | 158 | | 159 | Payload + Padding (L2/L3/ESP/...) | 160 | | 161 | | 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: E2E IOAM encapsulation in MPLS Header 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | IOAM and Flow Indicator Label TBA2 | TC |1| TTL | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |0 0 0 0| Flow label | RESERVED | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 174 | IOAM-Type | IOAM HDR LEN | RESERVED | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 176 | | O 177 | | A 178 ~ IOAM Option and Data Space ~ M 179 | | | 180 | | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 182 | | 183 | | 184 | Payload + Padding (L2/L3/ESP/...) | 185 | | 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 2: E2E IOAM encapsulation with Flow Label in MPLS Header 192 Indicator Label and Flow Label as defined in this document. 194 The fields related to the encapsulation of IOAM data fields in the 195 MPLS header are defined as follows: 197 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 198 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 200 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 201 4-octet units. 203 RESERVED: 8-bit reserved field MUST be set to zero upon 204 transmission and ignored upon receipt. 206 IOAM Option and Data Space: IOAM option header and data is present 207 as defined by the IOAM-Type field, and is defined in Section 4 of 208 [I-D.ietf-ippm-ioam-data]. 210 4. Procedure for Edge-to-Edge IOAM 212 This section summarizes the procedure for data encapsulation and 213 decapsulation for IOAM Edge-to-Edge Option Type 214 [I-D.ietf-ippm-ioam-data] in MPLS header. 216 o The encapsulating node inserts the IOAM Indicator Label or IOAM 217 Flow Indicator Label with Flow Label and one or more IOAM data 218 field(s) in the MPLS header. The procedure to generate the Flow 219 Label is outside the scope of this document. 221 o The decapsulating node "forwards and punts the timestamped copy" 222 of the data packet including IOAM data fields when the node 223 recognizes the IOAM Indicator Label and IOAM Flow Indicator Label. 224 The copy of the data packet is punted to the slow path for OAM 225 processing and is not necessarily punted to the control-plane. 226 The receive timestamp is required by various OAM use-cases. 228 o The decapsulating node processes the IOAM data field(s) using the 229 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 230 IOAM processing may be to export the data fields, send data fields 231 via Telemetry, etc. 233 o The decapsulating node also pops the Indicator Label and the IOAM 234 data fields from the MPLS header. 236 O An example of data packet carrying the SR-MPLS header with Path 237 Segment Identifier (PSID) [I-D.spring-mpls-path-segment] with IOAM 238 encapsulation is shown in Figure 3. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Segment List(1) | TC |S| TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 . . 246 . . 247 . . 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Segment List(n) | TC |S| TTL | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | PSID | TC |S| TTL | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Packet as shown in Figure 1 or Figure 2 | 254 . . 255 +---------------------------------------------------------------+ 257 Figure 3: Data Packet over SR-MPLS Policy 259 4.1. Edge-to-Edge IOAM Indicator Labels 261 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 262 Option-Type [I-D.ietf-ippm-ioam-data]. IOAM Indicator Label (value 263 TBA1) and IOAM and Flow Indicator Label (value TBA2) are used to 264 indicate the presence of the E2E IOAM data field in the MPLS header. 266 The Indicator Label with value TBA2 is used to carry a second label 267 underneath with protocol value 0000b and 20-bit Flow Label. The 268 protocol value 0000b allows to avoid incorrect IP header based 269 hashing over ECMP paths that uses the value 0x4 (for IPv4) and value 270 0x6 (for IPv6) [RFC4928]. The Flow Label identifies the traffic flow 271 that can be used for IOAM purpose as well as for hashing over ECMP 272 paths. 274 The IOAM Indicator Label and IOAM and Flow Indicator Label can be 275 allocated using one of the following methods: 277 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 278 Special-Purpose MPLS Values [mpls-spl-terminology]. 280 o Labels allocated by a Controller from the global table of the 281 decapsulating node. The Controller provisions the label on both 282 encapsulating and decapsulating nodes. 284 o Labels allocated by the decapsulating node. The signaling 285 extension for this is outside the scope of this document. 287 5. Procedure for Hop-by-Hop IOAM 289 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM 290 Pre-allocated Trace Option-Type, IOAM Incremental Trace Option-Type 291 and IOAM Proof of Transit (POT) Option-Type 292 [I-D.ietf-ippm-ioam-data]. Different values for Indicator Labels 293 (TBA3 and TBA4) are used to indicate presence of hop-by-hop IOAM. 295 The details for hop-by-hop IOAM will be added in a future version of 296 the document. 298 6. Considerations for ECMP 300 The encapsulating node needs to make sure the IOAM data field does 301 not start with a well known IP protocol value (e.g. 0x4 for IPv4 and 302 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 303 the IP header. This can be achieved by using the IOAM and Flow 304 Indicator Label (value TBA2 and TBA4) that follows by protocol value 305 0000b. This approach is consistent with the use of utilizing 0000b 306 as the first nibble after the MPLS label stack, as described in 307 [RFC4928] [RFC4385]. 309 Note that the hashing function for ECMP that uses the labels from the 310 MPLS header may also now include the Indicator Label. 312 The entropy label can be used for hashing function for ECMP as 313 defined in [RFC6790]. 315 7. Node Capability 317 The decapsulating node that has to pop the 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 8. IANA Considerations 326 IANA maintains the "Special-Purpose Multiprotocol Label Switching 327 (MPLS) Label Values" registry (see 328 ). IANA is requested to allocate IOAM Indicator Label 330 value and IOAM and Flow Indicator value from the "Extended 331 Special-Purpose MPLS Label Values" registry: 333 +-------------+-----------------------------------+---------------+ 334 | Value | Description | Reference | 335 +-------------+-----------------------------------+---------------+ 336 | TBA1 | E2E IOAM Indicator Label | This document | 337 +-------------+-----------------------------------+---------------+ 338 | TBA2 | E2E IOAM and Flow Indicator Label | This document | 339 +-------------+-----------------------------------+---------------+ 340 | TBA3 | HbH IOAM Indicator Label | This document | 341 +-------------+-----------------------------------+---------------+ 342 | TBA4 | HbH IOAM and Flow Indicator Label | This document | 343 +-------------+-----------------------------------+---------------+ 345 9. Security Considerations 347 The security considerations of SR-MPLS are discussed in 348 [I-D.ietf-spring-segment-routing-mpls], and the security 349 considerations of IOAM in general are discussed in 350 [I-D.ietf-ippm-ioam-data]. 352 IOAM is considered a "per domain" feature, where one or several 353 operators decide on leveraging and configuring IOAM according to 354 their needs. Still, operators need to properly secure the IOAM 355 domain to avoid malicious configuration and use, which could include 356 injecting malicious IOAM packets into a domain. 358 10. Acknowledgements 360 The authors would like to thank Shwetha Bhandari and Vengada Prasad 361 Govindan for the discussions on IOAM. The authors would also like to 362 thank Tarek Saad, Loa Andersson and Cheng Li for providing many 363 useful comments. 365 11. References 367 11.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 371 RFC2119, March 1997. 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", RFC 8174, May 2017. 376 [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., 377 Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, 378 "Segment Routing with MPLS data plane", 379 draft-ietf-spring-segment-routing-mpls, work in progress. 381 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, 382 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 383 Mozes, D., Lapukhov, P., Chang, R., and Bernier, D., "Data 384 Fields for In-situ OAM", draft-ietf-ippm-ioam-data, work 385 in progress. 387 11.2. Informative References 389 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 390 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 391 Use over an MPLS PSN", RFC 4385, February 2006. 393 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 394 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 395 4928, June 2007. 397 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 398 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 399 RFC 6790, November 2012. 401 [mpls-spl-terminology] L. Andersson, et al. "Special Purpose Label 402 terminology", draft-ietf-mpls-spl-terminology, work in 403 progress. 405 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 406 MPLS Based Segment Routing Network", 407 draft-ietf-spring-mpls-path-segment, work in progress. 409 Contributors 411 Sagar Soni 412 Cisco Systems, Inc. 413 Email: sagsoni@cisco.com 414 Patrick Khordoc 415 Cisco Systems, Inc. 416 Email: pkhordoc@cisco.com 418 Authors' Addresses 420 Rakesh Gandhi (editor) 421 Cisco Systems, Inc. 422 Canada 424 Email: rgandhi@cisco.com 426 Zafar Ali 427 Cisco Systems, Inc. 429 Email: zali@cisco.com 431 Clarence Filsfils 432 Cisco Systems, Inc. 433 Belgium 435 Email: cf@cisco.com 437 Frank Brockners 438 Cisco Systems, Inc. 439 Hansaallee 249, 3rd Floor 440 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 441 Germany 443 Email: fbrockne@cisco.com 445 Bin Wen 446 Comcast 448 Email: Bin_Wen@cable.comcast.com 450 Voitek Kozak 451 Comcast 453 Email: Voitek_Kozak@comcast.com