idnits 2.17.1 draft-ali-spring-srv6-oam-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 22) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 89 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 233: '...ntaining END.OP SID, it is RECOMMENDED...' RFC 2119 keyword, line 260: '...taining END.OTP SID, it is RECOMMENDED...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2012 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.filsfils-spring-srv6-network-programming' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'I-D.6man-segment-routing-header' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'I-D.dawra-idr-bgpls-srv6-ext' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-oam-usecase' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-data' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-transport' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'I-D.spring-segment-routing-policy' is defined on line 889, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track N. Kumar 5 Expires: April 21, 2019 C. Pignataro 6 F. Iqbal 7 R. Gandhi 8 Cisco Systems, Inc. 9 J. Leddy 10 Comcast 11 S. Matsushima 12 SoftBank 13 R. Raszuk 14 Bloomberg LP 15 D. Voyer 16 Bell Canada 17 G. Dawra 18 LinkedIn 19 B. Peirens 20 Proximus 21 M. Chen 22 Huawei 23 G. Naik 24 Drexel University 25 October 22, 2018 27 Operations, Administration, and Maintenance (OAM) in Segment 28 Routing Networks with IPv6 Data plane (SRv6) 29 draft-ali-spring-srv6-oam-02.txt 31 Abstract 33 This document defines building blocks that can be used for 34 Operations, Administration, and Maintenance (OAM) in Segment Routing 35 Networks with IPv6 Dataplane (SRv6). The document also describes 36 some SRv6 OAM mechanisms that can be realized using these building 37 blocks. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction......................................................3 72 2. Conventions Used in This Document.................................3 73 2.1. Abbreviations.............................................3 74 2.2. Terminology and Reference Topology........................4 75 3. OAM Building Blocks...............................................5 76 3.1. O-flag in Segment Routing Header..........................5 77 3.2. OAM Segments..............................................7 78 3.2.1. End.OP: OAM Endpoint with Punt.......................7 79 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt........8 80 4. OAM Mechanisms....................................................8 81 4.1. Ping......................................................9 82 4.1.1. Classic Ping.........................................9 83 4.1.2. Pinging a SID Function..............................10 84 4.1.2.1. End-to-end ping using END.OP/ END.OTP..........11 85 4.1.2.2. Segment-by-segment ping using O-flag (Proof of 86 Transit)................................................11 87 4.2. Error Reporting..........................................13 88 4.3. Traceroute...............................................13 89 4.3.1. Classic Traceroute..................................13 90 4.3.2. Traceroute to a SID Function........................15 91 4.3.2.1. Hop-by-hop traceroute using END.OP/ END.OTP....16 92 4.3.2.2. Tracing SRv6 Overlay...........................17 93 4.4. Monitoring of SRv6 Paths.................................19 94 5. Security Considerations..........................................20 95 6. IANA Considerations..............................................20 96 6.1. ICMPv6 type Numbers Registry.............................20 97 7. References.......................................................21 98 7.1. Normative References.....................................21 99 7.2. Informative References...................................22 100 8. Acknowledgments..................................................22 102 1. Introduction 104 This document defines building blocks that can be used for 105 Operations, Administration, and Maintenance (OAM) in Segment Routing 106 Networks with IPv6 Dataplane (SRv6). The document also describes 107 some SRv6 OAM mechanisms that can be implemented using these 108 building blocks. 110 Additional OAM mechanisms will be added in a future revision of the 111 document. 113 2. Conventions Used in This Document 115 2.1. Abbreviations 117 ECMP: Equal Cost Multi-Path. 119 SID: Segment ID. 121 SL: Segment Left. 123 SR: Segment Routing. 125 SRH: Segment Routing Header. 127 SRv6: Segment Routing with IPv6 Data plane. 129 TC: Traffic Class. 131 UCMP: Unequal Cost Multi-Path. 133 2.2. Terminology and Reference Topology 135 This document uses the terminology defined in [I-D.draft-filsfils- 136 spring-srv6-network-programming]. The readers are expected to be 137 familiar with the same. 139 Throughout the document, the following simple topology is used for 140 illustration. 142 +--------------------------| N100 |------------------------+ 143 | | 144 ====== link1====== link3------ link5====== link9------ 145 ||N1||======||N2||======| N3 |======||N4||======| N5 | 146 || ||------|| ||------| |------|| ||------| | 147 ====== link2====== link4------ link6======link10------ 148 | | 149 | ------ | 150 +-------| N6 |---------+ 151 link7 | | link8 152 ------ 154 Figure 1 Reference Topology 156 In the reference topology: 158 Nodes N1, N2, and N4 are SRv6 capable nodes. 160 Nodes N3, N5 and N6 are classic IPv6 nodes. 162 Node N100 is a controller. 164 Node k has a classic IPv6 loopback address A:k::/128. 165 A SID at node k with locator block B and function F is represented 166 by B:k:F:: 168 The IPv6 address of the nth Link between node X and Y at the X side 169 is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address of link6 170 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 171 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 172 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 174 B:k:1:: is explicitly allocated as the END function at Node k. 176 B:k::Cij is explicitly allocated as the END.X function at node k 177 towards neighbor node i via jth Link between node i and node j. 178 e.g., B:2:C31 represents END.X at N2 towards N3 via link3 (the 1st 179 link between N2 and N3). Similarly, B:4:C52 represents the END.X at 180 N4 towards N5 via link10. 182 represents a SID list where S1 is the first SID and S3 183 is the last SID. (S3, S2, S1; SL) represents the same SID list but 184 encoded in the SRH format where the rightmost SID (S1) in the SRH is 185 the first SID and the leftmost SID (S3) in the SRH is the last SID. 187 (SA, DA) (S3, S2, S1; SL) represents an IPv6 packet, SA is the IPv6 188 Source Address, DA the IPv6 Destination Address, (S3, S2, S1; SL) is 189 the SRH header that includes the SID list . 191 3. OAM Building Blocks 193 This section defines the various building blocks that can be used to 194 implement OAM mechanisms in SRv6 networks. The following section 195 describes some SRv6 OAM mechanisms that can be implemented using 196 these building blocks. 198 3.1. O-flag in Segment Routing Header 200 [I-D. draft-ietf-6man-segment-routing-header] describes the Segment 201 Routing Header (SRH) and how SR capable nodes use it. The draft 202 [I-D. draft-ietf-6man-segment-routing-header] also define an OAM 203 flag (SRH.Flags.O), which indicates that this packet is an 204 operations and management (OAM) packet. The SRH draft also defines 205 the processing rules for the O-flag in the SRH.Flags. The O-flag 206 is one of the OAM building blocks considered in this document. 208 3.2. OAM Segments 210 OAM Segment IDs (SIDs) is another components of the building blocks 211 needed to implement SRv6 OAM mechanisms. This document defines a 212 couple of OAM SIDs. Additional SIDs will be added in the later 213 version of the document. 215 3.2.1. End.OP: OAM Endpoint with Punt 217 Many scenarios require punting of SRv6 OAM packets at the desired 218 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 219 for short) represents a particular OAM function to implement the 220 punt behavior for an OAM packet. It is described using the 221 pseudocode as follows: 223 When N receives a packet destined to S and S is a local End.OP SID, 224 N does: 226 1. Punt the packet to CPU for SW processing (slow-path) ;; Ref1 228 Ref1: Hardware (microcode) only punts the packet. There is no 229 requirement for the hardware to manipulate any TLV in the SRH (or 230 elsewhere). Software (slow path) implements the required OAM 231 mechanisms. 233 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 234 to set the SRH.Flags.O-flag = 0. 236 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt 238 Scenarios demanding performance management of an SR policy/ path 239 requires hardware timestamping before hardware punts the packet to 240 the software for OAM processing. The "OAM Endpoint with Timestamp 241 and Punt" function (End.OTP for short) represents an OAM SID 242 function to implement the timestamp and punt behavior for an OAM 243 packet. It is described using the pseudocode as follows: 245 When N receives a packet destined to S and S is a local End.OTP SID, 246 N does: 248 1. Timestamp the packet ;; Ref1 250 2. Punt the packet to CPU for SW processing (slow-path) ;; Ref2 252 Ref1: Timestamping is done in hardware, as soon as possible 253 during the packet processing. 255 Ref2: Hardware (microcode) only punts the packet. There is no 256 requirement for the hardware to manipulate any TLV in the SRH (or 257 elsewhere). Software (slow path) implements the required OAM 258 mechanisms. 260 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 261 to set the SRH.Flags.O-flag = 0. 263 4. OAM Mechanisms 265 This section describes how OAM mechanisms can be implemented using 266 the OAM building blocks described in the previous section. 267 Additional OAM mechanisms will be added in a future revision of the 268 document. 270 [RFC4443] describes Internet Control Message Protocol for IPv6 271 (ICMPv6) that is used by IPv6 devices for network diagnostic and 272 error reporting purposes. As Segment Routing with IPv6 data plane 273 (SRv6) simply adds a new type of Routing Extension Header, existing 274 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 275 describes the applicability of ICMPv6 in the SRv6 network and how 276 the existing ICMPv6 mechanisms can be used for providing OAM 277 functionality. 279 Throughout this document, unless otherwise specified, the acronym 280 ICMPv6 refers to multi-part ICMPv6 messages [RFC4884]. The document 281 does not propose any changes to the standard ICMPv6 [RFC4443], 282 [RFC4884] or standard ICMPv4 [RFC792]. 284 4.1. Ping 286 There is no hardware or software change required for ping operation 287 at the classic IPv6 nodes in an SRv6 network. That includes the 288 classic IPv6 node with ingress, egress or transit roles. 289 Furthermore, no protocol changes are required to the standard ICMPv6 290 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 291 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 293 The following subsections outline some use cases of the ICMP ping in 294 the SRv6 networks. 296 4.1.1. Classic Ping 298 The existing mechanism to ping a remote IP prefix, along the 299 shortest path, continues to work without any modification. The 300 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 301 egress or transit may be an SRv6 capable node or a classic IPv6 302 node. 304 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 305 arbitrary segment list , it needs to initiate ICMPv6 306 ping with an SR header containing the SID list . This is 307 illustrated using the topology in Figure 1. Assume all the links 308 have IGP metric 10 except both links between node2 and node3, which 309 have IGP metric set to 100. User issues a ping from node N1 to a 310 loopback of node 5, via segment list . 312 Figure 2 contains sample output for a ping request initiated at node 313 N1 to the loopback address of node N5 via a segment list . 316 > ping A:5:: via segment-list B:2:C31, B:4:C52 318 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 319 !!!!! 320 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 321 /0.749/0.931 ms 322 Figure 2 A sample ping output at an SRv6 capable node 324 All transit nodes process the echo request message like any other 325 data packet carrying SR header and hence do not require any change. 326 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 327 require any change to process the ICMPv6 echo request. For example, 328 in the ping example of Figure 2: 330 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 331 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 332 ICMPv6)(ICMPv6 Echo Request). 333 - Node N2, which is an SRv6 capable node, performs the standard 334 SRH processing. Specifically, it executes the END.X function 335 (B:2:C31) on the echo request packet. 336 - Node N3, which is a classic IPv6 node, performs the standard 337 IPv6 processing. Specifically, it forwards the echo request 338 based on DA B:4:C52 in the IPv6 header. 339 - Node N4, which is an SRv6 capable node, performs the standard 340 SRH processing. Specifically, it observes the END.X function 341 (B:4:C52) with PSP (Penultimate Segment POP) on the echo 342 request packet and removes the SRH and forwards the packet 343 across link10 to N5. 344 - The echo request packet at N5 arrives as an IPv6 packet without 345 a SRH. Node N5, which is a classic IPv6 node, performs the 346 standard IPv6/ ICMPv6 processing on the echo request and 347 responds, accordingly. 349 4.1.2. Pinging a SID Function 351 The classic ping described in the previous section cannot be used to 352 ping a remote SID function, as explained using an example in the 353 following. 355 Consider the case where the user wants to ping the remote SID 356 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 357 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 358 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 359 receives the ICMPv6 echo request with DA set to B:4:C52 but the next header is 360 ICMPv6, instead of SRH. To solve this problem, the 361 initiator needs to mark the ICMPv6 echo request as an OAM packet. 363 The OAM packets are identified either by setting the O-flag in SRH 364 or by inserting the END.OP/ END.OTP SIDs at an appropriate place in 365 the SRH. The following illustration uses END.OTP SID but the 366 procedures are equally applicable to the END.OP SID. 368 In an SRv6 network, the user can exercise two flavors of the ping: 369 end-to-end ping or segment-by-segment ping, as outlined in the 370 following. 372 4.1.2.1. End-to-end ping using END.OP/ END.OTP 374 The end-to-end ping illustration uses the END.OTP SID but the 375 procedures are equally applicable to the END.OP SID. 377 Consider the same example where the user wants to ping a remote 378 SID function B:4:C52 , via B:2:C31, from node N1. To force a 379 punt of the ICMPv6 echo request at the node N4, node N1 inserts 380 the END.OTP SID just before the target SID B:4:C52 in the SRH. 381 The ICMPv6 echo request is processed at the individual nodes 382 along the path as follows: 384 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 385 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 386 NH=ICMPv6)(ICMPv6 Echo Request). 387 - Node N2, which is an SRv6 capable node, performs the standard 388 SRH processing. Specifically, it executes the END.X function 389 (B:2:C31) on the echo request packet. 390 - Node N3 receives the packet as follows (A:1::, 391 B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 392 Echo Request). Node N3, which is a classic IPv6 node, performs 393 the standard IPv6 processing. Specifically, it forwards the 394 echo request based on DA B:4:OTP in the IPv6 header. 395 - When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 396 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 397 processes the END.OTP SID, as described in the pseudocode in 398 Section 3. The packet gets punted to the ICMPv6 process for 399 processing. The ICMPv6 process checks if the next SID in SRH 400 (the target SID B:4:C52) is locally programmed. 401 - If the target SID is not locally programmed, N4 responses with 402 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 403 locally implemented (TBA)"); otherwise a success is returned. 405 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 407 Consider the same example where the user wants to ping a remote SID 408 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 409 the node N1 wants to get a response from each segment node in the 410 SRH as a "proof of transit". In other words, in the segment-by-segment ping 411 case, the node N1 expects a response from node N2 and node N4 for their 412 respective local SID function. When a response to O-bit is desired from the 413 last SID in a SID-list, it is the responsibility of the ingress node to use 414 USP as the last SID. E.g., in this example, the target SID B:4:C52 is a USP 415 SID. 417 To force a punt of the ICMPv6 echo request at node N2 and node N4, 418 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 419 at the individual nodes along the path as follows: and 421 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 422 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 423 NH=ICMPv6)(ICMPv6 Echo Request). 424 - When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 425 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) 426 packet, it processes the O-flag in SRH, as described in the 427 pseudocode in Section 3. A time-stamped copy of the packet gets 428 punted to the ICMPv6 process for processing. Node N2 continues 429 to apply the B:2:C31 SID function on the original packet and 430 forwards it, accordingly. As B:4:C52 is a USP SID, N2 does not 431 remove the SRH. 432 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 433 locally programmed or not and responds to the ICMPv6 Echo 434 Request. 435 - If the target SID is not locally programmed, N4 responses with 436 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 437 locally implemented (TBA)"); otherwise a success is returned. 438 Please note that, as mentioned in Section 3, if node N2 does 439 not support the O-flag, it simply ignores it and process the 440 local SID, B:2:C31. 441 - Node N3, which is a classic IPv6 node, performs the standard 442 IPv6 processing. Specifically, it forwards the echo request 443 based on DA B:4:C52 in the IPv6 header. 444 - When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 445 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 446 processes the O-flag in SRH, as described in the pseudocode in 447 Section 3. A time-stamped copy of the packet gets punted to the 448 ICMPv6 process for processing. The ICMPv6 process at node N4 449 checks if its local SID (B:2:C31) is locally programmed or not 450 and responds to the ICMPv6 Echo Request. If the target SID is 451 not locally programmed, N4 responses with the ICMPv6 message 452 (Type: "SRv6 OAM (TBA)", Code: "SID not locally implemented 453 (TBA)"); otherwise a success is returned. 455 Support for O-flag is part of node capability advertisement. That 456 enables node N1 to know which segment nodes are capable of 457 responding to the ICMPv6 echo request. Node N1 processes the echo 458 responses and presents data to the user, accordingly. 460 Please note that segment-by-segment ping can be used to address 461 proof of transit use-case. 463 4.2. Error Reporting 465 Any IPv6 node can use ICMPv6 control messages to report packet 466 processing errors to the host that originated the datagram packet. 467 To name a few such scenarios: 469 - If the router receives an undeliverable IP datagram, or 470 - If the router receives a packet with a Hop Limit of zero, or 471 - If the router receives a packet such that if the router 472 decrements the packet's Hop Limit it becomes zero, or 473 - If the router receives a packet with problem with a field in 474 the IPv6 header or the extension headers such that it cannot 475 complete processing the packet, or 476 - If the router cannot forward a packet because the packet is 477 larger than the MTU of the outgoing link. 479 In the scenarios listed above, the ICMPv6 response also contains the 480 IP header, IP extension headers and leading payload octets of the 481 "original datagram" to which the ICMPv6 message is a response. 482 Specifically, the "Destination Unreachable Message", "Time Exceeded 483 Message", "Packet Too Big Message" and "Parameter Problem Message" 484 ICMPV6 messages can contain as much of the invoking packet as 485 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 486 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 487 packet contains the SR header. The packet originator can use this 488 information for diagnostic purposes. For example, traceroute can use 489 this information as detailed in the following. 491 4.3. Traceroute 493 There is no hardware or software change required for traceroute 494 operation at the classic IPv6 nodes in an SRv6 network. That 495 includes the classic IPv6 node with ingress, egress or transit 496 roles. Furthermore, no protocol changes are required to the standard 497 traceroute operations. In other words, existing traceroute 498 mechanisms work seamlessly in the SRv6 networks. 500 The following subsections outline some use cases of the traceroute 501 in the SRv6 networks. 503 4.3.1. Classic Traceroute 505 The existing mechanism to traceroute a remote IP prefix, along the 506 shortest path, continues to work without any modification. The 507 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 508 egress or transit may be an SRv6 node or a classic IPv6 node. 510 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 511 via an arbitrary segment list , it needs to initiate 512 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 514 the links have IGP metric 10 except both links between node2 and 515 node3, which have IGP metric set to 100. User issues a traceroute 516 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 518 request. 520 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 522 Tracing the route to B5:: 524 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 525 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 527 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 528 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 530 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 531 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 533 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 535 Figure 3 A sample traceroute output at an SRv6 capable node 537 Please note that information for hop2 is returned by N3, which is a 538 classic IPv6 node. Nonetheless, the ingress node is able to display 539 SR header contents as the packet travels through the IPv6 classic 540 node. This is because the "Time Exceeded Message" ICMPv6 message can 541 contain as much of the invoking packet as possible without the 542 ICMPv6 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR 543 header is also included in these ICMPv6 messages initiated by the 544 classic IPv6 transit nodes that are not running SRv6 software. 545 Specifically, a node generating ICMPv6 message containing a copy of 546 the invoking packet does not need to understand the extension 547 header(s) in the invoking packet. 549 The segment list information returned for hop1 is returned by N2, 550 which is an SRv6 capable node. Just like for hop2, the ingress node 551 is able to display SR header contents for hop1. 553 There is no difference in processing of the traceroute probe at an 554 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 555 classic and SRv6 capable nodes use the address of the interface on 556 which probe was received as the source address in the ICMPv6 557 response. ICMP extensions defined in [RFC5837] can be used to also 558 display information about the IP interface through which the 559 datagram would have been forwarded had it been forwardable, and the 560 IP next hop to which the datagram would have been forwarded, the IP 561 interface upon which a datagram arrived, the sub-IP component of an 562 IP interface upon which a datagram arrived. 564 The information about the IP address of the incoming interface on 565 which the traceroute probe was received by the reporting node is 566 very useful. This information can also be used to verify if SID 567 functions B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 568 respectively. Specifically, the information displayed for hop2 569 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 570 This matches with the expected interface bound to END.X function 571 B:2:C31 (link3). Similarly, the information displayed for hop5 572 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 573 This matches with the expected interface bound to the END.X function 574 B:4:C52 (link10). 576 4.3.2. Traceroute to a SID Function 578 The classic traceroute described in the previous section cannot be 579 used to traceroute a remote SID function, as explained using an 580 example in the following. 582 Consider the case where the user wants to traceroute the remote SID 583 function B:4:C52, via B:2:C31, from node N1. The trace route fails at N4. 584 This is because the node N4 trace route probe where next header is 585 UDP or ICMPv6, instead of SRH (even though the hop limit is set to 1). 586 To solve this problem, the 587 initiator needs to mark the ICMPv6 echo request as an OAM packet. 589 The OAM packets are identified either by setting the O-flag in SRH 590 or by inserting the END.OTP SID at an appropriate place in the SRH. 592 In an SRv6 network, the user can exercise two flavors of the 593 traceroute: hop-by-hop traceroute or overlay traceroute. 595 - In hop-by-hop traceroute, user gets responses from all nodes 596 including classic IPv6 transit nodes, SRv6 capable transit 597 nodes as well as SRv6 capable segment endpoints. E.g., consider 598 the example where the user wants to traceroute to a remote SID 599 function B:4:C52 , via B:2:C31, from node N1. The traceroute 600 output will also display information about node3, which is a 601 transit (underlay) node. 602 - The overlay traceroute, on the other hand, does not trace the 603 underlay nodes. In other words, the overlay traceroute only 604 displays the nodes that acts as SRv6 segments along the route. 605 I.e., in the example where the user wants to traceroute to a 606 remote SID function B:4:C52 , via B:2:C31, from node N1, the 607 overlay traceroute would only display the traceroute 608 information from node N2 and node N2 and will not display 609 information from node 3. 611 4.3.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 613 In this section, hop-by-hop traceroute to a SID function is 614 exemplified using UDP probes. However, the procedure is equally 615 applicable to other implementation of traceroute mechanism. 616 Furthermore, the illustration uses the END.OTP SID but the 617 procedures are equally applicable to the END.OP SID 619 Consider the same example where the user wants to traceroute to a 620 remote SID function B:4:C52 , via B:2:C31, from node N1. To force a 621 punt of the traceroute probe only at the node N4, node N1 inserts 622 the END.OTP SID just before the target SID B:4:C52 in the SRH. The 623 traceroute probe is processed at the individual nodes along the path 624 as follows. 626 - Node N1 initiates a traceroute probe packet with a 627 monotonically increasing value of hop count and SRH as follows 628 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 629 NH=UDP)(Traceroute probe). 630 - When node N2 receives the packet with hop-count = 1, it 631 processes the hop count expiry. Specifically, the node N2 632 responses with the ICMPv6 message (Type: "Time Exceeded", Code: 633 "Time to Live exceeded in Transit"). 634 - When Node N2 receives the packet with hop-count > 1, it 635 performs the standard SRH processing. Specifically, it executes 636 the END.X function (B:2:C31) on the traceroute probe. 637 - When node N3, which is a classic IPv6 node, receives the packet 638 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 639 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the 640 hop count expiry. Specifically, the node N3 responses with the 641 ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 642 exceeded in Transit"). 643 - When node N3, which is a classic IPv6 node, receives the packet 644 with hop-count > 1, it performs the standard IPv6 processing. 645 Specifically, it forwards the traceroute probe based on DA 646 B:4:OTP in the IPv6 header. 648 - When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 649 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 650 processes the END.OTP SID, as described in the pseudocode in 651 Section 3. The packet gets punted to the traceroute process for 652 processing. The traceroute process checks if the next SID in 653 SRH (the target SID B:4:C52) is locally programmed. If the 654 target SID B:4:C52 is locally programmed, node N4 responses 655 with the ICMPv6 message (Type: Destination unreachable, Code: 656 Port Unreachable). If the target SID B:4:C52 is not a local 657 SID, node N4 silently drops the traceroute probe. 659 Figure 4 displays a sample traceroute output for this example. 661 > traceroute srv6 B:4:C52 via segment-list B:2:C31 663 Tracing the route to SID function B:4:C52 665 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 666 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 668 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 669 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 671 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 672 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 674 Figure 4 A sample output for hop-by-hop traceroute to a SID 675 function 677 4.3.2.2. Tracing SRv6 Overlay 679 The overlay traceroute does not trace the underlay nodes, i.e., only 680 displays the nodes that acts as SRv6 segments along the path. This 681 is achieved by setting the SRH.Flags.O bit. 683 In this section, overlay traceroute to a SID function is exemplified 684 using UDP probes. However, the procedure is equally applicable to 685 other implementation of traceroute mechanism. 687 Consider the same example where the user wants to traceroute to a 688 remote SID function B:4:C52 , via B:2:C31, from node N1. 690 - Node N1 initiates a traceroute probe with SRH as follows 691 (A:1::, B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 692 NH=UDP)(Traceroute Probe). Please note that the hop-count is 693 set to 64 to skip the underlay nodes from tracing. The O-flag 694 in SRH is set to make the overlay nodes (nodes processing the 695 SRH) respond. 696 - When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 697 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 698 processes the O-flag in SRH, as described in the pseudocode in 699 Section 3. A time-stamped copy of the packet gets punted to the 700 traceroute process for processing. Node N2 continues to apply 701 the B:2:C31 SID function on the original packet and forwards 702 it, accordingly. As SRH.Flags.O=1, Node N2 also disables the 703 PSP flavor, i.e., does not remove the SRH. The traceroute 704 process at node N2 checks if its local SID (B:2:C31) is locally 705 programmed. If the SID is not locally programmed, it silently 706 drops the packet. Otherwise, it performs the egress check by 707 looking at the SL value in SRH. 708 - As SL is not equal to zero (i.e., it's not egress node), node 709 N2 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", 710 Code: "O-flag punt at Transit (TBA)"). Please note that, as 711 mentioned in Section 3, if node N2 does not support the O-flag, 712 it simply ignores it and processes the local SID, B:2:C31. 713 - When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 714 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 715 performs the standard IPv6 processing. Specifically, it 716 forwards the traceroute probe based on DA B:4:C52 in the IPv6 717 header. Please note that there is no hop-count expiration at 718 the transit nodes. 719 - When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 720 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 721 processes the O-flag in SRH, as described in the pseudocode in 722 Section 3. A time-stamped copy of the packet gets punted to the 723 traceroute process for processing. The traceroute process at 724 node N4 checks if its local SID (B:2:C31) is locally 725 programmed. If the SID is not locally programmed, it silently 726 drops the packet. Otherwise, it performs the egress check by 727 looking at the SL value in SRH. As SL is equal to zero (i.e., 728 N4 is the egress node), node N4 tries to consume the UDP probe. 729 As UDP probe is set to access an invalid port, the node N4 730 responses with the ICMPv6 message (Type: Destination 731 unreachable, Code: Port Unreachable). 733 Figure 5 displays a sample overlay traceroute output for this 734 example. Please note that the underlay node N3 does not appear in 735 the output. 737 > traceroute srv6 B:4:C52 via segment-list B:2:C31 739 Tracing the route to SID function B:4:C52 740 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 741 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 743 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 744 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 746 Figure 5 A sample output for overlay traceroute to a SID function 748 4.5. Monitoring of SRv6 Paths 750 In the recent past, network operators are interested in performing 751 network OAM functions in a centralized manner. Various data models 752 like YANG are available to collect data from the network and manage 753 it from a centralized entity. 755 SR technology enables a centralized OAM entity to perform path 756 monitoring from centralized OAM entity without control plane 757 intervention on monitored nodes. [I.D-draft-ietf-spring-oam-usecase] 758 describes such a centralized OAM mechanism. Specifically, the draft 759 describes a procedure that can be used to perform path continuity 760 check between any nodes within an SR domain from a centralized 761 monitoring system, with minimal or no control plane intervene on the 762 nodes. However, the draft focuses on SR networks with MPLS data 763 plane. The same concept applies to the SRv6 networks. This document 764 describes how the concept can be used to perform path monitoring in 765 an SRv6 network. This document describes how the concept can be used 766 to perform path monitoring in an SRv6 network as follows. 768 In the above reference topology, N100 is the centralized monitoring 769 system implementing an END function B:100:1::. In order to verify a 770 segment list , N100 generates a probe packet with 771 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller routes 772 the probe packet towards the first segment, which is B:2:C31. N2 773 performs the standard SRH processing and forward it over link3 with 774 the DA of IPv6 packet set to B:4:C52. N4 also performs the normal 775 SRH processing and forward it over link10 with the DA of IPv6 packet 776 set to B:100:1::. This makes the probe loops back to the centralized 777 monitoring system. 779 In the reference topology in Figure 1, N100 uses an IGP protocol 780 like OSPF or ISIS to get the topology view within the IGP domain. 781 N100 can also use BGP-LS to get the complete view of an inter-domain 782 topology. In other words, the controller leverages the visibility of 783 the topology to monitor the paths between the various endpoints 784 without control plane intervention required at the monitored nodes. 786 5. Security Considerations 788 This document does not define any new protocol extensions and relies 789 on existing procedures defined for ICMP. This document does not 790 impose any additional security challenges to be considered beyond 791 security considerations described in [RFC4884], [RFC4443], [RFC792] 792 and RFCs that updates these RFCs. 794 6. IANA Considerations 796 6.1. ICMPv6 type Numbers Registry 798 This document defines one ICMPv6 Message, a type that has been 799 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 801 Specifically, it requests to add the following to the "ICMPv6 Type 802 Numbers" registry: 804 TBA (suggested value: 162) SRv6 OAM Message. 806 The document also requests the creation of a new IANA registry to 807 the 809 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 810 OAM Message" with the following codes: 812 Code Name Reference 813 ------------------------------------------------------- 814 0 No Error This document 815 1 SID is not locally implemented This document 816 2 O-flag punt at Transit This document 818 6.3. SRv6 OAM Endpoint Types 820 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 821 Behaviors Registry" sub-registry belonging to the top-level 822 "Segment-routing with 823 IPv6 dataplane (SRv6) Parameters" registry [I-D.filsfils-spring- 824 srv6-network-programming], the following allocations: 826 +-------------+-----+-------------------+-----------+ 827 | Value (Suggested | Endpoint Behavior | Reference | 828 | Value) | | | 829 +------------------+-------------------+-----------+ 830 | TBA (30) | End.OP | [This.ID] | 831 | TBA (31) | End.OTP | [This.ID] | 832 +------------------+-------------------+-----------+ 834 7. References 836 7.1. Normative References 838 [RFC792] J. Postel, "Internet Control Message Protocol", RFC 792, 839 September 1981. 841 [RFC4443] A. Conta, S. Deering, M. Gupta, Ed., "Internet Control 842 Message Protocol (ICMPv6) for the Internet Protocol 843 Version 6 (IPv6) Specification", RFC 4443, March 2006. 845 [RFC4884] R. Bonica, D. Gan, D. Tappan, C. Pignataro, "Extended ICMP 846 to Support Multi-Part Messages", RFC 4884, April 2007. 848 [RFC5837] A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, 849 JR. Rivers, "Extending ICMP for Interface and Next-Hop 850 Identification", RFC 5837, April 2010. 852 [I-D.filsfils-spring-srv6-network-programming] C. Filsfils, et al., 853 "SRv6 Network Programming", 854 draft-filsfils-spring-srv6-network-programming, work in 855 progress. 857 [I-D.6man-segment-routing-header] Previdi, S., Filsfils, et al, 858 "IPv6 Segment Routing Header (SRH)", 859 draft-ietf-6man-segment-routing-header, work in progress. 861 7.2. Informative References 863 [I-D.bashandy-isis-srv6-extensions] IS-IS Extensions to Support Routing 864 over IPv6 Dataplane. L. Ginsberg, P. Psenak, C. Filsfils, 865 A. Bashandy, B. Decraene, Z. Hu, 866 draft-bashandy-isis-srv6-extensions, work in progress. 868 [I-D.dawra-idr-bgpls-srv6-ext] G. Dawra, C. Filsfils, K. Talaulikar, 869 et al., BGP Link State extensions for IPv6 Segment Routing 870 (SRv6), draft-dawra-idr-bgpls-srv6-ext, work in progress. 872 [I-D.ietf-spring-oam-usecase] A Scalable and Topology-Aware MPLS 873 Dataplane Monitoring System. R. Geib, C. Filsfils, C. 874 Pignataro, N. Kumar, draft-ietf-spring-oam-usecase, work 875 in progress. 877 [I-D.brockners-inband-oam-data] F. Brockners, et al., "Data Formats 878 for In-situ OAM", draft-brockners-inband-oam-data, work in 879 progress. 881 [I-D.brockners-inband-oam-transport] F.Brockners, at al., 882 "Encapsulations for In-situ OAM Data", 883 draft-brockners-inband-oam-transport, work in progress. 885 [I-D.brockners-inband-oam-requirements] F.Brockners, et al., 886 "Requirements for In-situ OAM", 887 draft-brockners-inband-oam-requirements, work in progress. 889 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 890 Routing Policy for Traffic Engineering", 891 draft-filsfils-spring-segment-routing-policy, work in 892 progress. 894 8. Acknowledgments 896 To be added. 898 Authors' Addresses 900 Clarence Filsfils 901 Cisco Systems, Inc. 902 Email: cfilsfil@cisco.com 904 Zafar Ali 905 Cisco Systems, Inc. 906 Email: zali@cisco.com 908 Nagendra Kumar 909 Cisco Systems, Inc. 910 Email: naikumar@cisco.com 912 Carlos Pignataro 913 Cisco Systems, Inc. 914 Email: cpignata@cisco.com 916 Faisal Iqbal 917 Cisco Systems, Inc. 918 Email: faiqbal@cisco.com 920 Rakesh Gandhi 921 Cisco Systems, Inc. 922 Canada 923 Email: rgandhi@cisco.com 925 John Leddy 926 Comcast 927 Email: John_Leddy@cable.comcast.com 929 Robert Raszuk 930 Bloomberg LP 931 731 Lexington Ave 932 New York City, NY10022, USA 933 Email: robert@raszuk.net 935 Satoru Matsushima 936 SoftBank 937 Japan 938 Email: satoru.matsushima@g.softbank.co.jp 940 Daniel Voyer 941 Bell Canada 942 Email: daniel.voyer@bell.ca 943 Gaurav Dawra 944 LinkedIn 945 Email: gdawra.ietf@gmail.com 947 Bart Peirens 948 Proximus 949 Email: bart.peirens@proximus.com 951 Mach Chen 952 Huawei 953 Email: mach.chen@huawei.com 955 Gaurav Naik 956 Drexel University 957 United States of America 958 Email: gn@drexel.edu