idnits 2.17.1 draft-ietf-6man-spring-srv6-oam-05.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 (June 12, 2020) is 1407 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) == Missing Reference: 'SL' is mentioned on line 198, but not defined -- Looks like a reference, but probably isn't: '2' on line 199 -- Looks like a reference, but probably isn't: '1' on line 200 -- Looks like a reference, but probably isn't: '0' on line 200 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). 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: December 14, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 June 12, 2020 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-05 17 Abstract 19 This document describes how the existing IPv6 OAM mechanisms can be 20 used in an SRv6 network. The document also introduces enhancements 21 for controller-based OAM mechanisms for SRv6 networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 14, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Terminology and Reference Topology . . . . . . . . . . . 3 61 2. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 63 2.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 64 3. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Ping in SRv6 Networks . . . . . . . . . . . . . . . . . . 7 66 3.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 7 67 3.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 10 70 3.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 11 71 3.3. A Controller-Based Hybrid OAM Using O-flag . . . . . . . 13 72 3.4. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 15 73 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Segment Routing Header Flags . . . . . . . . . . . . . . 17 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 9.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 As Segment Routing with IPv6 data plane (SRv6) simply adds a new type 87 of Routing Extension Header, existing IPv6 OAM mechanisms can be used 88 in an SRv6 network. This document describes how the existing IPv6 89 mechanisms for ping and trace route can be used in an SRv6 network. 91 The document also introduces enhancements for controller-based OAM 92 mechanism for SRv6 networks. Specifically, the document describes an 93 OAM mechanism for performing controllable and predictable flow 94 sampling from segment endpoints using, e.g., IP Flow Information 95 Export (IPFIX) protocol [RFC7011]. The document also outlines how 96 centralized OAM technique in [RFC8403] can be extended for SRv6 to 97 perform a path continuity check between any nodes within an SRv6 98 domain from a centralized monitoring system, with minimal or no 99 control plane intervene on the nodes. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119], [RFC8174]. 107 1.2. Abbreviations 109 The following abbreviations are used in this document: 111 SID: Segment ID. 113 SL: Segments Left. 115 SR: Segment Routing. 117 SRH: Segment Routing Header. 119 SRv6: Segment Routing with IPv6 Data plane. 121 TC: Traffic Class. 123 ICMPv6: ICMPv6 Specification [RFC4443]. 125 1.3. Terminology and Reference Topology 127 This document uses the terminology defined in [I-D.ietf- spring-srv6- 128 network-programming]. The readers are expected to be familiar with 129 the same. 131 Throughout the document, the following simple topology is used for 132 illustration. 134 +--------------------------| N100 |---------------------------------+ 135 | | 136 | ====== link1====== link3------ link5====== link9------ ====== | 137 ||N1||------||N2||------| N3 |------||N4||------| N5 |---||N7|| 138 || ||------|| ||------| |------|| ||------| |---|| || 139 ====== link2====== link4------ link6======link10------ ====== 140 | | | | 141 ---+-- | ------ | --+--- 142 |CE 1| +-------| N6 |---------+ |CE 2| 143 ------ link7 | | link8 ------ 144 ------ 146 Figure 1 Reference Topology 148 In the reference topology: 150 Node k has a classic IPv6 loopback address 2001:DB8:A:k::/128. 152 Nodes N1, N2, and N4 are SRv6 capable nodes. 154 Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6 capable. 155 Such nodes are referred as classic IPv6 nodes. 157 A SID at node k with locator block 2001:DB8:B::/48 and function F 158 is represented by 2001:DB8:B:k:F::. 160 Node N100 is a controller. 162 The IPv6 address of the nth Link between node X and Y at the X 163 side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address 164 of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 165 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 166 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 168 2001:DB8:B:k:Cij:: is explicitly allocated as the END.X function 169 at node k towards neighbor node i via jth Link between node i and 170 node k. e.g., 2001:DB8:B:2:C31:: represents END.X at N2 towards 171 N3 via link3 (the 1st link between N2 and N3). Similarly, 172 2001:DB8:B:4:C52:: represents the END.X at N4 towards N5 via 173 link10. 175 A SID list is represented as where S1 is the first 176 SID to visit, S2 is the second SID to visit and S3 is the last SID 177 to visit along the SR path. 179 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 181 * IPv6 header with source address SA, destination addresses DA 182 and SRH as next-header 184 * SRH with SID list with SegmentsLeft = SL 186 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 188 the last SID to traverse. (S3, S2, S1; SL) represents the same 189 SID list but encoded in the SRH format where the rightmost SID 190 in the SRH is the first SID and the leftmost SID in the SRH is 191 the last SID. When referring to an SR policy in a high-level 192 use-case, it is simpler to use the notation. When 193 referring to an illustration of the detailed packet behavior, 194 the (S3, S2, S1; SL) notation is more convenient. 196 * (payload) represents the the payload of the packet. 198 SRH[SL] represents the SID pointed by the SL field in the first 199 SRH. In our example SID list (S3, S2, S1; SL), SRH[2] represents 200 S1, SRH[1] represents S2 and SRH[0] represents S3. 202 2. OAM Mechanisms 204 This section defines OAM enhancement for the SRv6 networks. 206 2.1. O-flag in Segment Routing Header 208 [RFC8754] describes the Segment Routing Header (SRH) and how SR 209 capable nodes use it. The SRH contains an 8-bit "Flags" field. This 210 document defines the following bit in the SRH.Flags to carry the 211 O-flag: 213 0 1 2 3 4 5 6 7 214 +-+-+-+-+-+-+-+-+ 215 | |O| | 216 +-+-+-+-+-+-+-+-+ 218 Where: 220 O-flag: OAM flag. 222 The document does not define any other flag in the SRH.Flags and 223 meaning and processing of any other bit in SRH.Flags is outside of 224 the scope of this document. 226 2.1.1. O-flag Processing 228 The O-flag in SRH is used as a marking-bit in the user packets to 229 trigger the telemetry data collection and export at the segment 230 endpoints. 232 Without the loss of generality, this document assumes IP Flow 233 Information Export (IPFIX) protocol [RFC7011] is used for exporting 234 the traffic flow information from the network devices to a controller 235 for monitoring and analytics. The requested information elements are 236 configured by the management plane through data set templates (e.g., 237 as in IPFIX [RFC7012]). 239 Implementation of the O-flag is OPTIONAL. If a node does not support 240 the O-flag, then upon reception it simply ignores it. If a node 241 supports the O-flag, it can optionally advertise its potential via 242 control plan protocol(s). 244 When N receives a packet whose IPv6 DA is S and S is a local SID, the 245 line S01 of the pseudo-code associated with the SID S, as defined in 246 section 4.3.1.1 of [RFC8754], is modified as follows for the O-flag 247 processing. 249 S01.1. IF SRH.Flags.O-flag is set and local configuration permits 250 O-flag processing THEN 251 a. Make a copy of the packet. 252 b. Send the copied packet, along with a timestamp 253 to the OAM process for telemetry data collection 254 and export. ;; Ref1 255 Ref1: An implementation SHOULD copy and record the timestamp as 256 soon as possible during packet processing. Timestamp or any other 257 metadata is not 258 carried in the packet forwarded to the next hop. 260 Please note that the O-flag processing happens before execution of 261 regular processing of the local SID S. 263 Based on the requested information elements configured by the 264 management plane through data set templates [RFC7012], the OAM 265 process exports the requested information elements. The information 266 elements include parts of the packet header and/or parts of the 267 packet payload for flow identification. The OAM process uses 268 information elements defined in IPFIX [RFC7011] and PSAMP [RFC5476] 269 for exporting the requested sections of the mirrored packets. 271 If the telemetry data from the last node in the segment-list (egress 272 node) is desired, the ingress uses an Ultimate Segment Pop (USP) SID 273 advertised by the egress node. 275 The processing node SHOULD rate-limit the number of packets punted to 276 the OAM process to avoid hitting any performance impact. 278 The OAM process MUST NOT process the copy of the packet or respond to 279 any upper-layer header (like ICMP, UDP, etc.) payload to prevent 280 multiple evaluations of the datagram. 282 Specification of the OAM process or the external controller 283 operations are beyond the scope of this document. section 3 284 illustrates use of the SRH.Flags.O-flag for implementing a 285 controller-based hybrid OAM mechanism, where the "hybrid" 286 classification is based on RFC7799 [RFC7799]. The illustration is 287 different than the In-situ OAM defined in [I.D-draft-ietf-ippm-ioam- 288 data]. This is because In-situ OAM records operational and telemetry 289 information in the packet as the packet traverses a path between two 290 points in the network [I.D-draft-ietf- ippm-ioam-data]. The 291 controller-based OAM mechanism using O-flag illustration in section 3 292 does not require the recording of OAM data in the packet. 294 3. Illustrations 296 This section shows how some of the existing IPv6 OAM mechanisms can 297 be used in an SRv6 network. It also illustrates an OAM mechanism for 298 performing controllable and predictable flow sampling from segment 299 endpoints. How centralized OAM technique in [RFC8403] can be 300 extended for SRv6 is also described in this Section. 302 3.1. Ping in SRv6 Networks 304 The following subsections outline some use cases of the ICMP ping in 305 the SRv6 networks. 307 3.1.1. Classic Ping 309 The existing mechanism to query liveliness of a remote IP address, 310 along the shortest path, continues to work without any modification. 311 The initiator may be an SRv6 node or a classic IPv6 node. Similarly, 312 the egress or transit may be an SRv6 capable node or a classic IPv6 313 node. 315 If an SRv6 capable ingress node wants to ping an IPv6 address via an 316 arbitrary segment list , it needs to initiate ICMPv6 ping 317 with an SR header containing the SID list . This is 318 illustrated using the topology in Figure 1. Assume all the links 319 have IGP metric 10 except both links between node2 and node3, which 320 have IGP metric set to 100. User issues a ping from node N1 to a 321 loopback of node 5, via segment list <2001:DB8:B:2:C31::, 322 2001:DB8:B:4:C52::>. 324 Figure 2 contains sample output for a ping request initiated at node 325 N1 to the loopback address of node N5 via a segment list 326 <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. 328 > ping 2001:DB8:A:5:: via segment-list 2001:DB8:B:2:C31::, 329 2001:DB8:B:4:C52:: 331 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 332 !!!!! 333 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 334 /0.749/0.931 ms 336 Figure 2 A sample ping output at an SRv6 capable node 338 All transit nodes process the echo request message like any other 339 data packet carrying SR header and hence do not require any change. 340 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 341 require any change to process the ICMPv6 echo request. For example, 342 in the ping example of Figure 2: 344 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 345 (2001:DB8:A:1::, 2001:DB8:B:2:C31::) (2001:DB8:A:5::, 346 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=2, NH = ICMPv6)(ICMPv6 347 Echo Request). If 2001:DB8:B:4:C52:: is a PSP SID, the OAM probes 348 encodes the PSP SID in the packet (just mimicking data packets). 349 No special consideration is needed to handle PSP SIDs. 351 o Node N2, which is an SRv6 capable node, performs the standard SRH 352 processing. Specifically, it executes the END.X function 353 (2001:DB8:B:2:C31::) and forwards the packet on link3 to N3. 355 o Node N3, which is a classic IPv6 node, performs the standard IPv6 356 processing. Specifically, it forwards the echo request based on 357 the DA 2001:DB8:B:4:C52:: in the IPv6 header. 359 o Node N4, which is an SRv6 capable node, performs the standard SRH 360 processing. Specifically, it observes the END.X function 361 (2001:DB8:B:4:C52::) and forwards the packet on link10 towards N5. 362 If 2001:DB8:B:4:C52:: is a PSP SID, The penultimate node (Node N4) 363 does not, should not and cannot differentiate between the data 364 packets and OAM probes. Specifically, if 2001:DB8:B:4:C52:: is a 365 PSP SID, node N4 executes the SID like any other data packet with 366 DA = 2001:DB8:B:4:C52:: and removes the SRH. 368 o The echo request packet at N5 arrives as an IPv6 packet with or 369 without an SRH. If N5 receives the packet with SRH, it skips SRH 370 processing (SL=0). In either case, Node N5 performs the standard 371 IPv6/ ICMPv6 processing on the echo request. 373 3.1.2. Pinging a SID 375 The classic ping described in the previous section applies equally to 376 ping a remote SID function, as explained using an example in the 377 following. 379 Consider the example where the user wants to ping a remote SID 380 function 2001:DB8:B:4::, via 2001:DB8:B:2:C31::, from node N1. The 381 ICMPv6 echo request is processed at the individual nodes along the 382 path as follows: 384 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 385 (2001:DB8:A:1::, 2001:DB8:B:2:C31::) (2001:DB8:B:4::, 386 2001:DB8:B:2:C31::; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). If 387 2001:DB8:B:2:C31:: is a PSP SID, the OAM probes encodes the PSP 388 SID in the packet (just mimicking data packets). No special 389 consideration is needed to handle PSP SIDs. 391 o Node N2, which is an SRv6 capable node, performs the standard SRH 392 processing. Specifically, it executes the END.X function 393 (2001:DB8:B:2:C31::) on the echo request packet. If 394 2001:DB8:B:2:C31:: is a PSP SID, node N4 executes the SID like any 395 other data packet with DA = 2001:DB8:B:2:C31:: and removes the 396 SRH. 398 o Node N3, which is a classic IPv6 node, performs the standard IPv6 399 processing. Specifically, it forwards the echo request based on 400 DA = 2001:DB8:B:4:: in the IPv6 header. 402 o When node N4 receives the packet, it processes the 2001:DB8:B:4:: 403 SID, as described in the pseudocode in [I-D.ietf-spring-srv6- 404 network-programming]. 406 o If the 2001:DB8:B:4:: SID is not locally programmed, the packet is 407 discarded 409 o If the target SID (2001:DB8:B:4::) is locally programmed, the node 410 processes the upper layer header. As part of the upper layer 411 header processing node N4 respond to the ICMPv6 echo request 412 message. 414 3.2. Traceroute 416 There is no hardware or software change required for traceroute 417 operation at the classic IPv6 nodes in an SRv6 network. That 418 includes the classic IPv6 node with ingress, egress or transit roles. 419 Furthermore, no protocol changes are required to the standard 420 traceroute operations. In other words, existing traceroute 421 mechanisms work seamlessly in the SRv6 networks. 423 The following subsections outline some use cases of the traceroute in 424 the SRv6 networks. 426 3.2.1. Classic Traceroute 428 The existing mechanism to traceroute a remote IP address, along the 429 shortest path, continues to work without any modification. The 430 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 431 egress or transit may be an SRv6 node or a classic IPv6 node. 433 If an SRv6 capable ingress node wants to traceroute to IPv6 address 434 via an arbitrary segment list , it needs to initiate 435 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 437 the links have IGP metric 10 except both links between node2 and 438 node3, which have IGP metric set to 100. User issues a traceroute 439 from node N1 to a loopback of node 5, via segment list 440 <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. Figure 3 contains sample 441 output for the traceroute request. 443 > traceroute 2001:DB8:A:5:: via segment-list 2001:DB8:B:2:C31::, 444 2001:DB8:B:4:C52:: 446 Tracing the route to 2001:DB8:A:5:: 447 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 448 DA: 2001:DB8:B:2:C31::, 449 SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=2) 450 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 451 DA: 2001:DB8:B:4:C52::, 452 SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=1) 453 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 454 DA: 2001:DB8:B:4:C52::, 455 SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=1) 456 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 457 DA: 2001:DB8:A:5:: 459 Figure 3 A sample traceroute output at an SRv6 capable node 461 Please note that information for hop2 is returned by N3, which is a 462 classic IPv6 node. Nonetheless, the ingress node is able to display 463 SR header contents as the packet travels through the IPv6 classic 464 node. This is because the "Time Exceeded Message" ICMPv6 message can 465 contain as much of the invoking packet as possible without the ICMPv6 466 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 467 also included in these ICMPv6 messages initiated by the classic IPv6 468 transit nodes that are not running SRv6 software. Specifically, a 469 node generating ICMPv6 message containing a copy of the invoking 470 packet does not need to understand the extension header(s) in the 471 invoking packet. 473 The segment list information returned for hop1 is returned by N2, 474 which is an SRv6 capable node. Just like for hop2, the ingress node 475 is able to display SR header contents for hop1. 477 There is no difference in processing of the traceroute probe at an 478 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 479 classic and SRv6 capable nodes may use the address of the interface 480 on which probe was received as the source address in the ICMPv6 481 response. ICMP extensions defined in [RFC5837] can be used to also 482 display information about the IP interface through which the datagram 483 would have been forwarded had it been forwardable, and the IP next 484 hop to which the datagram would have been forwarded, the IP interface 485 upon which a datagram arrived, the sub-IP component of an IP 486 interface upon which a datagram arrived. 488 The information about the IP address of the incoming interface on 489 which the traceroute probe was received by the reporting node is very 490 useful. This information can also be used to verify if SID functions 491 2001:DB8:B:2:C31:: and 2001:DB8:B:4:C52:: are executed correctly by 492 N2 and N4, respectively. Specifically, the information displayed for 493 hop2 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 494 This matches with the expected interface bound to END.X function 495 2001:DB8:B:2:C31:: (link3). Similarly, the information displayed for 496 hop5 contains the incoming interface address 2001:DB8:4:5::52:: at 497 N5. This matches with the expected interface bound to the END.X 498 function 2001:DB8:B:4:C52:: (link10). 500 3.2.2. Traceroute to a SID 502 The classic traceroute described in the previous section applies 503 equally to traceroute a remote SID function, as explained using an 504 example in the following. 506 Please note that traceroute to a SID function is exemplified using 507 UDP probes. However, the procedure is equally applicable to other 508 implementations of traceroute mechanism. 510 Consider the example where the user wants to traceroute a remote SID 511 function 2001:DB8:B:4::, via 2001:DB8:B:2:C31::, from node N1. The 512 traceroute probe is processed at the individual nodes along the path 513 as follows: 515 o Node N1 initiates a traceroute probe packet with a monotonically 516 increasing value of hop count and SRH as follows (2001:DB8:A:1::, 517 2001:DB8:B:2:C31::) (2001:DB8:B:4::, 2001:DB8:B:2:C31::; SL=1; 518 NH=UDP)(Traceroute probe). If 2001:DB8:B:2:C31:: is a PSP SID, 519 the OAM probes encodes the PSP SID in the packet (just mimicking 520 data packets). No special consideration is needed to handle PSP 521 SIDs. 523 o When node N2 receives the packet with hop-count = 1, it processes 524 the hop count expiry. Specifically, the node N2 responses with 525 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 526 exceeded in Transit"). 528 o When Node N2 receives the packet with hop-count > 1, it performs 529 the standard SRH processing. Specifically, it executes the END.X 530 function (2001:DB8:B:2:C31::) on the traceroute probe. If 531 2001:DB8:B:2:C31:: is a PSP SID, node N4 executes the SID like any 532 other data packet with DA = 2001:DB8:B:2:C31:: and removes the 533 SRH. 535 o When node N3, which is a classic IPv6 node, receives the packet 536 with hop-count = 1, it processes the hop count expiry. 537 Specifically, the node N3 responses with the ICMPv6 message (Type: 538 "Time Exceeded", Code: "Time to Live exceeded in Transit"). 540 o When node N3, which is a classic IPv6 node, receives the packet 541 with hop-count > 1, it performs the standard IPv6 processing. 542 Specifically, it forwards the traceroute probe based on DA 543 2001:DB8:B:4:: in the IPv6 header. 545 o When node N4 receives the packet with DA set to the local SID 546 2001:DB8:B:4::, it processes the END SID, as described in the 547 pseudocode in [I-D.ietf-spring-srv6-network-programming]. 549 o If the 2001:DB8:B:4:: SID is not locally programmed, the packet is 550 discarded. 552 o If the target SID (2001:DB8:B:4::) is locally programmed, the node 553 processes the upper layer header. As part of the upper layer 554 header processing node N4 responses with the ICMPv6 message (Type: 555 Destination unreachable, Code: Port Unreachable). 557 Figure 4 displays a sample traceroute output for this example. 559 > traceroute 2001:DB8:B:4:C52:: via segment-list 2001:DB8:B:2:C31:: 561 Tracing the route to SID function 2001:DB8:B:4:C52:: 562 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 563 DA: 2001:DB8:B:2:C31::, 564 SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=1) 565 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 566 DA: 2001:DB8:B:4:C52::, 567 SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=0) 568 3 2001:DB8:3:4:41:: 0.921 msec 0.816 msec 0.759 msec 569 DA: 2001:DB8:B:4:C52::, 570 SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=0) 572 Figure 4 A sample output for hop-by-hop traceroute to a SID 574 3.3. A Controller-Based Hybrid OAM Using O-flag 576 Consider the example where the user wants to monitor sampled IPv4 VPN 577 100 traffic going from CE1 to CE2 via a low latency SR policy P 578 installed at Node N1. To exercise a low latency path, the SR Policy 579 P forces the packet via segments 2001:DB8:B:2:C31:: and 580 2001:DB8:B:4:C52::. The VPN SID at N7 associated with VPN100 is 581 2001:DB8:B:7:DT100::. 2001:DB8:B:7:DT100:: is a USP SID. N1, N4, 582 and N7 are capable of processing SRH.Flags.O-flag but N2 is not 583 capable of processing SRH.Flags.O-flag. N100 is the centralized 584 controller capable of processing and correlating the copy of the 585 packets sent from nodes N1, N4, and N7. N100 is aware of 586 SRH.Flags.O-flag processing capabilities. Controller N100 with the 587 help from nodes N1, N4, N7 and implements a hybrid OAM mechanism 588 using the SRH.Flags.O-flag as follows: 590 o A packet P1:(IPv4 header)(payload) is sent from CE1 to Node N1. 592 o Node N1 steers the packet P1 through the Policy P. Based on a 593 local configuration, Node N1 also implements logic to sample 594 traffic steered through policy P for hybrid OAM purposes. 595 Specification for the sampling logic is beyond the scope of this 596 document. Consider the case where packet P1 is classified as a 597 packet to be monitored via the hybrid OAM. Node N1 sets 598 SRH.Flags.O-flag during encapsulation required by policy P. As 599 part of setting the SRH.Flags.O-flag, node N1 also send a 600 timestamped copy of the packet P1: (2001:DB8:A:1::, 601 2001:DB8:B:2:C31::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, 602 2001:DB8:B:2:C31::; SL=2; O-flag=1; NH=IPv4)(IPv4 header)(payload) 603 to a local OAM process. The local OAM process sends a full or 604 partial copy of the packet P1 to the controller N100. The OAM 605 process includes the recorded timestamp, additional OAM 606 information like incoming and outgoing interface, etc. along with 607 any applicable metadata. Node N1 forwards the original packet 608 towards the next segment 2001:DB8:B:2:C31::. 610 o When node N2 receives the packet with SRH.Flags.O-flag set, it 611 ignores the SRH.Flags.O-flag. This is because node N2 is not 612 capable of processing the O-flag. Node N2 performs the standard 613 SRv6 SID and SRH processing. Specifically, it executes the END.X 614 function (2001:DB8:B:2:C31::) and forwards the packet P1 615 (2001:DB8:A:1::, 2001:DB8:B:4:C52::) (2001:DB8:B:7:DT100::, 616 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=1; O-flag=1; 617 NH=IPv4)(IPv4 header)(payload) over link 3 towards Node N3. 619 o When node N3, which is a classic IPv6 node, receives the packet P1 620 , it performs the standard IPv6 processing. Specifically, it 621 forwards the packet P1 based on DA 2001:DB8:B:4:C52:: in the IPv6 622 header. 624 o When node N4 receives the packet P1 (2001:DB8:A:1::, 625 2001:DB8:B:4:C52::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, 626 2001:DB8:B:2:C31::; SL=1; O-flag=1; NH=IPv4)(IPv4 627 header)(payload), it processes the SRH.Flags.O-flag. As part of 628 processing the O-flag, it sends a timestamped copy of the packet 629 to a local OAM process. The local OAM process sends a full or 630 partial copy of the packet P1 to the controller N100. The OAM 631 process includes the recorded timestamp, additional OAM 632 information like incoming and outgoing interface, etc. along with 633 any applicable metadata. Node N4 performs the standard SRv6 SID 634 and SRH processing on the original packet P1. Specifically, it 635 executes the END.X function (2001:DB8:B:4:C52::) and forwards the 636 packet P1 (2001:DB8:A:1::, 2001:DB8:B:7:DT100::) 637 (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; 638 SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload) over link 10 639 towards Node N5. 641 o When node N5, which is a classic IPv6 node, receives the packet 642 P1, it performs the standard IPv6 processing. Specifically, it 643 forwards the packet based on DA 2001:DB8:B:7:DT100:: in the IPv6 644 header. 646 o When node N7 receives the packet P1 (2001:DB8:A:1::, 647 2001:DB8:B:7:DT100::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, 648 2001:DB8:B:2:C31::; SL=0; O-flag=1; NH=IPv4)(IPv4 649 header)(payload), it processes the SRH.Flags.O-flag. As part of 650 processing the O-flag, it sends a timestamped copy of the packet 651 to a local OAM process. The local OAM process sends a full or 652 partial copy of the packet P1 to the controller N100. The OAM 653 process includes the recorded timestamp, additional OAM 654 information like incoming and outgoing interface, etc. along with 655 any applicable metadata. Node N4 performs the standard SRv6 SID 656 and SRH processing on the original packet P1. Specifically, it 657 executes the VPN SID (2001:DB8:B:7:DT100::) and based on lookup in 658 table 100 forwards the packet P1 (IPv4 header)(payload) towards CE 659 2. 661 o The controller N100 processes and correlates the copy of the 662 packets sent from nodes N1, N4 and N7 to find segment-by-segment 663 delays and provide other hybrid OAM information related to packet 664 P1. 666 o The process continues for any other sampled packets. 668 3.4. Monitoring of SRv6 Paths 670 In the recent past, network operators are interested in performing 671 network OAM functions in a centralized manner. [RFC8403] describes 672 such a centralized OAM mechanism. Specifically, the document 673 describes a procedure that can be used to perform path continuity 674 check between any nodes within an SR domain from a centralized 675 monitoring system, with minimal or no control plane intervene on the 676 nodes. However, the document focuses on SR networks with MPLS data 677 plane. This document describes how the concept can be used to 678 perform path monitoring in an SRv6 network from the centralized 679 controller. 681 In the reference topology in Figure 1, N100 uses an IGP protocol like 682 OSPF or ISIS to get the topology view within the IGP domain. N100 683 can also use BGP-LS to get the complete view of an inter-domain 684 topology. The controller leverages the visibility of the topology to 685 monitor the paths between the various endpoints without control plane 686 intervention required at the monitored nodes. 688 The controller N100 advertises an END SID 2001:DB8:B:100:1::. To 689 monitor any arbitrary SRv6 paths, the controller can create a 690 loopback probe that originates and terminates on Node N100. For 691 example, in order to verify a segment list <2001:DB8:B:2:C31::, 692 2001:DB8:B:4:C52::>: 694 o N100 generates an OAM packet (2001:DB8:A:100::, 695 2001:DB8:B:2:C31::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, 696 2001:DB8:B:2:C31::, SL=2)(OAM Payload). The controller routes the 697 probe packet towards the first segment, which is 698 2001:DB8:B:2:C31::. 700 o Node N2 executes the END.X function (2001:DB8:B:2:C31::) and 701 forwards the packet (2001:DB8:A:100::, 702 2001:DB8:B:4:C52::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, 703 2001:DB8:B:2:C31::, SL=1)(OAM Payload) on link3 to N3. 705 o Node N3, which is a classic IPv6 node, performs the standard IPv6 706 processing. Specifically, it forwards the packet based on the DA 707 2001:DB8:B:4:C52:: in the IPv6 header. 709 o Node N4 executes the END.X function (2001:DB8:B:4:C52::) and 710 forwards the packet (2001:DB8:A:100::, 711 2001:DB8:B:100:1::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, 712 2001:DB8:B:2:C31::, SL=0)(OAM Payload) on link10 to N5. 714 o Node N5, which is a classic IPv6 node, performs the standard IPv6 715 processing. Specifically, it forwards the packet based on the DA 716 2001:DB8:B:100:1:: in the IPv6 header. 718 o Node N100 executes the standard SRv6 END function. It 719 decapsulates the header and consume the probe for OAM processing. 720 The information in the OAM payload is used to detect any missing 721 probes, round trip delay, etc. 723 The OAM payload type or the information carried in the OAM probe is a 724 local implementation decision at the controller and is outside the 725 scope of this document. 727 4. Implementation Status 729 This section is to be removed prior to publishing as an RFC. 731 See [I-D.matsushima-spring-srv6-deployment-status] for updated 732 deployment and interoperability reports. 734 5. Security Considerations 736 This document does not define any new protocol extensions and relies 737 on existing procedures defined for ICMP. This document does not 738 impose any additional security challenges to be considered beyond 739 security considerations described in [RFC4884], [RFC4443], [RFC0792], 740 and [RFC8754]. 742 6. IANA Considerations 743 6.1. Segment Routing Header Flags 745 This I-D requests to IANA to allocate bit position 2, within the 746 "Segment Routing Header Flags" registry defined in [RFC8754]. 748 7. Acknowledgements 750 The authors would like to thank Joel M. Halpern, Greg Mirsky, Bob 751 Hinden, Loa Andersson and Gaurav Naik for their review comments. 753 8. Contributors 755 The following people have contributed to this document: 757 Robert Raszuk 758 Bloomberg LP 759 Email: robert@raszuk.net 761 John Leddy 762 Individual 763 Email: john@leddy.net 765 Gaurav Dawra 766 LinkedIn 767 Email: gdawra.ietf@gmail.com 769 Bart Peirens 770 Proximus 771 Email: bart.peirens@proximus.com 773 Nagendra Kumar 774 Cisco Systems, Inc. 775 Email: naikumar@cisco.com 777 Carlos Pignataro 778 Cisco Systems, Inc. 779 Email: cpignata@cisco.com 780 Rakesh Gandhi 781 Cisco Systems, Inc. 782 Canada 783 Email: rgandhi@cisco.com 785 Frank Brockners 786 Cisco Systems, Inc. 787 Germany 788 Email: fbrockne@cisco.com 790 Darren Dukes 791 Cisco Systems, Inc. 792 Email: ddukes@cisco.com 794 Cheng Li 795 Huawei 796 Email: chengli13@huawei.com 798 Faisal Iqbal 799 Individual 800 Email: faisal.ietf@gmail.com 802 9. References 804 9.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 812 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 813 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 814 . 816 9.2. Informative References 818 [I-D.ietf-spring-srv6-network-programming] 819 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 820 Matsushima, S., and Z. Li, "SRv6 Network Programming", 821 draft-ietf-spring-srv6-network-programming-15 (work in 822 progress), March 2020. 824 [I-D.matsushima-spring-srv6-deployment-status] 825 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 826 Rajaraman, "SRv6 Implementation and Deployment Status", 827 draft-matsushima-spring-srv6-deployment-status-07 (work in 828 progress), April 2020. 830 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 831 RFC 792, DOI 10.17487/RFC0792, September 1981, 832 . 834 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 835 Control Message Protocol (ICMPv6) for the Internet 836 Protocol Version 6 (IPv6) Specification", STD 89, 837 RFC 4443, DOI 10.17487/RFC4443, March 2006, 838 . 840 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 841 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 842 DOI 10.17487/RFC4884, April 2007, 843 . 845 [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet 846 Sampling (PSAMP) Protocol Specifications", RFC 5476, 847 DOI 10.17487/RFC5476, March 2009, 848 . 850 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 851 N., and JR. Rivers, "Extending ICMP for Interface and 852 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 853 April 2010, . 855 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 856 "Specification of the IP Flow Information Export (IPFIX) 857 Protocol for the Exchange of Flow Information", STD 77, 858 RFC 7011, DOI 10.17487/RFC7011, September 2013, 859 . 861 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 862 for IP Flow Information Export (IPFIX)", RFC 7012, 863 DOI 10.17487/RFC7012, September 2013, 864 . 866 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 867 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 868 May 2016, . 870 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 871 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 872 May 2017, . 874 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 875 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 876 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 877 2018, . 879 Authors' Addresses 881 Zafar Ali 882 Cisco Systems 884 Email: zali@cisco.com 886 Clarence Filsfils 887 Cisco Systems 889 Email: cfilsfil@cisco.com 891 Satoru Matsushima 892 Softbank 894 Email: satoru.matsushima@g.softbank.co.jp 896 Daniel Voyer 897 Bell Canada 899 Email: daniel.voyer@bell.ca 901 Mach Chen 902 Huawei 904 Email: mach.chen@huawei.com