idnits 2.17.1 draft-ali-spring-srv6-oam-01.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 94 instances of too long lines in the document, the longest one being 13 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 227: '...of the O-flag is OPTIONAL. A node MAY ...' RFC 2119 keyword, line 229: '...d on a local decision it MAY ignore it...' RFC 2119 keyword, line 300: '...ntaining END.OP SID, it is RECOMMENDED...' RFC 2119 keyword, line 329: '...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 (July 2, 2018) is 2125 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: 'RFC8126' is mentioned on line 885, but not defined == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'I-D.6man-segment-routing-header' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-oam-usecase' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-data' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'I-D.spring-segment-routing-policy' is defined on line 987, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 9 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: January 1, 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 July 2, 2018 27 Operations, Administration, and Maintenance (OAM) in Segment 28 Routing Networks with IPv6 Data plane (SRv6) 29 draft-ali-spring-srv6-oam-01.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.1.1. O-flag Processing....................................6 78 3.1.2. Disabling Penultimate Segment Pop (PSP)..............7 79 3.2. OAM Segments..............................................7 80 3.2.1. End.OP: OAM Endpoint with Punt.......................7 81 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt........8 82 4. OAM Mechanisms....................................................8 83 4.1. Ping......................................................9 84 4.1.1. Classic Ping.........................................9 85 4.1.2. Pinging a SID Function..............................10 86 4.1.2.1. End-to-end ping using END.OP/ END.OTP..........11 87 4.1.2.2. Segment-by-segment ping using O-flag (Proof of 88 Transit)................................................11 89 4.2. Error Reporting..........................................13 90 4.3. Traceroute...............................................13 91 4.3.1. Classic Traceroute..................................13 92 4.3.2. Traceroute to a SID Function........................15 93 4.3.2.1. Hop-by-hop traceroute using END.OP/ END.OTP....16 94 4.3.2.2. Tracing SRv6 Overlay...........................17 95 4.4. In-situ OAM..............................................19 96 4.5. Monitoring of SRv6 Paths.................................19 97 5. Security Considerations..........................................20 98 6. IANA Considerations..............................................20 99 6.1. Segment Routing Header Flags Register....................20 100 6.2. ICMPv6 type Numbers Registry.............................20 101 7. References.......................................................21 102 7.1. Normative References.....................................21 103 7.2. Informative References...................................22 104 8. Acknowledgments..................................................22 106 1. Introduction 108 This document defines building blocks that can be used for 109 Operations, Administration, and Maintenance (OAM) in Segment Routing 110 Networks with IPv6 Dataplane (SRv6). The document also describes 111 some SRv6 OAM mechanisms that can be implemented using these 112 building blocks. 114 Additional OAM mechanisms will be added in a future revision of the 115 document. 117 2. Conventions Used in This Document 119 2.1. Abbreviations 121 ECMP: Equal Cost Multi-Path. 123 SID: Segment ID. 125 SL: Segment Left. 127 SR: Segment Routing. 129 SRH: Segment Routing Header. 131 SRv6: Segment Routing with IPv6 Data plane. 133 TC: Traffic Class. 135 UCMP: Unequal Cost Multi-Path. 137 2.2. Terminology and Reference Topology 139 This document uses the terminology defined in [I-D.draft-filsfils- 140 spring-srv6-network-programming]. The readers are expected to be 141 familiar with the same. 143 Throughout the document, the following simple topology is used for 144 illustration. 146 +--------------------------| N100 |------------------------+ 147 | | 148 ====== link1====== link3------ link5====== link9------ 149 ||N1||======||N2||======| N3 |======||N4||======| N5 | 150 || ||------|| ||------| |------|| ||------| | 151 ====== link2====== link4------ link6======link10------ 152 | | 153 | ------ | 154 +-------| N6 |---------+ 155 link7 | | link8 156 ------ 158 Figure 1 Reference Topology 160 In the reference topology: 162 Nodes N1, N2, and N4 are SRv6 capable nodes. 164 Nodes N3, N5 and N6 are classic IPv6 nodes. 166 Node 100 is a controller. 168 Node Nk has a classic IPv6 loopback address Bk::/128 170 Node Nk has Ak::/48 for its local SID space from which Local SIDs 171 are explicitly allocated. 173 The IPv6 address of the nth Link between node X and Y at the X side 174 is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address of link6 175 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 176 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 177 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 179 Ak::0 is explicitly allocated as the END function at Node k. 181 Ak::Cij is explicitly allocated as the END.X function at node k 182 towards neighbor node i via jth Link between node i and node j. 183 e.g., A2::C31 represents END.X at N2 towards N3 via link3 (the 1st 184 link between N2 and N3). Similarly, A4::C52 represents the END.X at 185 N4 towards N5 via link10. 187 represents a SID list where S1 is the first SID and S3 188 is the last SID. (S3, S2, S1; SL) represents the same SID list but 189 encoded in the SRH format where the rightmost SID (S1) in the SRH is 190 the first SID and the leftmost SID (S3) in the SRH is the last SID. 192 (SA, DA) (S3, S2, S1; SL) represents an IPv6 packet, SA is the IPv6 193 Source Address, DA the IPv6 Destination Address, (S3, S2, S1; SL) is 194 the SRH header that includes the SID list . 196 3. OAM Building Blocks 198 This section defines the various building blocks that can be used to 199 implement OAM mechanisms in SRv6 networks. The following section 200 describes some SRv6 OAM mechanisms that can be implemented using 201 these building blocks. 203 3.1. O-flag in Segment Routing Header 205 [I-D. draft-ietf-6man-segment-routing-header] describes the Segment 206 Routing Header (SRH) and how SR capable nodes use it. The SRH 207 contains an 8-bit "Flags" field [I-D. draft-ietf-6man-segment- 208 routing-header]. This document defines the following bit in the 209 SRH.Flags to carry the O-flag: 211 0 1 2 3 4 5 6 7 212 +-+-+-+-+-+-+-+-+ 213 | |O| | 214 +-+-+-+-+-+-+-+-+ 216 Where: 218 - O-flag: OAM flag. When set, it indicates that this packet is an 219 operations and management (OAM) packet. This document defines 220 the usage of the O-flag in the SRH.Flags. 221 - The document does not define any other flag in the SRH.Flags 222 and meaning and processing of any other bit in SRH.Flags is 223 outside of the scope of this document. 225 3.1.1. O-flag Processing 227 Implementation of the O-flag is OPTIONAL. A node MAY ignore 228 SRH.Flags.O-flag. It is also possible that a node is capable of 229 supporting the O-bit but based on a local decision it MAY ignore it 230 during processing on some local SIDs. If a node does not support the 231 O-flag, then upon reception it simply ignores it. If a node supports 232 the O-flag, it can optionally advertise its potential via node 233 capability advertisement in IGP [I-D.bashandy-isis-srv6- 234 extensions] and BGP-LS [I-D.dawra-idr-bgpls-srv6-ext]. 236 The SRH.Flags.O-flag implements the "punt a timestamped copy and 237 forward" behavior. To avoid the head of the line processing of the 238 packet, some implementation may implement the "forward and punt a 239 timestamped copy" behavior, instead. In order to implement "punt a 240 timestamped copy and forward" or "forward and punt a timestamped 241 copy" behavior, the following instructions are inserted at the 242 beginning or the end of the pseudo-code for all SID Functions, 243 respectively. 245 When N receives a packet whose IPv6 DA is S and S is a local SID, N executes the 246 following the pseudo-code, either before or after the execution of the local SID 247 S. 248 1. IF SRH.Flags.O-flag is True and SRH.Flags.O-flag is locally 249 supported for S THEN 250 a. Timestamp a local copy of the packet. ;; Ref1 251 b. Punt the time-stamped copy of the packet to CPU for processing in 252 software (slow-path). ;; Ref2 253 Ref1: Timestamping is done in hardware, as soon as possible during 254 the packet processing. As timestamping is done on a copy of the 255 packet which is locally punted, timestamp value can be carried in 256 the local packet (punt) header. 257 Ref1: Hardware (microcode) just punts the packet. There is no 258 requirement for the hardware to manipulate any TLV in SRH (or 259 elsewhere). Software (slow path) implements the required OAM 260 mechanism. Timestamp is not carried in the packet forwarded to the 261 next hop. 262 3.1.2. Disabling Penultimate Segment Pop (PSP) 264 Penultimate Segment Pop (PSP) needs to be disabled when SRH.Flags.O- 265 flag is set. If a node supports SRH.Flags.O-flag, it adds the 266 following check after executing the instruction 'update the IPv6 DA 267 with SRH[SL]' during processing of a local SID as described in [I- 268 D.draft-filsfils-spring-srv6-network-programming]: 270 1. IF updated SL = 0 & PSP is TRUE and SRH.Flags.O-bit is False 271 2. pop the top SRH ;; Ref1 273 Ref1: PSP behavior is disabled when SRH.Flags.O-flag is set. 275 3.2. OAM Segments 277 OAM Segment IDs (SIDs) is another components of the building blocks 278 needed to implement SRv6 OAM mechanisms. This document defines a 279 couple of OAM SIDs. Additional SIDs will be added in the later 280 version of the document. 282 3.2.1. End.OP: OAM Endpoint with Punt 284 Many scenarios require punting of SRv6 OAM packets at the desired 285 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 286 for short) represents a particular OAM function to implement the 287 punt behavior for an OAM packet. It is described using the 288 pseudocode as follows: 290 When N receives a packet destined to S and S is a local End.OP SID, 291 N does: 293 1. Punt the packet to CPU for SW processing (slow-path) ;; Ref1 295 Ref1: Hardware (microcode) only punts the packet. There is no 296 requirement for the hardware to manipulate any TLV in the SRH (or 297 elsewhere). Software (slow path) implements the required OAM 298 mechanisms. 300 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 301 to set the SRH.Flags.O-flag = 0. 303 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt 305 Scenarios demanding performance management of an SR policy/ path 306 requires hardware timestamping before hardware punts the packet to 307 the software for OAM processing. The "OAM Endpoint with Timestamp 308 and Punt" function (End.OTP for short) represents an OAM SID 309 function to implement the timestamp and punt behavior for an OAM 310 packet. It is described using the pseudocode as follows: 312 When N receives a packet destined to S and S is a local End.OTP SID, 313 N does: 315 1. Timestamp the packet ;; Ref1 317 2. Punt the packet to CPU for SW processing (slow-path) ;; Ref2 319 Ref1: Timestamping is done in hardware, as soon as possible 320 during the packet processing. As timestamping is done on a copy of 321 the packet which is locally punted, timestamp value can be carried 322 in the local packet (punt) header. 324 Ref2: Hardware (microcode) only punts the packet. There is no 325 requirement for the hardware to manipulate any TLV in the SRH (or 326 elsewhere). Software (slow path) implements the required OAM 327 mechanisms. 329 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 330 to set the SRH.Flags.O-flag = 0. 332 4. OAM Mechanisms 334 This section describes how OAM mechanisms can be implemented using 335 the OAM building blocks described in the previous section. 336 Additional OAM mechanisms will be added in a future revision of the 337 document. 339 [RFC4443] describes Internet Control Message Protocol for IPv6 340 (ICMPv6) that is used by IPv6 devices for network diagnostic and 341 error reporting purposes. As Segment Routing with IPv6 data plane 342 (SRv6) simply adds a new type of Routing Extension Header, existing 343 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 344 describes the applicability of ICMPv6 in the SRv6 network and how 345 the existing ICMPv6 mechanisms can be used for providing OAM 346 functionality. 348 Throughout this document, unless otherwise specified, the acronym 349 ICMPv6 refers to multi-part ICMPv6 messages [RFC4884]. The document 350 does not propose any changes to the standard ICMPv6 [RFC4443], 351 [RFC4884] or standard ICMPv4 [RFC792]. 353 4.1. Ping 355 There is no hardware or software change required for ping operation 356 at the classic IPv6 nodes in an SRv6 network. That includes the 357 classic IPv6 node with ingress, egress or transit roles. 358 Furthermore, no protocol changes are required to the standard ICMPv6 359 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 360 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 362 The following subsections outline some use cases of the ICMP ping in 363 the SRv6 networks. 365 4.1.1. Classic Ping 367 The existing mechanism to ping a remote IP prefix, along the 368 shortest path, continues to work without any modification. The 369 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 370 egress or transit may be an SRv6 capable node or a classic IPv6 371 node. 373 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 374 arbitrary segment list , it needs to initiate ICMPv6 375 ping with an SR header containing the SID list . This is 376 illustrated using the topology in Figure 1. Assume all the links 377 have IGP metric 10 except both links between node2 and node3, which 378 have IGP metric set to 100. User issues a ping from node N1 to a 379 loopback of node 5, via segment list . 381 Figure 2 contains sample output for a ping request initiated at node 382 N1 to the loopback address of node N5 via a segment list . 385 > ping B5:: via segment-list A2::C31, A4::C52 387 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 388 !!!!! 389 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 390 /0.749/0.931 ms 391 Figure 2 A sample ping output at an SRv6 capable node 393 All transit nodes process the echo request message like any other 394 data packet carrying SR header and hence do not require any change. 395 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 396 require any change to process the ICMPv6 echo request. For example, 397 in the ping example of Figure 2: 399 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 400 (B1::, A2::C31)(B1::, A4::C52, A2::C31, SL=2, NH: 401 ICMPv6)(ICMPv6 Echo Request). 402 - Node N2, which is an SRv6 capable node, performs the standard 403 SRH processing. Specifically, it executes the END.X function 404 (A2::C31) on the echo request packet. 405 - Node N3, which is a classic IPv6 node, performs the standard 406 IPv6 processing. Specifically, it forwards the echo request 407 based on DA A4::C52 in the IPv6 header. 408 - Node N4, which is an SRv6 capable node, performs the standard 409 SRH processing. Specifically, it observes the END.X function 410 (A4::C52) with PSP (Penultimate Segment POP) on the echo 411 request packet and removes the SRH and forwards the packet 412 across link10 to N5. 413 - The echo request packet at N5 arrives as an IPv6 packet without 414 a SRH. Node N5, which is a classic IPv6 node, performs the 415 standard IPv6/ ICMPv6 processing on the echo request and 416 responds, accordingly. 418 4.1.2. Pinging a SID Function 420 The classic ping described in the previous section cannot be used to 421 ping a remote SID function, as explained using an example in the 422 following. 424 Consider the case where the user wants to ping the remote SID 425 function A4::C52, via A2::C31, from node N1. Node N1 constructs the 426 ping packet (B1::0, A2::C31)( A4::C52, A2::C31, SL=1; 427 NH=ICMPv6)(ICMPv6 Echo Request). When the node N4 receives the 428 ICMPv6 echo request with DA set to A4::C52 and next header set to 429 ICMPv6, it silently drops it (see [I-D.filsfils-spring-srv6- 430 network-programming] for details). To solve this problem, the 431 initiator needs to mark the ICMPv6 echo request as an OAM packet. 433 The OAM packets are identified either by setting the O-flag in SRH 434 or by inserting the END.OP/ END.OTP SIDs at an appropriate place in 435 the SRH. The following illustration uses END.OTP SID but the 436 procedures are equally applicable to the END.OP SID. 438 In an SRv6 network, the user can exercise two flavors of the ping: 439 end-to-end ping or segment-by-segment ping, as outlined in the 440 following. 442 4.1.2.1. End-to-end ping using END.OP/ END.OTP 444 The end-to-end ping illustration uses the END.OTP SID but the 445 procedures are equally applicable to the END.OP SID. 447 Consider the same example where the user wants to ping a remote 448 SID function A4::C52 , via A2::C31, from node N1. To force a 449 punt of the ICMPv6 echo request at the node N4, node N1 inserts 450 the END.OTP SID just before the target SID A4::C52 in the SRH. 451 The ICMPv6 echo request is processed at the individual nodes 452 along the path as follows: 454 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 455 (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; 456 NH=ICMPv6)(ICMPv6 Echo Request). 457 - Node N2, which is an SRv6 capable node, performs the standard 458 SRH processing. Specifically, it executes the END.X function 459 (A2::C31) on the echo request packet. 460 - Node N3 receives the packet as follows (B1::0, 461 A4::OTP)(A4::C52, A4::OTP, A2::C31 ; SL=1; NH=ICMPv6)(ICMPv6 462 Echo Request). Node N3, which is a classic IPv6 node, performs 463 the standard IPv6 processing. Specifically, it forwards the 464 echo request based on DA A4::OTP in the IPv6 header. 465 - When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, 466 A4::OTP, A2::C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 467 processes the END.OTP SID, as described in the pseudocode in 468 Section 3. The packet gets punted to the ICMPv6 process for 469 processing. The ICMPv6 process checks if the next SID in SRH 470 (the target SID A4::C52) is locally programmed. 471 - If the target SID is not locally programmed, N4 responses with 472 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 473 locally implemented (TBA)"); otherwise a success is returned. 475 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 477 Consider the same example where the user wants to ping a remote SID 478 function A4::C52, via A2::C31, from node N1. However, in this ping, 479 the node N1 wants to get a response from each segment node in the 480 SRH. In other words, in the segment-by-segment ping case, the node 481 N1 expects a response from node N2 and node N4 for their respective 482 local SID function. 484 To force a punt of the ICMPv6 echo request at node N2 and node N4, 485 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 486 at the individual nodes along the path as follows: 488 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 489 (B1::0, A2::C31)(A4::C52, A2::C31; SL=1, Flags.O=1; 490 NH=ICMPv6)(ICMPv6 Echo Request). 491 - When node N2 receives the packet (B1::0, A2::C31)(A4::C52, 492 A2::C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) 493 packet, it processes the O-flag in SRH, as described in the 494 pseudocode in Section 3. A time-stamped copy of the packet gets 495 punted to the ICMPv6 process for processing. Node N2 continues 496 to apply the A2::C31 SID function on the original packet and 497 forwards it, accordingly. As SRH.Flags.O=1, Node N2 also 498 disables the PSP flavour, i.e., does not remove the SRH. The 499 ICMPv6 process at node N2 checks if its local SID (A2::C31) is 500 locally programmed or not and responds to the ICMPv6 Echo 501 Request. 502 - If the target SID is not locally programmed, N4 responses with 503 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 504 locally implemented (TBA)"); otherwise a success is returned. 505 Please note that, as mentioned in Section 3, if node N2 does 506 not support the O-flag, it simply ignores it and process the 507 local SID, A2::C31. 508 - Node N3, which is a classic IPv6 node, performs the standard 509 IPv6 processing. Specifically, it forwards the echo request 510 based on DA A4::C52 in the IPv6 header. 511 - When node N4 receives the packet (B1::0, A4::C52)(A4::C52, 512 A2::C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 513 processes the O-flag in SRH, as described in the pseudocode in 514 Section 3. A time-stamped copy of the packet gets punted to the 515 ICMPv6 process for processing. The ICMPv6 process at node N4 516 checks if its local SID (A2::C31) is locally programmed or not 517 and responds to the ICMPv6 Echo Request. If the target SID is 518 not locally programmed, N4 responses with the ICMPv6 message 519 (Type: "SRv6 OAM (TBA)", Code: "SID not locally implemented 520 (TBA)"); otherwise a success is returned. 522 Support for O-flag is part of node capability advertisement. That 523 enables node N1 to know which segment nodes are capable of 524 responding to the ICMPv6 echo request. Node N1 processes the echo 525 responses and presents data to the user, accordingly. 527 Please note that segment-by-segment ping can be used to address 528 proof of transit use-case discussed earlier. 530 4.2. Error Reporting 532 Any IPv6 node can use ICMPv6 control messages to report packet 533 processing errors to the host that originated the datagram packet. 534 To name a few such scenarios: 536 - If the router receives an undeliverable IP datagram, or 537 - If the router receives a packet with a Hop Limit of zero, or 538 - If the router receives a packet such that if the router 539 decrements the packet's Hop Limit it becomes zero, or 540 - If the router receives a packet with problem with a field in 541 the IPv6 header or the extension headers such that it cannot 542 complete processing the packet, or 543 - If the router cannot forward a packet because the packet is 544 larger than the MTU of the outgoing link. 546 In the scenarios listed above, the ICMPv6 response also contains the 547 IP header, IP extension headers and leading payload octets of the 548 "original datagram" to which the ICMPv6 message is a response. 549 Specifically, the "Destination Unreachable Message", "Time Exceeded 550 Message", "Packet Too Big Message" and "Parameter Problem Message" 551 ICMPV6 messages can contain as much of the invoking packet as 552 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 553 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 554 packet contains the SR header. The packet originator can use this 555 information for diagnostic purposes. For example, traceroute can use 556 this information as detailed in the following. 558 4.3. Traceroute 560 There is no hardware or software change required for traceroute 561 operation at the classic IPv6 nodes in an SRv6 network. That 562 includes the classic IPv6 node with ingress, egress or transit 563 roles. Furthermore, no protocol changes are required to the standard 564 traceroute operations. In other words, existing traceroute 565 mechanisms work seamlessly in the SRv6 networks. 567 The following subsections outline some use cases of the traceroute 568 in the SRv6 networks. 570 4.3.1. Classic Traceroute 572 The existing mechanism to traceroute a remote IP prefix, along the 573 shortest path, continues to work without any modification. The 574 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 575 egress or transit may be an SRv6 node or a classic IPv6 node. 577 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 578 via an arbitrary segment list , it needs to initiate 579 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 581 the links have IGP metric 10 except both links between node2 and 582 node3, which have IGP metric set to 100. User issues a traceroute 583 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 585 request. 587 > traceroute B5:: via segment-list A2::C31, A4::C52 589 Tracing the route to B5:: 591 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 592 SRH: (B5::, A4::C52, A2::C31, SL=2) 594 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 595 SRH: (B5::, A4::C52, A2::C31, SL=1) 597 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 598 SRH: (B5::, A4::C52, A2::C31, SL=1) 600 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 602 Figure 3 A sample traceroute output at an SRv6 capable node 604 Please note that information for hop2 is returned by N3, which is a 605 classic IPv6 node. Nonetheless, the ingress node is able to display 606 SR header contents as the packet travels through the IPv6 classic 607 node. This is because the "Time Exceeded Message" ICMPv6 message can 608 contain as much of the invoking packet as possible without the 609 ICMPv6 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR 610 header is also included in these ICMPv6 messages initiated by the 611 classic IPv6 transit nodes that are not running SRv6 software. 612 Specifically, a node generating ICMPv6 message containing a copy of 613 the invoking packet does not need to understand the extension 614 header(s) in the invoking packet. 616 The segment list information returned for hop1 is returned by N2, 617 which is an SRv6 capable node. Just like for hop2, the ingress node 618 is able to display SR header contents for hop1. 620 There is no difference in processing of the traceroute probe at an 621 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 622 classic and SRv6 capable nodes use the address of the interface on 623 which probe was received as the source address in the ICMPv6 624 response. ICMP extensions defined in [RFC5837] can be used to also 625 display information about the IP interface through which the 626 datagram would have been forwarded had it been forwardable, and the 627 IP next hop to which the datagram would have been forwarded, the IP 628 interface upon which a datagram arrived, the sub-IP component of an 629 IP interface upon which a datagram arrived. 631 The information about the IP address of the incoming interface on 632 which the traceroute probe was received by the reporting node is 633 very useful. This information can also be used to verify if SID 634 functions A2::C31 and A4::C52 are executed correctly by N2 and N4, 635 respectively. Specifically, the information displayed for hop2 636 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 637 This matches with the expected interface bound to END.X function 638 A2::C31 (link3). Similarly, the information displayed for hop5 639 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 640 This matches with the expected interface bound to the END.X function 641 A4::C52 (link10). 643 4.3.2. Traceroute to a SID Function 645 The classic traceroute described in the previous section cannot be 646 used to traceroute a remote SID function, as explained using an 647 example in the following. 649 Consider the case where the user wants to traceroute the remote SID 650 function A4::C52, via A2::C31, from node N1. Node N1 constructs the 651 traceroute packet (B1::0, A2::C31, HC=1)( A4::C52, A2::C31, SL=1; 652 NH=UDP)(traceroute probe). Even though Hop Count of the packet is 653 set to 1, when the node N4 receives the traceroute probe with DA set 654 to A4::C52 and next header set to UDP, it silently drops it (see [I- 655 D.draft-filsfils-spring-srv6-network-programming] for details). To 656 solve this problem, the initiator needs to mark the traceroute probe 657 as an OAM packet. 659 The OAM packets are identified either by setting the O-flag in SRH 660 or by inserting the END.OTP SID at an appropriate place in the SRH. 662 In an SRv6 network, the user can exercise two flavors of the 663 traceroute: hop-by-hop traceroute or overlay traceroute. 665 - In hop-by-hop traceroute, user gets responses from all nodes 666 including classic IPv6 transit nodes, SRv6 capable transit 667 nodes as well as SRv6 capable segment endpoints. E.g., consider 668 the example where the user wants to traceroute to a remote SID 669 function A4::C52 , via A2::C31, from node N1. The traceroute 670 output will also display information about node3, which is a 671 transit (underlay) node. 672 - The overlay traceroute, on the other hand, does not trace the 673 underlay nodes. In other words, the overlay traceroute only 674 displays the nodes that acts as SRv6 segments along the route. 675 I.e., in the example where the user wants to traceroute to a 676 remote SID function A4::C52 , via A2::C31, from node N1, the 677 overlay traceroute would only display the traceroute 678 information from node N2 and node N2 and will not display 679 information from node 3. 681 4.3.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 683 In this section, hop-by-hop traceroute to a SID function is 684 exemplified using UDP probes. However, the procedure is equally 685 applicable to other implementation of traceroute mechanism. 686 Furthermore, the illustration uses the END.OTP SID but the 687 procedures are equally applicable to the END.OP SID 689 Consider the same example where the user wants to traceroute to a 690 remote SID function A4::C52 , via A2::C31, from node N1. To force a 691 punt of the traceroute probe only at the node N4, node N1 inserts 692 the END.OTP SID just before the target SID A4::C52 in the SRH. The 693 traceroute probe is processed at the individual nodes along the path 694 as follows. 696 - Node N1 initiates a traceroute probe packet with a 697 monotonically increasing value of hop count and SRH as follows 698 (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; 699 NH=UDP)(Traceroute probe). 700 - When node N2 receives the packet with hop-count = 1, it 701 processes the hop count expiry. Specifically, the node N2 702 responses with the ICMPv6 message (Type: "Time Exceeded", Code: 703 "Time to Live exceeded in Transit"). 704 - When Node N2 receives the packet with hop-count > 1, it 705 performs the standard SRH processing. Specifically, it executes 706 the END.X function (A2::C31) on the traceroute probe. 707 - When node N3, which is a classic IPv6 node, receives the packet 708 (B1::0, A4::OTP)(A4::C52, A4::OTP, A2::C31 ; HC=1, SL=1; 709 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the 710 hop count expiry. Specifically, the node N3 responses with the 711 ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 712 exceeded in Transit"). 713 - When node N3, which is a classic IPv6 node, receives the packet 714 with hop-count > 1, it performs the standard IPv6 processing. 715 Specifically, it forwards the traceroute probe based on DA 716 A4::OTP in the IPv6 header. 718 - When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, 719 A4::OTP, A2::C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 720 processes the END.OTP SID, as described in the pseudocode in 721 Section 3. The packet gets punted to the traceroute process for 722 processing. The traceroute process checks if the next SID in 723 SRH (the target SID A4::C52) is locally programmed. If the 724 target SID A4::C52 is locally programmed, node N4 responses 725 with the ICMPv6 message (Type: Destination unreachable, Code: 726 Port Unreachable). If the target SID A4::C52 is not a local 727 SID, node N4 silently drops the traceroute probe. 729 Figure 4 displays a sample traceroute output for this example. 731 > traceroute srv6 A4::C52 via segment-list A2::C31 733 Tracing the route to SID function A4::C52 735 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 736 SRH: (A4::C52, A4::OTP, A2::C31; SL=2) 738 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 739 SRH: (A4::C52, A4::OTP, A2::C31; SL=1) 741 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 742 SRH: (A4::C52, A4::OTP, A2::C31; SL=1) 744 Figure 4 A sample output for hop-by-hop traceroute to a SID 745 function 747 4.3.2.2. Tracing SRv6 Overlay 749 The overlay traceroute does not trace the underlay nodes, i.e., only 750 displays the nodes that acts as SRv6 segments along the path. This 751 is achieved by setting the SRH.Flags.O bit. 753 In this section, overlay traceroute to a SID function is exemplified 754 using UDP probes. However, the procedure is equally applicable to 755 other implementation of traceroute mechanism. 757 Consider the same example where the user wants to traceroute to a 758 remote SID function A4::C52 , via A2::C31, from node N1. 760 - Node N1 initiates a traceroute probe with SRH as follows 761 (B1::0, A2::C31)(A4::C52, A2::C31; HC=64, SL=1, Flags.O=1; 762 NH=UDP)(Traceroute Probe). Please note that the hop-count is 763 set to 64 to skip the underlay nodes from tracing. The O-flag 764 in SRH is set to make the overlay nodes (nodes processing the 765 SRH) respond. 766 - When node N2 receives the packet (B1::0, A2::C31)(A4::C52, 767 A2::C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 768 processes the O-flag in SRH, as described in the pseudocode in 769 Section 3. A time-stamped copy of the packet gets punted to the 770 traceroute process for processing. Node N2 continues to apply 771 the A2::C31 SID function on the original packet and forwards 772 it, accordingly. As SRH.Flags.O=1, Node N2 also disables the 773 PSP flavor, i.e., does not remove the SRH. The traceroute 774 process at node N2 checks if its local SID (A2::C31) is locally 775 programmed. If the SID is not locally programmed, it silently 776 drops the packet. Otherwise, it performs the egress check by 777 looking at the SL value in SRH. 778 - As SL is not equal to zero (i.e., it's not egress node), node 779 N2 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", 780 Code: "O-flag punt at Transit (TBA)"). Please note that, as 781 mentioned in Section 3, if node N2 does not support the O-flag, 782 it simply ignores it and processes the local SID, A2::C31. 783 - When node N3 receives the packet (B1::0, A4::C52)(A4::C52, 784 A2::C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 785 performs the standard IPv6 processing. Specifically, it 786 forwards the traceroute probe based on DA A4::C52 in the IPv6 787 header. Please note that there is no hop-count expiration at 788 the transit nodes. 789 - When node N4 receives the packet (B1::0, A4::C52)(A4::C52, 790 A2::C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 791 processes the O-flag in SRH, as described in the pseudocode in 792 Section 3. A time-stamped copy of the packet gets punted to the 793 traceroute process for processing. The traceroute process at 794 node N4 checks if its local SID (A2::C31) is locally 795 programmed. If the SID is not locally programmed, it silently 796 drops the packet. Otherwise, it performs the egress check by 797 looking at the SL value in SRH. As SL is equal to zero (i.e., 798 N4 is the egress node), node N4 tries to consume the UDP probe. 799 As UDP probe is set to access an invalid port, the node N4 800 responses with the ICMPv6 message (Type: Destination 801 unreachable, Code: Port Unreachable). 803 Figure 5 displays a sample overlay traceroute output for this 804 example. Please note that the underlay node N3 does not appear in 805 the output. 807 > traceroute srv6 A4::C52 via segment-list A2::C31 809 Tracing the route to SID function A4::C52 810 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 811 SRH: (A4::C52, A4::OTP, A2::C31; SL=2) 813 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 814 SRH: (A4::C52, A4::OTP, A2::C31; SL=1) 816 Figure 5 A sample output for overlay traceroute to a SID function 818 4.4. In-situ OAM 820 [I-D.brockners-inband-oam-requirements] describes motivation 821 and requirements for In-situ OAM (iOAM). iOAM records operational 822 and telemetry information in the data packet while the packet 823 traverses the network of telemetry domain. iOAM complements out-of- 824 band probe based OAM mechanisms such ICMP ping and traceroute by 825 directly encoding tracing and the other kind of telemetry 826 information to the regular data traffic. 828 [I-D.brockners-inband-oam-transport] describes transport mechanisms 829 for iOAM data including IPv6 and Segment Routing traffic. To address 830 iOAM requirements in an SRv6 network, the draft describes iOAM TLV 831 in SRH and its usage. 833 4.5. Monitoring of SRv6 Paths 835 In the recent past, network operators are interested in performing 836 network OAM functions in a centralized manner. Various data models 837 like YANG are available to collect data from the network and manage 838 it from a centralized entity. 840 SR technology enables a centralized OAM entity to perform path 841 monitoring from centralized OAM entity without control plane 842 intervention on monitored nodes. [I.D-draft-ietf-spring-oam-usecase] 843 describes such a centralized OAM mechanism. Specifically, the draft 844 describes a procedure that can be used to perform path continuity 845 check between any nodes within an SR domain from a centralized 846 monitoring system, with minimal or no control plane intervene on the 847 nodes. However, the draft focuses on SR networks with MPLS data 848 plane. The same concept applies to the SRv6 networks. This document 849 describes how the concept can be used to perform path monitoring in 850 an SRv6 network. This document describes how the concept can be used 851 to perform path monitoring in an SRv6 network as follows. 853 In the above reference topology, N100 is the centralized monitoring 854 system implementing an END function A100::. In order to verify a 855 segment list , N100 generates a probe packet with 856 SRH set to (A100::, A4::C52, A2::C31, SL=2). The controller routes 857 the probe packet towards the first segment, which is A2::C31. N2 858 performs the standard SRH processing and forward it over link3 with 859 the DA of IPv6 packet set to A4::C52. N4 also performs the normal 860 SRH processing and forward it over link10 with the DA of IPv6 packet 861 set to A100::. This makes the probe loops back to the centralized 862 monitoring system. 864 In the reference topology in Figure 1, N100 uses an IGP protocol 865 like OSPF or ISIS to get the topology view within the IGP domain. 866 N100 can also use BGP-LS to get the complete view of an inter-domain 867 topology. In other words, the controller leverages the visibility of 868 the topology to monitor the paths between the various endpoints 869 without control plane intervention required at the monitored nodes. 871 5. Security Considerations 873 This document does not define any new protocol extensions and relies 874 on existing procedures defined for ICMP. This document does not 875 impose any additional security challenges to be considered beyond 876 security considerations described in [RFC4884], [RFC4443], [RFC792] 877 and RFCs that updates these RFCs. 879 6. IANA Considerations 881 6.1. Segment Routing Header Flags Register 883 This document requests the creation of a new IANA managed registry 884 to identify SRH Flags Bits. The registration procedure is "Expert 885 Review" as defined in [RFC8126]. Suggested registry name is 886 "Segment Routing Header Flags". SRH.Flags is an 8 bits field; the 887 following bit is defined in this document: 889 Suggested Bit Description Reference 891 ----------------------------------------------------- 893 2 OAM This document 895 6.2. ICMPv6 type Numbers Registry 897 This document defines one ICMPv6 Message, a type that has been 898 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 900 Specifically, it requests to add the following to the "ICMPv6 Type 901 Numbers" registry: 903 TBA (suggested value: 162) SRv6 OAM Message. 905 The document also requests the creation of a new IANA registry to 906 the 908 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 909 OAM Message" with the following codes: 911 Code Name Reference 912 ------------------------------------------------------- 913 0 No Error This document 914 1 SID is not locally implemented This document 915 2 O-flag punt at Transit This document 917 6.3. SRv6 OAM Endpoint Types 919 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 920 Types" sub-registry belonging to the top-level "Segment-routing with 921 IPv6 dataplane (SRv6) Parameters" registry [I-D.filsfils-spring- 922 srv6-network-programming], the following allocations: 924 +-------------+-----+-------------------+-----------+ 925 | Value (Suggested | Endpoint function | Reference | 926 | Value) | | | 927 +------------------+-------------------+-----------+ 928 | TBA (25) | End.OTP | [This.ID] | 929 | TBA (30) | End.OTP | [This.ID] | 930 +------------------+-------------------+-----------+ 932 7. References 934 7.1. Normative References 936 [RFC792] J. Postel, "Internet Control Message Protocol", RFC 792, 937 September 1981. 939 [RFC4443] A. Conta, S. Deering, M. Gupta, Ed., "Internet Control 940 Message Protocol (ICMPv6) for the Internet Protocol 941 Version 6 (IPv6) Specification", RFC 4443, March 2006. 943 [RFC4884] R. Bonica, D. Gan, D. Tappan, C. Pignataro, "Extended ICMP 944 to Support Multi-Part Messages", RFC 4884, April 2007. 946 [RFC5837] A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, 947 JR. Rivers, "Extending ICMP for Interface and Next-Hop 948 Identification", RFC 5837, April 2010. 950 [I-D.filsfils-spring-srv6-network-programming] C. Filsfils, et al., 951 "SRv6 Network Programming", 952 draft-filsfils-spring-srv6-network-programming, work in 953 progress. 955 [I-D.6man-segment-routing-header] Previdi, S., Filsfils, et al, 956 "IPv6 Segment Routing Header (SRH)", 957 draft-ietf-6man-segment-routing-header, work in progress. 959 7.2. Informative References 961 [I-D.bashandy-isis-srv6-extensions] IS-IS Extensions to Support Routing 962 over IPv6 Dataplane. L. Ginsberg, P. Psenak, C. Filsfils, 963 A. Bashandy, B. Decraene, Z. Hu, 964 draft-bashandy-isis-srv6-extensions, work in progress. 966 [I-D.dawra-idr-bgpls-srv6-ext] G. Dawra, C. Filsfils, K. Talaulikar, 967 et al., BGP Link State extensions for IPv6 Segment Routing 968 (SRv6), draft-dawra-idr-bgpls-srv6-ext, work in progress. 970 [I-D.ietf-spring-oam-usecase] A Scalable and Topology-Aware MPLS 971 Dataplane Monitoring System. R. Geib, C. Filsfils, C. 972 Pignataro, N. Kumar, draft-ietf-spring-oam-usecase, work 973 in progress. 975 [I-D.brockners-inband-oam-data] F. Brockners, et al., "Data Formats 976 for In-situ OAM", draft-brockners-inband-oam-data, work in 977 progress. 979 [I-D.brockners-inband-oam-transport] F.Brockners, at al., 980 "Encapsulations for In-situ OAM Data", 981 draft-brockners-inband-oam-transport, work in progress. 983 [I-D.brockners-inband-oam-requirements] F.Brockners, et al., 984 "Requirements for In-situ OAM", 985 draft-brockners-inband-oam-requirements, work in progress. 987 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 988 Routing Policy for Traffic Engineering", 989 draft-filsfils-spring-segment-routing-policy, work in 990 progress. 992 8. Acknowledgments 994 To be added. 996 Authors' Addresses 998 Clarence Filsfils 999 Cisco Systems, Inc. 1000 Email: cfilsfil@cisco.com 1002 Zafar Ali 1003 Cisco Systems, Inc. 1004 Email: zali@cisco.com 1006 Nagendra Kumar 1007 Cisco Systems, Inc. 1008 Email: naikumar@cisco.com 1010 Carlos Pignataro 1011 Cisco Systems, Inc. 1012 Email: cpignata@cisco.com 1014 Faisal Iqbal 1015 Cisco Systems, Inc. 1016 Email: faiqbal@cisco.com 1018 Rakesh Gandhi 1019 Cisco Systems, Inc. 1020 Canada 1021 Email: rgandhi@cisco.com 1023 John Leddy 1024 Comcast 1025 Email: John_Leddy@cable.comcast.com 1027 Robert Raszuk 1028 Bloomberg LP 1029 731 Lexington Ave 1030 New York City, NY10022, USA 1031 Email: robert@raszuk.net 1033 Satoru Matsushima 1034 SoftBank 1035 Japan 1036 Email: satoru.matsushima@g.softbank.co.jp 1038 Daniel Voyer 1039 Bell Canada 1040 Email: daniel.voyer@bell.ca 1041 Gaurav Dawra 1042 LinkedIn 1043 Email: gdawra.ietf@gmail.com 1045 Bart Peirens 1046 Proximus 1047 Email: bart.peirens@proximus.com 1049 Mach Chen 1050 Huawei 1051 Email: mach.chen@huawei.com 1053 Gaurav Naik 1054 Drexel University 1055 United States of America 1056 Email: gn@drexel.edu