idnits 2.17.1 draft-ietf-6man-spring-srv6-oam-12.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2021) is 872 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) == Unused Reference: 'I-D.ietf-ippm-ioam-data' is defined on line 966, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems 5 Expires: June 1, 2022 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 November 28, 2021 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-12 17 Abstract 19 This document describes how the existing IPv6 mechanisms for ping and 20 traceroute can be used in an SRv6 network. The document also 21 specifies the OAM flag in the Segment Routing Header (SRH) for 22 performing controllable and predictable flow sampling from segment 23 endpoints. In addition, the document describes how a centralized 24 monitoring system performs a path continuity check between any nodes 25 within an SRv6 domain. 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 https://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 This Internet-Draft will expire on June 1, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Terminology and Reference Topology . . . . . . . . . . . 4 65 2. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 67 2.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 68 2.2. OAM Operations . . . . . . . . . . . . . . . . . . . . . 8 69 3. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Ping in SRv6 Networks . . . . . . . . . . . . . . . . . . 9 71 3.1.1. Pinging an IPv6 Address via a Segment-list . . . . . 9 72 3.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 10 73 3.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.2.1. Traceroute to an IPv6 Address via a Segment-list . . 11 75 3.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 13 76 3.3. A Hybrid OAM Using O-flag . . . . . . . . . . . . . . . . 15 77 3.4. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 17 78 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 10.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 As Segment Routing with IPv6 data plane (SRv6) [RFC8402] simply adds 92 a new type of Routing Extension Header, existing IPv6 OAM mechanisms 93 can be used in an SRv6 network. This document describes how the 94 existing IPv6 mechanisms for ping and traceroute can be used in an 95 SRv6 network. This includes illustrations of pinging an SRv6 SID to 96 verify that the SID is reachable and is locally programmed at the 97 target node. This also includes illustrations for tracerouting to an 98 SRv6 SID for hop-by-hop fault localization as well as path tracing to 99 a SID. 101 The document also introduces enhancements for the OAM mechanism for 102 SRv6 networks for performing controllable and predictable flow 103 sampling from segment endpoints using, e.g., IP Flow Information 104 Export (IPFIX) protocol [RFC7011]. Specifically, the document 105 specifies the O-flag in SRH as a marking-bit in the user packets to 106 trigger the telemetry data collection and export at the segment 107 endpoints. 109 The document also outlines how the centralized OAM technique in 110 [RFC8403] can be extended for SRv6 to perform a path continuity check 111 between any nodes within an SRv6 domain. Specifically, the document 112 illustrates how a centralized monitoring system can monitor arbitrary 113 SRv6 paths by creating the loopback probes that originate and 114 terminate at the centralized monitoring system. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 1.2. Abbreviations 126 The following abbreviations are used in this document: 128 SID: Segment ID. 130 SL: Segments Left. 132 SR: Segment Routing. 134 SRH: Segment Routing Header [RFC8754]. 136 SRv6: Segment Routing with IPv6 Data plane. 138 PSP: Penultimate Segment Pop of the SRH [RFC8986]. 140 USP: Ultimate Segment Pop of the SRH [RFC8986]. 142 ICMPv6: ICMPv6 Specification [RFC4443]. 144 IS-IS: Intermediate System to Intermediate System 145 OSPF: Open Shortest Path First protocol [RFC2328] 147 IGP: Interior Gateway Protocols (e.g., OSPF, IS-IS). 149 BGP-LS: Border Gateway Protocol - Link State Extensions [RFC8571] 151 1.3. Terminology and Reference Topology 153 Throughout the document, the following terminology and simple 154 topology is used for illustration. 156 +--------------------------| N100 |---------------------------------+ 157 | | 158 | ====== link1====== link3------ link5====== link9------ ====== | 159 ||N1||------||N2||------| N3 |------||N4||------| N5 |---||N7|| 160 || ||------|| ||------| |------|| ||------| |---|| || 161 ====== link2====== link4------ link6======link10------ ====== 162 | | | | 163 ---+-- | ------ | --+--- 164 |CE 1| +-------| N6 |---------+ |CE 2| 165 ------ link7 | | link8 ------ 166 ------ 168 Figure 1 Reference Topology 170 In the reference topology: 172 Node j has a IPv6 loopback address 2001:db8:L:j::/128. 174 Nodes N1, N2, N4 and N7 are SRv6-capable nodes. 176 Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6-capable. 177 Such nodes are referred as non-SRv6 capable nodes. 179 CE1 and CE2 are Customer Edge devices of any data plane capability 180 (e.g., IPv4, IPv6, L2, etc.). 182 A SID at node j with locator block 2001:db8:K::/48 and function U 183 is represented by 2001:db8:K:j:U::. 185 Node N100 is a controller. 187 The IPv6 address of the nth Link between node i and j at the i 188 side is represented as 2001:db8:i:j:in::, e.g., the IPv6 address 189 of link6 (the 2nd link between N3 and N4) at N3 in Figure 1 is 190 2001:db8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 191 link between N3 and N4) at node N3 is 2001:db8:3:4:31::. 193 2001:db8:K:j:Xin:: is explicitly allocated as the End.X SID at 194 node j towards neighbor node i via nth Link between node i and 195 node j. e.g., 2001:db8:K:2:X31:: represents End.X at N2 towards 196 N3 via link3 (the 1st link between N2 and N3). Similarly, 197 2001:db8:K:4:X52:: represents the End.X at N4 towards N5 via 198 link10 (the 2nd link between N4 and N5). Please refer to 199 [RFC8986] for description of End.X SID. 201 A SID list is represented as where S1 is the first 202 SID to visit, S2 is the second SID to visit and S3 is the last SID 203 to visit along the SR path. 205 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 207 * IPv6 header with source address SA, destination addresses DA 208 and SRH as next-header 210 * SRH with SID list with SegmentsLeft = SL 212 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 214 the last SID to traverse. (S3, S2, S1; SL) represents the same 215 SID list but encoded in the SRH format where the rightmost SID 216 in the SRH is the first SID and the leftmost SID in the SRH is 217 the last SID. When referring to an SR policy in a high-level 218 use-case, it is simpler to use the notation. When 219 referring to an illustration of the detailed packet behavior, 220 the (S3, S2, S1; SL) notation is more convenient. 222 * (payload) represents the the payload of the packet. 224 2. OAM Mechanisms 226 This section defines OAM enhancement for the SRv6 networks. 228 2.1. O-flag in Segment Routing Header 230 [RFC8754] describes the Segment Routing Header (SRH) and how SR 231 capable nodes use it. The SRH contains an 8-bit "Flags" field. 233 This document defines the following bit in the SRH Flags field to 234 carry the O-flag: 236 0 1 2 3 4 5 6 7 237 +-+-+-+-+-+-+-+-+ 238 | |O| | 239 +-+-+-+-+-+-+-+-+ 241 Where: 243 O-flag: OAM flag in the SRH Flags field defined in [RFC8754]. 245 2.1.1. O-flag Processing 247 The O-flag in SRH is used as a marking-bit in the user packets to 248 trigger the telemetry data collection and export at the segment 249 endpoints. 251 An SR domain ingress edge node encapsulates packets traversing the SR 252 domain as defined in [RFC8754]. The SR domain ingress edge node MAY 253 use the O-flag in SRH for marking the packet to trigger the telemetry 254 data collection and export at the segment endpoints. Based on a 255 local configuration, the SR domain ingress edge node may implement a 256 classification and sampling mechanism to mark a packet with the 257 O-flag in SRH. Specification of the classification and sampling 258 method is outside the scope of this document. 260 This document does not specify the data elements that need to be 261 exported and the associated configurations. Similarly, this document 262 does not define any formats for exporting the data elements. 263 Nonetheless, without the loss of generality, this document assumes IP 264 Flow Information Export (IPFIX) protocol [RFC7011] is used for 265 exporting the traffic flow information from the network devices to a 266 controller for monitoring and analytics. Similarly, without the loss 267 of generality, this document assumes requested information elements 268 are configured by the management plane through data set templates 269 (e.g., as in IPFIX [RFC7012]). 271 Implementation of the O-flag is OPTIONAL. If a node does not support 272 the O-flag, then upon reception it simply ignores it. If a node 273 supports the O-flag, it can optionally advertise its potential via 274 control plane protocol(s). 276 When N receives a packet destined to S and S is a local SID, the line 277 S01 of the pseudo-code associated with the SID S, as defined in 278 section 4.3.1.1 of [RFC8754], is appended to as follows for the 279 O-flag processing. 281 S01.1. IF O-flag is set and local configuration permits 282 O-flag processing { 283 a. Make a copy of the packet. 284 b. Send the copied packet, along with a timestamp 285 to the OAM process for telemetry data collection 286 and export. ;; Ref1 287 } 288 Ref1: To provide an accurate timestamp, an implementation should copy 289 and record the timestamp as soon as possible during packet processing. 290 Timestamp and any other metadata is not carried in the packet forwarded to the next hop. 292 Please note that the O-flag processing happens before execution of 293 regular processing of the local SID S. Specifically, the line S01.1 294 of the pseudo-code specified in this document is inserted between 295 line S01 and S02 of the pseudo-code defined in section 4.3.1.1 of 296 [RFC8754]. 298 Based on the requested information elements configured by the 299 management plane through data set templates [RFC7012], the OAM 300 process exports the requested information elements. The information 301 elements include parts of the packet header and/or parts of the 302 packet payload for flow identification. The OAM process uses 303 information elements defined in IPFIX [RFC7011] and PSAMP [RFC5476] 304 for exporting the requested sections of the mirrored packets. 306 If the penultimate segment of a segment-list is a Penultimate Segment 307 Pop (PSP) SID, telemetry data from the ultimate segment cannot be 308 requested. This is because, when the penultimate segment is a PSP 309 SID, the SRH is removed at the penultimate segment and the O-flag is 310 not processed at the ultimate segment. 312 The processing node MUST rate-limit the number of packets punted to 313 the OAM process to a configurable rate. This is to avoid hitting any 314 performance impact on the OAM and the telemetry collection processes. 315 Failure in implementing the rate limit can lead to a denial-of- 316 service attack, as detailed in Section 5. 318 The OAM process MUST NOT process the copy of the packet or respond to 319 any upper-layer header (like ICMP, UDP, etc.) payload to prevent 320 multiple evaluations of the datagram. 322 The OAM process is expected to be located on the routing node 323 processing the packet. Although the specification of the OAM process 324 or the external controller operations are beyond the scope of this 325 document, the OAM process SHOULD NOT be topologically distant from 326 the routing node, as this is likely to create significant security 327 and congestion issues. How to correlate the data collected from 328 different nodes at an external controller is also outside the scope 329 of the document. Section 3 illustrates use of the O-flag for 330 implementing a hybrid OAM mechanism, where the "hybrid" 331 classification is based on RFC7799 [RFC7799]. 333 2.2. OAM Operations 335 IPv6 OAM operations can be performed for any SRv6 SID whose behavior 336 allows Upper Layer Header processing for an applicable OAM payload 337 (e.g., ICMP, UDP). 339 Ping to an SRv6 SID is used to verify that the SID is reachable and 340 is locally programmed at the target node. Traceroute to a SID is 341 used for hop-by-hop fault localization as well as path tracing to a 342 SID. Section 3 illustrates the ICMPv6 based ping and the UDP based 343 traceroute mechanisms for ping and traceroute to an SRv6 SID. 344 Although this document only illustrates ICMPv6 ping and UDP based 345 traceroute to an SRv6 SID, the procedures are equally applicable to 346 other IPv6 OAM probing to an SRv6 SID (e.g., Bidirectional Forwarding 347 Detection (BFD) [RFC5880], Seamless BFD (SBFD) [RFC7880], STAMP probe 348 message processing [I-D.gandhi-spring-stamp-srpm], etc.). 349 Specifically, as long as local configuration allows the Upper-layer 350 Header processing of the applicable OAM payload for SRv6 SIDs, the 351 existing IPv6 OAM techniques can be used to target a probe to a 352 (remote) SID. 354 IPv6 OAM operations can be performed with the target SID in the IPv6 355 destination address without SRH or with SRH where the target SID is 356 the last segment. In general, OAM operations to a target SID may not 357 exercise all of its processing depending on its behavior definition. 358 For example, ping to an End.X SID [RFC8986] only validates the SID is 359 locally programmed at the target node and does not validate switching 360 to the correct outgoing interface. To exercise the behavior of a 361 target SID, the OAM operation should construct the probe in a manner 362 similar to a data packet that exercises the SID behavior, i.e. to 363 include that SID as a transit SID in either an SRH or IPv6 DA of an 364 outer IPv6 header or as appropriate based on the definition of the 365 SID behavior. 367 3. Illustrations 369 This section shows how some of the existing IPv6 OAM mechanisms can 370 be used in an SRv6 network. It also illustrates an OAM mechanism for 371 performing controllable and predictable flow sampling from segment 372 endpoints. How centralized OAM technique in [RFC8403] can be 373 extended for SRv6 is also described in this Section. 375 3.1. Ping in SRv6 Networks 377 The existing mechanism to perform the reachability checks, along the 378 shortest path, continues to work without any modification. Any IPv6 379 node (SRv6 capable or a non-SRv6 capable) can initiate, transit, and 380 egress a ping packet. 382 The following subsections outline some additional use cases of the 383 ICMPv6 ping in the SRv6 networks. 385 3.1.1. Pinging an IPv6 Address via a Segment-list 387 If an SRv6-capable ingress node wants to ping an IPv6 address via an 388 arbitrary segment list , it needs to initiate an ICMPv6 389 ping with an SR header containing the SID list . This is 390 illustrated using the topology in Figure 1. User issues a ping from 391 node N1 to a loopback of node N5, via segment list 392 <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID behavior used in 393 the example is End.X SID, as described in [RFC8986], but the 394 procedure is equally applicable to any other (transit) SID type. 396 Figure 2 contains sample output for a ping request initiated at node 397 N1 to a loopback address of node N5 via a segment list 398 <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. 400 > ping 2001:db8:L:5:: via segment-list 2001:db8:K:2:X31::, 401 2001:db8:K:4:X52:: 403 Sending 5, 100-byte ICMPv6 Echos to B5::, timeout is 2 seconds: 404 !!!!! 405 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 406 /0.749/0.931 ms 408 Figure 2 A sample ping output at an SRv6-capable node 410 All transit nodes process the echo request message like any other 411 data packet carrying SR header and hence do not require any change. 412 Similarly, the egress node does not require any change to process the 413 ICMPv6 echo request. For example, in the ping example of Figure 2: 415 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 416 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:L:5::, 417 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2, NH = ICMPv6)(ICMPv6 418 Echo Request). 420 o Node N2, which is an SRv6-capable node, performs the standard SRH 421 processing. Specifically, it executes the End.X behavior 422 indicated by the 2001:db8:K:2:X31:: SID and forwards the packet on 423 link3 to N3. 425 o Node N3, which is a non-SRv6 capable node, performs the standard 426 IPv6 processing. Specifically, it forwards the echo request based 427 on the DA 2001:db8:K:4:X52:: in the IPv6 header. 429 o Node N4, which is an SRv6-capable node, performs the standard SRH 430 processing. Specifically, it observes the End.X behavior 431 (2001:db8:K:4:X52::) and forwards the packet on link10 towards N5. 432 If 2001:db8:K:4:X52:: is a PSP SID, the penultimate node (Node N4) 433 does not, should not and cannot differentiate between the data 434 packets and OAM probes. Specifically, if 2001:db8:K:4:X52:: is a 435 PSP SID, node N4 executes the SID like any other data packet with 436 DA = 2001:db8:K:4:X52:: and removes the SRH. 438 o The echo request packet at N5 arrives as an IPv6 packet with or 439 without an SRH. If N5 receives the packet with SRH, it skips SRH 440 processing (SL=0). In either case, Node N5 performs the standard 441 ICMPv6 processing on the echo request and responds with the echo 442 reply message to N1. The echo reply message is IP routed. 444 3.1.2. Pinging a SID 446 The ping mechanism described above applies equally to perform SID 447 reachability check and to validate the SID is locally programmed at 448 the target node. This is explained using an example in the 449 following. The example uses ping to an END SID, as described in 450 [RFC8986], but the procedure is equally applicable to ping any other 451 SID behaviors. 453 Consider the example where the user wants to ping a remote SID 454 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The ICMPv6 455 echo request is processed at the individual nodes along the path as 456 follows: 458 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 459 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 460 2001:db8:K:2:X31::; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). 462 o Node N2, which is an SRv6-capable node, performs the standard SRH 463 processing. Specifically, it executes the End.X behavior 464 indicated by the 2001:db8:K:2:X31:: SID on the echo request 465 packet. If 2001:db8:K:2:X31:: is a PSP SID, node N4 executes the 466 SID like any other data packet with DA = 2001:db8:K:2:X31:: and 467 removes the SRH. 469 o Node N3, which is a non-SRv6 capable node, performs the standard 470 IPv6 processing. Specifically, it forwards the echo request based 471 on DA = 2001:db8:K:4:: in the IPv6 header. 473 o When node N4 receives the packet, it processes the target SID 474 (2001:db8:K:4::). 476 o If the target SID (2001:db8:K:4::) is not locally instantiated and 477 does not represent a local interface, the packet is discarded 479 o If the target SID (2001:db8:K:4::) is locally instantiated or 480 represents a local interface, the node processes the upper layer 481 header. As part of the upper layer header processing node N4 482 respond to the ICMPv6 echo request message and responds with the 483 echo reply message. The echo reply message is IP routed. 485 3.2. Traceroute 487 The existing traceroute mechanisms, along the shortest path, 488 continues to work without any modification. Any IPv6 node (SRv6 489 capable or a non-SRv6 capable) can initiate, transit, and egress a 490 traceroute probe. 492 The following subsections outline some additional use cases of the 493 traceroute in the SRv6 networks. 495 3.2.1. Traceroute to an IPv6 Address via a Segment-list 497 If an SRv6-capable ingress node wants to traceroute to IPv6 address 498 via an arbitrary segment list , it needs to initiate a 499 traceroute probe with an SR header containing the SID list . User issues a traceroute from node N1 to a loopback of node N5, 501 via segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID 502 behavior used in the example is End.X SID, as described in [RFC8986], 503 but the procedure is equally applicable to any other (transit) SID 504 type. Figure 3 contains sample output for the traceroute request. 506 > traceroute 2001:db8:L:5:: via segment-list 2001:db8:K:2:X31::, 507 2001:db8:K:4:X52:: 509 Tracing the route to 2001:db8:L:5:: 510 1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec 511 DA: 2001:db8:K:2:X31::, 512 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2) 513 2 2001:db8:3:2:31:: 0.721 msec 0.810 msec 0.795 msec 514 DA: 2001:db8:K:4:X52::, 515 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 516 3 2001:db8:4:3::41:: 0.921 msec 0.816 msec 0.759 msec 517 DA: 2001:db8:K:4:X52::, 518 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 519 4 2001:db8:5:4::52:: 0.879 msec 0.916 msec 1.024 msec 520 DA: 2001:db8:L:5:: 522 Figure 3 A sample traceroute output at an SRv6-capable node 524 In the sample traceroute output, the information displayed at each 525 hop is obtained using the contents of the "Time Exceeded" or 526 "Destination Unreachable" ICMPv6 responses. These ICMPv6 responses 527 are IP routed. 529 In the sample traceroute output, the information for link3 is 530 returned by N3, which is a non-SRv6 capable node. Nonetheless, the 531 ingress node is able to display SR header contents as the packet 532 travels through the IPv6 classic node. This is because the "Time 533 Exceeded Message" ICMPv6 message can contain as much of the invoking 534 packet as possible without the ICMPv6 packet exceeding the minimum 535 IPv6 MTU [RFC4443]. The SR header is included in these ICMPv6 536 messages initiated by the non-SRv6 capable transit nodes that are not 537 running SRv6 software. Specifically, a node generating ICMPv6 538 message containing a copy of the invoking packet does not need to 539 understand the extension header(s) in the invoking packet. 541 The segment list information returned for the first hop is returned 542 by N2, which is an SRv6-capable node. Just like for the second hop, 543 the ingress node is able to display SR header contents for the first 544 hop. 546 There is no difference in processing of the traceroute probe at an 547 IPv6 classic node and an SRv6-capable node. Similarly, both IPv6 548 classic and SRv6-capable nodes may use the address of the interface 549 on which probe was received as the source address in the ICMPv6 550 response. ICMPv6 extensions defined in [RFC5837] can be used to 551 display information about the IP interface through which the datagram 552 would have been forwarded had it been forwardable, and the IP next 553 hop to which the datagram would have been forwarded, the IP interface 554 upon which a datagram arrived, the sub-IP component of an IP 555 interface upon which a datagram arrived. 557 The IP address of the interface on which the traceroute probe was 558 received is useful. This information can also be used to verify if 559 SIDs 2001:db8:K:2:X31:: and 2001:db8:K:4:X52:: are executed correctly 560 by N2 and N4, respectively. Specifically, the information displayed 561 for the second hop contains the incoming interface address 562 2001:db8:2:3:31:: at N3. This matches with the expected interface 563 bound to End.X behavior 2001:db8:K:2:X31:: (link3). Similarly, the 564 information displayed for the fourth hop contains the incoming 565 interface address 2001:db8:4:5::52:: at N5. This matches with the 566 expected interface bound to the End.X behavior 2001:db8:K:4:X52:: 567 (link10). 569 3.2.2. Traceroute to a SID 571 The classic traceroute described in the previous section applies 572 equally to traceroute a remote SID behavior, as explained using an 573 example in the following. The example uses traceroute to an END SID, 574 as described in [RFC8986], but the procedure is equally applicable to 575 tracerouting any other SID behaviors. 577 Please note that traceroute to a SID is exemplified using UDP probes. 578 However, the procedure is equally applicable to other implementations 579 of traceroute mechanism. The UDP encoded message to traceroute a SID 580 would use the UDP ports assigned by IANA for "traceroute use". 582 Consider the example where the user wants to traceroute a remote SID 583 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The traceroute 584 probe is processed at the individual nodes along the path as follows: 586 o Node N1 initiates a traceroute probe packet as follows 587 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 588 2001:db8:K:2:X31::; SL=1; NH=UDP)(Traceroute probe). The first 589 traceroute probe is sent with hop-count value set to 1. The hop- 590 count value is incremented by 1 for each following traceroute 591 probes. 593 o When node N2 receives the packet with hop-count = 1, it processes 594 the hop-count expiry. Specifically, the node N2 responds with the 595 ICMPv6 message (Type: "Time Exceeded", Code: "Hop limit exceeded 596 in transit"). The ICMPv6 response is IP routed. 598 o When Node N2 receives the packet with hop-count > 1, it performs 599 the standard SRH processing. Specifically, it executes the End.X 600 behavior indicated by the 2001:db8:K:2:X31:: SID on the traceroute 601 probe. If 2001:db8:K:2:X31:: is a PSP SID, node N2 executes the 602 SID like any other data packet with DA = 2001:db8:K:2:X31:: and 603 removes the SRH. 605 o When node N3, which is a non-SRv6 capable node, receives the 606 packet with hop-count = 1, it processes the hop-count expiry. 607 Specifically, the node N3 responds with the ICMPv6 message (Type: 608 "Time Exceeded", Code: "Hop limit exceeded in Transit"). The 609 ICMPv6 response is IP routed. 611 o When node N3, which is a non-SRv6 capable node, receives the 612 packet with hop-count > 1, it performs the standard IPv6 613 processing. Specifically, it forwards the traceroute probe based 614 on DA 2001:db8:K:4:: in the IPv6 header. 616 o When node N4 receives the packet with DA set to the local SID 617 2001:db8:K:4::, it processes the END SID. 619 o If the target SID (2001:db8:K:4::) is not locally instantiated and 620 does not represent a local interface, the packet is discarded. 622 o If the target SID (2001:db8:K:4::) is locally instantiated or 623 represents a local interface, the node processes the upper layer 624 header. As part of the upper layer header processing node N4 625 responds with the ICMPv6 message (Type: Destination unreachable, 626 Code: Port Unreachable). The ICMPv6 response is IP routed. 628 Figure 4 displays a sample traceroute output for this example. 630 > traceroute 2001:db8:K:4:X52:: via segment-list 2001:db8:K:2:X31:: 632 Tracing the route to SID 2001:db8:K:4:X52:: 633 1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec 634 DA: 2001:db8:K:2:X31::, 635 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=1) 636 2 2001:db8:3:2:21:: 0.721 msec 0.810 msec 0.795 msec 637 DA: 2001:db8:K:4:X52::, 638 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0) 639 3 2001:db8:4:3:41:: 0.921 msec 0.816 msec 0.759 msec 640 DA: 2001:db8:K:4:X52::, 641 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0) 643 Figure 4 A sample output for hop-by-hop traceroute to a SID 645 3.3. A Hybrid OAM Using O-flag 647 This section illustrates a hybrid OAM mechanism using the the O-flag. 648 Without loss of the generality, the illustration assumes N100 is a 649 centralized controller. 651 The illustration is different than the In-situ OAM defined in [I.D- 652 draft-ietf-ippm-ioam-data]. This is because In-situ OAM records 653 operational and telemetry information in the packet as the packet 654 traverses a path between two points in the network [I.D-draft-ietf- 655 ippm-ioam-data]. The illustration in this subsection does not 656 require the recording of OAM data in the packet. 658 The illustration does not assume any formats for exporting the data 659 elements or the data elements that need to be exported. The 660 illustration assumes system clocks among all nodes in the SR domain 661 are synchronized. 663 Consider the example where the user wants to monitor sampled IPv4 VPN 664 999 traffic going from CE1 to CE2 via a low latency SR policy P 665 installed at Node N1. To exercise a low latency path, the SR Policy 666 P forces the packet via segments 2001:db8:K:2:X31:: and 667 2001:db8:K:4:X52::. The VPN SID at N7 associated with VPN 999 is 668 2001:db8:K:7:DT999::. 2001:db8:K:7:DT999:: is a USP SID. N1, N4, 669 and N7 are capable of processing O-flag but N2 is not capable of 670 processing O-flag. N100 is the centralized controller capable of 671 processing and correlating the copy of the packets sent from nodes 672 N1, N4, and N7. N100 is aware of O-flag processing capabilities. 673 Controller N100 with the help from nodes N1, N4, N7 and implements a 674 hybrid OAM mechanism using the O-flag as follows: 676 o A packet P1:(IPv4 header)(payload) is sent from CE1 to Node N1. 678 o Node N1 steers the packet P1 through the Policy P. Based on a 679 local configuration, Node N1 also implements logic to sample 680 traffic steered through policy P for hybrid OAM purposes. 681 Specification for the sampling logic is beyond the scope of this 682 document. Consider the case where packet P1 is classified as a 683 packet to be monitored via the hybrid OAM. Node N1 sets O-flag 684 during the encapsulation required by policy P. As part of setting 685 the O-flag, node N1 also sends a timestamped copy of the packet 686 P1: (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:7:DT999::, 687 2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=2; O-flag=1; 688 NH=IPv4)(IPv4 header)(payload) to a local OAM process. The local 689 OAM process sends a full or partial copy of the packet P1 to the 690 controller N100. The OAM process includes the recorded timestamp, 691 additional OAM information like incoming and outgoing interface, 692 etc. along with any applicable metadata. Node N1 forwards the 693 original packet towards the next segment 2001:db8:K:2:X31::. 695 o When node N2 receives the packet with O-flag set, it ignores the 696 O-flag. This is because node N2 is not capable of processing the 697 O-flag. Node N2 performs the standard SRv6 SID and SRH 698 processing. Specifically, it executes the End.X behavior 699 indicated by the 2001:db8:K:2:X31:: SID as described in [RFC8986] 700 and forwards the packet P1 (2001:db8:L:1::, 2001:db8:K:4:X52::) 701 (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::; 702 SL=1; O-flag=1; NH=IPv4)(IPv4 header)(payload) over link 3 towards 703 Node N3. 705 o When node N3, which is a non-SRv6 capable node, receives the 706 packet P1 , it performs the standard IPv6 processing. 707 Specifically, it forwards the packet P1 based on DA 708 2001:db8:K:4:X52:: in the IPv6 header. 710 o When node N4 receives the packet P1 (2001:db8:L:1::, 711 2001:db8:K:4:X52::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 712 2001:db8:K:2:X31::; SL=1; O-flag=1; NH=IPv4)(IPv4 713 header)(payload), it processes the O-flag. As part of processing 714 the O-flag, it sends a timestamped copy of the packet to a local 715 OAM process. Based on a local configuration, the local OAM 716 process sends a full or partial copy of the packet P1 to the 717 controller N100. The OAM process includes the recorded timestamp, 718 additional OAM information like incoming and outgoing interface, 719 etc. along with any applicable metadata. Node N4 performs the 720 standard SRv6 SID and SRH processing on the original packet P1. 721 Specifically, it executes the End.X behavior indicated by the 722 2001:db8:K:4:X52:: SID and forwards the packet P1 (2001:db8:L:1::, 723 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 724 2001:db8:K:2:X31::; SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload) 725 over link 10 towards Node N5. 727 o When node N5, which is a non-SRv6 capable node, receives the 728 packet P1, it performs the standard IPv6 processing. 729 Specifically, it forwards the packet based on DA 730 2001:db8:K:7:DT999:: in the IPv6 header. 732 o When node N7 receives the packet P1 (2001:db8:L:1::, 733 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 734 2001:db8:K:2:X31::; SL=0; O-flag=1; NH=IPv4)(IPv4 735 header)(payload), it processes the O-flag. As part of processing 736 the O-flag, it sends a timestamped copy of the packet to a local 737 OAM process. The local OAM process sends a full or partial copy 738 of the packet P1 to the controller N100. The OAM process includes 739 the recorded timestamp, additional OAM information like incoming 740 and outgoing interface, etc. along with any applicable metadata. 741 Node N7 performs the standard SRv6 SID and SRH processing on the 742 original packet P1. Specifically, it executes the VPN SID 743 indicated by the 2001:db8:K:7:DT999:: SID and based on lookup in 744 table 100 forwards the packet P1 (IPv4 header)(payload) towards CE 745 2. 747 o The controller N100 processes and correlates the copy of the 748 packets sent from nodes N1, N4 and N7 to find segment-by-segment 749 delays and provide other hybrid OAM information related to packet 750 P1. For segment-by-segment delay computation, it is assumed that 751 clock are synchronized time across the SR domain. 753 o The process continues for any other sampled packets. 755 3.4. Monitoring of SRv6 Paths 757 In the recent past, network operators demonstrated interest in 758 performing network OAM functions in a centralized manner. [RFC8403] 759 describes such a centralized OAM mechanism. Specifically, the 760 document describes a procedure that can be used to perform path 761 continuity check between any nodes within an SR domain from a 762 centralized monitoring system. However, the document focuses on SR 763 networks with MPLS data plane. This document describes how the 764 concept can be used to perform path monitoring in an SRv6 network 765 from a centralized controller. 767 In the reference topology in Figure 1, N100 uses an IGP protocol like 768 OSPF or IS-IS to get the topology view within the IGP domain. N100 769 can also use BGP-LS to get the complete view of an inter-domain 770 topology. The controller leverages the visibility of the topology to 771 monitor the paths between the various endpoints. 773 The controller N100 advertises an END SID [RFC8986] 774 2001:db8:K:100:1::. To monitor any arbitrary SRv6 paths, the 775 controller can create a loopback probe that originates and terminates 776 on Node N100. To distinguish between a failure in the monitored path 777 and loss of connectivity between the controller and the network, Node 778 N100 runs a suitable mechanism to monitor its connectivity to the 779 monitored network. 781 The loopback probes are exemplified using an example where controller 782 N100 needs to verify a segment list <2001:db8:K:2:X31::, 783 2001:db8:K:4:X52::>: 785 o N100 generates an OAM packet (2001:db8:L:100::, 786 2001:db8:K:2:X31::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 787 2001:db8:K:2:X31::, SL=2)(OAM Payload). The controller routes the 788 probe packet towards the first segment, which is 789 2001:db8:K:2:X31::. 791 o Node N2 executes the End.X behavior indicated by the 792 2001:db8:K:2:X31:: SID and forwards the packet (2001:db8:L:100::, 793 2001:db8:K:4:X52::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 794 2001:db8:K:2:X31::, SL=1)(OAM Payload) on link3 to N3. 796 o Node N3, which is a non-SRv6 capable node, performs the standard 797 IPv6 processing. Specifically, it forwards the packet based on 798 the DA 2001:db8:K:4:X52:: in the IPv6 header. 800 o Node N4 executes the End.X behavior indicated by the 801 2001:db8:K:4:X52:: SID and forwards the packet (2001:db8:L:100::, 802 2001:db8:K:100:1::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 803 2001:db8:K:2:X31::, SL=0)(OAM Payload) on link10 to N5. 805 o Node N5, which is a non-SRv6 capable node, performs the standard 806 IPv6 processing. Specifically, it forwards the packet based on 807 the DA 2001:db8:K:100:1:: in the IPv6 header. 809 o Node N100 executes the standard SRv6 END behavior. It 810 decapsulates the header and consume the probe for OAM processing. 811 The information in the OAM payload is used to detect any missing 812 probes, round trip delay, etc. 814 The OAM payload type or the information carried in the OAM probe is a 815 local implementation decision at the controller and is outside the 816 scope of this document. 818 4. Implementation Status 820 This section is to be removed prior to publishing as an RFC. 822 See [I-D.matsushima-spring-srv6-deployment-status] for updated 823 deployment and interoperability reports. 825 5. Security Considerations 827 [RFC8754] defines the notion of an SR domain and use of SRH within 828 the SR domain. The use of OAM procedures described in this document 829 is restricted to an SR domain. For example, similar to the SID 830 manipulation, O-flag manipulation is not considered as a threat 831 within the SR domain. Procedures for securing an SR domain are 832 defined the section 5.1 and section 7 of [RFC8754]. 834 As noted in section 7.1 of [RFC8754], compromised nodes within the SR 835 domain may mount attacks. The O-flag may be set by an attacking node 836 attempting a denial-of-service attack on the OAM process at the 837 segment endpoint node. An implementation correctly implementing the 838 rate limiting in section 2.1.1 is not susceptible to that denial-of- 839 service attack. Additionally, SRH Flags are protected by the HMAC 840 TLV, as described in Section 2.1.2.1 of [RFC8754]. Once an HMAC is 841 generated for a segment list with the O-flag set, it can be used for 842 an arbitrary amount of traffic using that segment list with O-flag 843 set. 845 The security properties of the channel used to send exported packets 846 marked by the O-flag will depend on the specific OAM processes used. 847 An on-path attacker able to observe this OAM channel could conduct 848 traffic analysis, or potentially eavesdropping (depending on the OAM 849 configuration), of this telemetry for the entire SR domain from such 850 a vantage point. 852 This document does not impose any additional security challenges to 853 be considered beyond security threats described in [RFC4884], 854 [RFC4443], [RFC0792], [RFC8754] and [RFC8986]. 856 6. Privacy Considerations 858 The per-packet marking capabilities of the O-flag provides a granular 859 mechanism to collect telemetry. When this collection is deployed by 860 an operator with knowledge and consent of the users, it will enable a 861 variety of diagnostics and monitoring to support the OAM and security 862 operations use cases needed for resilient network operations. 863 However, this collection mechanism will also provide an explicit 864 protocol mechanism to operators for surveillance and pervasive 865 monitoring use cases done contrary to the user's consent. 867 7. IANA Considerations 869 This document requests that IANA allocate the following registration 870 in the "Segment Routing Header Flags" sub-registry for the "Internet 871 Protocol Version 6 (IPv6) Parameters" registry maintained by IANA: 873 +-------+------------------------------+---------------+ 874 | Bit | Description | Reference | 875 +=======+==============================+===============+ 876 | 2 | O-flag | This document | 877 +-------+------------------------------+---------------+ 879 8. Acknowledgements 881 The authors would like to thank Joel M. Halpern, Greg Mirsky, Bob 882 Hinden, Loa Andersson, Gaurav Naik, Ketan Talaulikar and Haoyu Song 883 for their review comments. 885 9. Contributors 887 The following people have contributed to this document: 889 Robert Raszuk 890 Bloomberg LP 891 Email: robert@raszuk.net 893 John Leddy 894 Individual 895 Email: john@leddy.net 897 Gaurav Dawra 898 LinkedIn 899 Email: gdawra.ietf@gmail.com 901 Bart Peirens 902 Proximus 903 Email: bart.peirens@proximus.com 905 Nagendra Kumar 906 Cisco Systems, Inc. 907 Email: naikumar@cisco.com 909 Carlos Pignataro 910 Cisco Systems, Inc. 911 Email: cpignata@cisco.com 913 Rakesh Gandhi 914 Cisco Systems, Inc. 915 Canada 916 Email: rgandhi@cisco.com 917 Frank Brockners 918 Cisco Systems, Inc. 919 Germany 920 Email: fbrockne@cisco.com 922 Darren Dukes 923 Cisco Systems, Inc. 924 Email: ddukes@cisco.com 926 Cheng Li 927 Huawei 928 Email: chengli13@huawei.com 930 Faisal Iqbal 931 Individual 932 Email: faisal.ietf@gmail.com 934 10. References 936 10.1. Normative References 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 944 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 945 May 2017, . 947 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 948 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 949 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 950 . 952 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 953 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 954 (SRv6) Network Programming", RFC 8986, 955 DOI 10.17487/RFC8986, February 2021, 956 . 958 10.2. Informative References 960 [I-D.gandhi-spring-stamp-srpm] 961 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 962 B., and R. Foote, "Performance Measurement Using Simple 963 TWAMP (STAMP) for Segment Routing Networks", draft-gandhi- 964 spring-stamp-srpm-07 (work in progress), July 2021. 966 [I-D.ietf-ippm-ioam-data] 967 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 968 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 969 progress), November 2020. 971 [I-D.matsushima-spring-srv6-deployment-status] 972 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 973 Rajaraman, "SRv6 Implementation and Deployment Status", 974 draft-matsushima-spring-srv6-deployment-status-11 (work in 975 progress), February 2021. 977 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 978 RFC 792, DOI 10.17487/RFC0792, September 1981, 979 . 981 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 982 DOI 10.17487/RFC2328, April 1998, 983 . 985 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 986 Control Message Protocol (ICMPv6) for the Internet 987 Protocol Version 6 (IPv6) Specification", STD 89, 988 RFC 4443, DOI 10.17487/RFC4443, March 2006, 989 . 991 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 992 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 993 DOI 10.17487/RFC4884, April 2007, 994 . 996 [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet 997 Sampling (PSAMP) Protocol Specifications", RFC 5476, 998 DOI 10.17487/RFC5476, March 2009, 999 . 1001 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 1002 N., and JR. Rivers, "Extending ICMP for Interface and 1003 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 1004 April 2010, . 1006 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1007 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1008 . 1010 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1011 "Specification of the IP Flow Information Export (IPFIX) 1012 Protocol for the Exchange of Flow Information", STD 77, 1013 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1014 . 1016 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1017 for IP Flow Information Export (IPFIX)", RFC 7012, 1018 DOI 10.17487/RFC7012, September 2013, 1019 . 1021 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1022 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1023 May 2016, . 1025 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 1026 Pallagatti, "Seamless Bidirectional Forwarding Detection 1027 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 1028 . 1030 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1031 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1032 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1033 July 2018, . 1035 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 1036 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 1037 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 1038 2018, . 1040 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1041 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1042 IGP Traffic Engineering Performance Metric Extensions", 1043 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1044 . 1046 Authors' Addresses 1048 Zafar Ali 1049 Cisco Systems 1051 Email: zali@cisco.com 1052 Clarence Filsfils 1053 Cisco Systems 1055 Email: cfilsfil@cisco.com 1057 Satoru Matsushima 1058 Softbank 1060 Email: satoru.matsushima@g.softbank.co.jp 1062 Daniel Voyer 1063 Bell Canada 1065 Email: daniel.voyer@bell.ca 1067 Mach Chen 1068 Huawei 1070 Email: mach.chen@huawei.com