idnits 2.17.00 (12 Aug 2021) /tmp/idnits58099/draft-filsfils-spring-path-tracing-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 document date (4 March 2022) is 71 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 (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft A. Abdelsalam, Ed. 4 Intended status: Standards Track P. Camarillo, Ed. 5 Expires: 5 September 2022 Cisco Systems, Inc. 6 M. Yufit 7 Broadcom 8 T. Graf 9 Swisscom 10 Y. Su 11 Alibaba, Inc 12 S. Matsushima 13 SoftBank 14 4 March 2022 16 Path Tracing in SRv6 networks 17 draft-filsfils-spring-path-tracing-00 19 Abstract 21 Path Tracing provides a record of the packet path as a sequence of 22 interface ids. In addition, it provides a record of end-to-end 23 delay, per-hop delay, and load on each egress interface along the 24 packet delivery path. 26 Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- 27 by-Hop extension header. 29 Path Tracing supports fine grained timestamp. It has been designed 30 for linerate hardware implementation in the base pipeline. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 5 September 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 3. Midpoint Compressed Data . . . . . . . . . . . . . . . . . . 4 69 4. PT Probing Instance . . . . . . . . . . . . . . . . . . . . . 5 70 5. PT Source Node Dataplane Behavior . . . . . . . . . . . . . . 6 71 6. PT Midpoint Node Dataplane Behavior . . . . . . . . . . . . . 7 72 7. PT Sink Node Dataplane Behavior . . . . . . . . . . . . . . . 7 73 8. PT Headers . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. IPv6 Hop-by-Hop Path Tracing Option . . . . . . . . . . . 8 75 8.2. SRH Path Tracing TLV . . . . . . . . . . . . . . . . . . 9 76 9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 12.1. Destination Options and Hop-by-Hop Options . . . . . . . 12 81 12.2. Segment Routing Header TLV . . . . . . . . . . . . . . . 12 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 15.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 Path Tracing provides a record of the packet path as a sequence of 92 interface ids. In addition, it provides a record of end-to-end 93 delay, per-hop delay, and load on each egress interface along the 94 packet delivery path. 96 Path Tracing allows to trace 14 hops with only a 40 bytes IPv6 Hop- 97 by-Hop header. The overhead is lower than [INT], 98 [I-D.ietf-ippm-ioam-data], [I-D.song-opsawg-ifit-framework], and 99 [I-D.kumar-ippm-ifa]. 101 Path Tracing supports fine-grained timestamps. It has been designed 102 for linerate hardware implementation in the base pipeline. 104 Path Tracing is applicable to both SR-MPLS [RFC8660], as well as SRv6 105 [RFC8986]. This document defines the Path Tracing specification for 106 the SRv6 dataplane. The SR-MPLS dataplane will be detailed in a 107 separate document. 109 The specification proposed in this document has been demonstrated 110 successfully in different interoperable hardware platforms at 111 linerate (Section 10). 113 2. Terminology 115 The following terms used within this document are defined in 116 [RFC8402], [RFC8754] and [RFC8986]: Segment Routing (SR), SR Domain, 117 Segment ID (SID), SRv6, SRv6 SID, SR Policy, Segment Routing Header 118 (SRH), SR source node, transit node, SR Endpoint, SA, DA. 120 The following terms are used in this document as defined below: 122 PT: Path Tracing 124 MCD: Midpoint Compressed Data (MCD). Information that every transit 125 router adds to the packet for PT purposes. Defined in Section 3 of 126 this document. 128 HbH-PT: IPv6 Hop-by-Hop [RFC8200] Path Tracing Option used for PT. 129 It contains a stack of MCDs. It is defined in Section 8.1 of this 130 document 132 SRH PT-TLV: SRH TLV defined in Section 8.2 of this document. 134 PT Source: A Source node that starts a PT Probing Instance (defined 135 in Section 4) and generates PT probes. 137 PT Midpoint: A transit node that performs plain IPv6 forwarding (or 138 SR Endpoint processing) and in addition records PT information in the 139 HbH-PT. 141 PT Sink: A node that receives PT probes sent from the SRC containing 142 the information recorded by every PT Midpoint along the path, and 143 forwards them to a regional collector after recording its PT 144 information. 146 RC: Regional collector that receives PT probes, parses, and stores 147 them in TimeSeries Database. It uses the information in the HBH-PT 148 and the SRH PT-TLV to construct the packet delivery path as well as 149 the timestamp at each node. 151 2.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Midpoint Compressed Data 161 Every PT Midpoint along the packet delivery path -from Source to 162 Sink- records its PT information into the HbH-PT header. This 163 information is known as Midpoint Compressed Data (MCD). It contains 164 the following information: 166 * MCD.OIF (Outgoing Interface ID): An 8-bit or 12-bit interface ID 167 associated with the egress physical port of the router 169 - The interface ID is assigned by an operator. The Interface IDs 170 are not globally unique across the entire network. Indeed the 171 same Interface ID may be repeated multiple times in the network 172 as long as the end-to-end path can be deterministically 173 inferred based on the chain of Interface IDs. 175 - The programming of the Interface ID in the device may be done 176 by CLI/NETCONF or any other means, and it is out of the scope 177 of this document. 179 - The usage of an 8-bit or 12-bit Interface ID is an operator 180 choice, but the Interface ID size MUST be consistent across the 181 entire network. 183 - In case of Link Aggregation Groups (LAG/bundle) [LAG], each one 184 of the members is configured with a different interface ID. 186 * MCD.OIL (Outgoing Interface Load): A 4-bit representation of the 187 egress interface load (i.e., current throughout relative to the 188 port bandwidth). 190 - The load is represented using a 4-bit value in logarithmic 191 scale. This allows more granular information as the load is 192 higher. 194 * MCD.TTS (Truncated Timestamp): An 8-bit timestamp encoding the 195 time at which the packet egress the router. 197 - The 8-bit TTS has various possible significance depending on 198 the link type. This is known as Time Template, and it is 199 configured by the operator. For example, if the link is 200 intercontinental, the 8-bit TTS encodes 7 bits of milliseconds 201 and 1 bit of microseconds; whereas if the link is within an DC, 202 the 8-bit TTS encodes 2 bits of milliseconds and 6 bits of 203 microseconds. 205 - Each egress port in the device is configured with one Time 206 Template. 208 - Note: all routers across the network MUST have time- 209 synchronization. The mechanism used for time synchronization 210 is out of the scope of this draft. 212 4. PT Probing Instance 214 The controller configures a PT Probing Instance at the source node. 215 A PT Probing Instance is configured with the following parameters: 217 * SA: the source address of the PT probe. Typically, it is the 218 loopback address of the PT SRC. 220 * Session ID: A 16-bit value. 222 * Probe-rate: Number of probes per second to generate as part of 223 this PT Probing Instance. The probe-rate is the aggregate of the 224 probes generated across all the sweeping ranges. 226 * SRv6 SID List: The SRv6 SID list associated with the packet. The 227 last SID is the Sink node. 229 * DSCP value 231 * Hop-limit Value 233 * IPv6 Flow-Label sweeping range: 235 - If set, different Flow-Label values must be used in the probe 236 packets. It may be specified as a range of specific Flow-Label 237 values to enumerate, or it may be specified as the number of 238 different random Flow-Label values to use in a round-robin. 240 * HbH-PT size 242 * MTU sweeping range: 244 - If set, payload must be included at the end of the packet to 245 test different packet sizes. 247 5. PT Source Node Dataplane Behavior 249 For each configured PT Probing Instance, according to the probe-rate, 250 the PT SRC generates a PT probe packet as follows: 252 S01. Generate a new IPv6 packet 253 S02. Set the IPv6 SA as per PT Probing Instance configuration 254 S03. Set the IPv6 DA to the first SID from the SRv6 SID List 255 S04. Set the IPv6 Next Header field to 43 (SRH) 256 S05. Set the DSCP and Flow Label values as per 257 PT Probing Instance configuration 258 S06. Append an IPv6 Hop-by-Hop header with the Hop-by-Hop 259 Path Tracing option (HbH-PT) 260 S07. Set all bits of the HbH-PT MCD Stack to zero 261 S08. Append an SRH 262 S09. Set the SRH Next Header field to 59 (IPv6 No Next Header) 263 S10. Write the SID list in the SRH 264 S11. Append the SRH PT-TLV 265 S12. Add padding bytes after the SRH to reach the desired 266 packet size as per the MTU sweeping range configuration 267 S13. Set the session ID field of the SRH PT-TLV as per 268 PT Probing Instance configuration 269 S14. Set the Sequence Number field of SRH PT-TLV and 270 increase local counter 271 S15. Perform an IPv6 FIB lookup to determine the Outgoing 272 Interface (IFACE-OUT) on which packet will be forwarded 273 S16. Record Transmit 64-bit timestamp (SRC.T64) in the T64 field 274 of the SRH PT-TLV 275 S17. Record IFACE-OUT ID (SRC.OIF) in the IF_ID field 276 of the SRH PT-TLV 277 S18. Record IFACE-OUT Load (SRC.OIL) in the IF_LD field 278 of the SRH PT-TLV 279 S19. Forward the packet via IFACE-OUT 281 Notes: 283 * The pseudocode describes local processing at a node. An 284 implementation of the pseudocode is compliant as long as the 285 externally observable wire protocol is as described in the 286 pseudocode. 288 6. PT Midpoint Node Dataplane Behavior 290 When a midpoint node receives an IPv6 packet that contains an IPv6 291 HbH-PT option, the node processes the HbH-PT as follows: 293 S01. When processing HbH-PT option { 294 S02. Compute the MCD information as per Section 3 295 S03. HbH-PT.MCD_Stack[MCD_Size:HbH-PT.OPT_Data_Len-1] = 296 HbH-PT.MCD_Stack[0:HbH-PT.OPT_Data_Len-(MCD_Size+1)] 297 //Shift HbH-PT MCD Stack to the right by MCD_Size bytes 298 S04. HbH-PT.MCD_Stack[0:MCD_Size-1] = MCD[0:MCD_Size-1] 299 //Push the MCD at the beginning of the Stack 300 S05. } 302 Notes: 304 * The PT Midpoint behavior MUST be implemented in the normal 305 pipeline to experience the regular datapath (i.e., linerate). 306 Offloading the processing of this option to either the slow-path 307 or a co-processors is not acceptable and yields invalid results. 309 7. PT Sink Node Dataplane Behavior 311 We define a new SRv6 Endpoint Behavior called "Endpoint Behavior 312 bound to an SRv6 Policy with Timestamp, Encapsulation and Forward" 313 ("End.B6.TEF" for short). 315 It is a Binding SID instantiated, at Sink nodes, that encapsulates 316 the packet with a new IPv6 header, an SRH that contains the SID list 317 associated to End.B6.TEF SID and an SRH PT-TLV that is used to carry 318 Path Tracing information of Sink node. 320 When N receives a packet whose IPv6 DA is S and S is a local 321 End.B6.TEF SID, N does the following: 323 S01. Record Rx 64-bit timestamp (SNK.T64) 324 S02. Record incoming interface ID (SNK.IIF) 325 S03. Record incoming interface Load (SNK.IIL) 326 S04. Push a new IPv6 header 327 S05. Set the IPv6 SA to the Sink node loopback 328 S06. Set the IPv6 DA to the first SID in the SRv6 SID List 329 S07. Set the IPv6 Next Header field to 43 (SRH) 330 S08. Append an SRH 331 S09. Set the SRH Next Header field to 41 (IPv6) 332 S10. Write the SID list in the SRH 333 S11. Append the SRH PT-TLV 334 S12. Set the session ID field of the SRH PT-TLV to zero 335 S13. Set the Sequence Number field of the SRH PT-TLV to zero 336 S14. Write SNK.T64 in the T64 field of the SRH PT-TLV 337 S15. Write SNK.IIF in the IF_ID field of the SRH PT-TLV 338 S16. Write SNK.IIL in the IF_LD field of the SRH PT-TLV 339 S17. Submit the packet to the egress IPv6 FIB lookup for 340 transmission to the new destination 342 Notes: 344 * The pseudocode describes local processing at a node. An 345 implementation of the pseudocode is compliant as long as the 346 externally observable wire protocol is as described in the 347 pseudocode. 349 8. PT Headers 351 8.1. IPv6 Hop-by-Hop Path Tracing Option 353 This document defines a new IPv6 Path Tracing option to be carried in 354 the IPv6 Hop-by-Hop Header. The option has the following format: 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Option Type | Opt Data Len | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 ~ MCD Stack ~ 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 1: IPv6 Hop-by-Hop Path Tracing Option Format 366 Where: 368 * Option Type: TBA1-1 370 - The 3 high-order bits of the option must be set to 001 371 o 00: Skip HbH for nodes that don't support the HbH-PT Option 372 Type 374 o 1: update HbH-PT for nodes that support the HbH-PT Option 375 Type 377 - Opt Data Len: the length of the MCD stack in bytes. 379 Note: The IPv6 Path Tracing Option has a variable length. It is 380 RECOMMENDED that implementations support a 38-octet HbH-PT Option. 381 The operator, upon configuring the Source node behavior, MUST select 382 an option length that is supported by all the routers in the network. 384 8.2. SRH Path Tracing TLV 386 We define a new SRH TLV, called "Path Tracing TLV" ("SRH PT-TLV" for 387 short). It has the following format: 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type | Length | IF_ID | IF_LD | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 + T64 + 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Session ID | Sequence Number | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 2: SRH Path Tracing TLV Format 401 Where: 403 * Type: TBA2-1 405 * Length: 14 407 * IF_ID: 12-bit Interface ID 409 * IF_LD: 4-bit Interface Load 411 * T64: 64-bit PTP Timestamp 413 * Session ID: Session identifier set by SRC node generating the 414 probes. Used to co-relate probes of the same session. Value of 415 zero means unset. 417 * Sequence Number: the sequence number of the probe set by SRC node 418 generating the probes. Value of zero means unset. 420 Note: The SRH PT-TLV is generated by both the PT SRC and the PT SNK. 421 When used at the PT SNK node, the Session ID, and Sequence Number 422 fields MUST be set to zero. 424 9. Benefits 426 * Low overhead: 428 - A 40Byte Hop-By-Hop header allows for 14 hops path 429 measurements: 1 at the PT SRC, 12 at PT Midpoint routers and 1 430 at the PT SNK 432 - PT has the lowest MTU overhead compared to alternative 433 solutions such as [INT], [I-D.ietf-ippm-ioam-data], 434 [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. 436 * Linerate and HW friendliness: 438 - Implemented at linerate in current hardware, using the regular 439 forwarding pipeline. No offloading to co-processors or slow- 440 path whose databases might defer from forwarding pipeline. 442 - Leverages mature hardware capabilities (basic shift operation); 443 no packet resizing at every node along the path 445 - High number of diverse linerate interoperable hardware 446 Implementations (see Section 10) 448 * Scalable Fine-grained Timestamp: 450 - 64bit at PT SRC and PT SNK 452 - 8bit at PT Midpoint leveraging flexible per-outgoing-link 453 template allowing diverse link types in the same measurement 454 (e.g., DC, metro, WAN) 456 * Scalable Load measurement 458 10. Implementation Status 460 Editorial note: Please remove this section prior publication. 462 The following routing platforms have participated in an interop 463 testing: 465 * Cisco 8802 (based Cisco Silicon One Q200) 467 * Cisco ASR9904 with Lightspeed linecard 468 * Cisco NCS5508 (based on Broadcom Jericho2 platform) 470 * Cisco Nexus N3K-C3464C (based on Barefoot Tofino) 472 * Marvel Prestera Falcon 474 The following open-source software networking stacks have also 475 participated in the interop: 477 * FD.io VPP 479 * Linux Kernel 481 The following opensource applications also have extensions to support 482 Path Tracing: 484 * Wireshark 486 * Tcpdump 488 * P4 implementation for software switch 490 11. Security Considerations 492 The security considerations for Segment Routing are discussed in 493 [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model 494 and the requirements for securing the SR Domain. The security 495 considerations of [RFC8754] also cover topics such as attack vectors 496 and their mitigation mechanisms that also apply to the behaviors 497 introduced in this document. Together, they describe the required 498 security mechanisms that allow establishment of an SR domain of 499 trust. Having such a well-defined trust boundary is necessary in 500 order to operate SRv6-based services for internal traffic while 501 preventing any external traffic from accessing or exploiting the 502 SRv6-based services. 504 This document defines the Path Tracing architecture, which is 505 deployed on a secured SRv6-domain. As such, all the security 506 considerations defined in [RFC8754], [RFC8402], and [RFC8986] are 507 applicable. 509 In addition, any border router in an SR Domain network where Path 510 Tracing is enabled, MUST support the configuration of the following 511 ACLs: 513 * If there is a packet coming from an external interface destined 514 towards an internal interface that contains an IPv6 Hop-by-Hop 515 header with a Path Tracing option, then such packet is silently 516 dropped. 518 * If there is a packet coming from an internal interface destined 519 towards an external interface that contains an IPv6 Hop-by-Hop 520 header with a Path Tracing option, then such packet is silently 521 dropped. 523 These ACLs SHOULD be enabled by default. An operator MAY disable 524 them individually based on local configuration. 526 The processing of IPv6 Hop-by-Hop headers could sometimes be used as 527 an attack vector to overload the CPU of the router. As defined in 528 Section 6 of this document, the HBH-PT option MUST be processed at 529 linerate. Therefore there is no impact on the router's CPU. 531 12. IANA Considerations 533 This document has two actions for IANA: 535 12.1. Destination Options and Hop-by-Hop Options 537 This I-D requests IANA to allocate a new entry in the "Destination 538 Options and Hop-by-Hop Options" sub-registry under the top-level 539 registry "Internet Protocol Version 6 (IPv6) Parameters": 541 Value Description Reference 542 ---------------------------------------------- 543 TBA1-1 Path Tracing [This.ID] 545 Note: The 3 high-order bits must be 001. 547 12.2. Segment Routing Header TLV 549 This I-D requests IANA to allocate a new entry in the "Segment 550 Routing Header TLVs" sub-registry under the top-level registry 551 "Internet Protocol Version 6 (IPv6) Parameters": 553 Value Description Reference 554 ---------------------------------------------- 555 TBA2-1 Path Tracing TLV [This.ID] 557 13. Acknowledgements 559 The authors of this document would like to thank the team that has 560 collaborated on the design and implementation of the Path Tracing 561 framework at Cisco, Broadcom, Marvel, Swisscom, Alibaba, Softbank, 562 University of Rome "Tor Vergata", and ETH Zurich. In particular: 563 Eyal Dagan, Guy Caspary, Elad Naor, Aviran Kadosh, Eli Stein, Oren 564 Yabo, Aviad Behar, Anand Sridharan, Anju Dey, John Bettink, Kamran 565 Raza, Asif Islam, Yue Gao, Jakub Horn, Sam Kheirallah, Shelly Cadora, 566 Kris Michielsen, Francois Clad, Stefano Salsano, Andrea Mayer, Paolo 567 Lungaroni, Giulio Sidoretti, Leonardo Rodoni, Marco Tollini. 569 14. Contributors 571 Jisu Bhattacharya, Cisco Systems; jisu@cisco.com 573 Rakesh Gandhi, Cisco Systems; rgandhi@cisco.com 575 Serguei Bezverkhi, Cisco Systems; sbezverk@cisco.com 577 Sonia Ben Ayed, Cisco Systems; sbenayed@cisco.com 579 Israel Meilik, Broadcom; israel.meilik@broadcom.com 581 Shay Zadok, Broadcom; shay.zadok@broadcom.com 583 Weiqiang Cheng, China Mobile; chengweiqiang@chinamobile.com 585 15. References 587 15.1. Normative References 589 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 590 (IPv6) Specification", STD 86, RFC 8200, 591 DOI 10.17487/RFC8200, July 2017, 592 . 594 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 595 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 596 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 597 . 599 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 600 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 601 (SRv6) Network Programming", RFC 8986, 602 DOI 10.17487/RFC8986, February 2021, 603 . 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 15.2. Informative References 616 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 617 Decraene, B., Litkowski, S., and R. Shakir, "Segment 618 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 619 July 2018, . 621 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 622 Decraene, B., Litkowski, S., and R. Shakir, "Segment 623 Routing with the MPLS Data Plane", RFC 8660, 624 DOI 10.17487/RFC8660, December 2019, 625 . 627 [I-D.ietf-ippm-ioam-data] 628 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 629 for In-situ OAM", Work in Progress, Internet-Draft, draft- 630 ietf-ippm-ioam-data-17, 13 December 2021, 631 . 634 [I-D.kumar-ippm-ifa] 635 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 636 H., Ghanwani, A., Cai, D., Ou, H., Li, Y., and X. Wang, 637 "Inband Flow Analyzer", Work in Progress, Internet-Draft, 638 draft-kumar-ippm-ifa-04, 20 January 2022, 639 . 642 [I-D.song-opsawg-ifit-framework] 643 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "A 644 Framework for In-situ Flow Information Telemetry", Work in 645 Progress, Internet-Draft, draft-song-opsawg-ifit- 646 framework-17, 22 February 2022, 647 . 650 [INT] "In-band Network Telemetry (INT) Dataplane Specification", 651 2020, . 654 [LAG] "IEEE Standard for Local and metropolitan area networks - 655 Link aggregation, IEEE std 802.1AX-2008", IEEE , 2008. 657 Authors' Addresses 659 Clarence Filsfils (editor) 660 Cisco Systems, Inc. 661 Belgium 662 Email: cf@cisco.com 664 Ahmed Abdelsalam (editor) 665 Cisco Systems, Inc. 666 Italy 667 Email: ahabdels@cisco.com 669 Pablo Camarillo Garvia (editor) 670 Cisco Systems, Inc. 671 Spain 672 Email: pcamaril@cisco.com 674 Mark Yufit 675 Broadcom 676 Israel 677 Email: mark.yufit@broadcom.com 679 Thomas Graf 680 Swisscom 681 Switzerland 682 Email: thomas.graf@swisscom.com 684 Yuanchao Su 685 Alibaba, Inc 686 China 687 Email: yitai.syc@alibaba-inc.com 689 Satoru Matsushima 690 SoftBank 691 Japan 692 Email: satoru.matsushima@g.softbank.co.jp