idnits 2.17.1 draft-ietf-6man-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2019) is 1616 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 192, but not defined -- Looks like a reference, but probably isn't: '2' on line 193 -- Looks like a reference, but probably isn't: '1' on line 193 -- Looks like a reference, but probably isn't: '0' on line 194 == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line 237, but not defined == Missing Reference: 'RFC792' is mentioned on line 864, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 823, but not defined == Unused Reference: 'RFC0792' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 1006, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-05 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems 5 Expires: May 23, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 November 20, 2019 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-02 17 Abstract 19 This document defines building blocks for Operations, Administration, 20 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 21 (SRv6). The document also describes some SRv6 OAM mechanisms. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 23, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Terminology and Reference Topology . . . . . . . . . . . 3 67 3. OAM Building Blocks . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 69 3.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 70 3.2. OAM Segments . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. End.OP: OAM Endpoint with Punt . . . . . . . . . . . . . 6 72 3.4. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 7 73 3.5. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 8 77 4.1.2. Pinging a SID Function . . . . . . . . . . . . . . . 10 78 4.1.3. Error Reporting . . . . . . . . . . . . . . . . . . . 12 79 4.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 13 81 4.2.2. Traceroute to a SID Function . . . . . . . . . . . . 15 82 4.3. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 18 83 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 7.1. ICMPv6 type Numbers RegistrySEC . . . . . . . . . . . . . 20 87 7.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 20 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 10.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 This document defines building blocks for Operations, Administration, 98 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 99 (SRv6). The document also describes some SRv6 OAM mechanisms. 101 2. Conventions Used in This Document 103 2.1. Abbreviations 105 The following abbreviations are used in this document: 107 SID: Segment ID. 109 SL: Segment Left. 111 SR: Segment Routing. 113 SRH: Segment Routing Header. 115 SRv6: Segment Routing with IPv6 Data plane. 117 TC: Traffic Class. 119 ICMPv6: multi-part ICMPv6 messages [RFC4884]. 121 2.2. Terminology and Reference Topology 123 This document uses the terminology defined in [I-D.ietf- spring-srv6- 124 network-programming]. The readers are expected to be familiar with 125 the same. 127 Throughout the document, the following simple topology is used for 128 illustration. 130 +--------------------------| N100 |------------------------+ 131 | | 132 ====== link1====== link3------ link5====== link9------ 133 ||N1||======||N2||======| N3 |======||N4||======| N5 | 134 || ||------|| ||------| |------|| ||------| | 135 ====== link2====== link4------ link6======link10------ 136 | | 137 | ------ | 138 +-------| N6 |---------+ 139 link7 | | link8 140 ------ 142 Figure 1 Reference Topology 144 In the reference topology: 146 Nodes N1, N2, and N4 are SRv6 capable nodes. 148 Nodes N3, N5 and N6 are classic IPv6 nodes. 150 Node N100 is a controller. 152 Node k has a classic IPv6 loopback address A:k::/128. 154 A SID at node k with locator block B and function F is represented 155 by B:k:F::. 157 The IPv6 address of the nth Link between node X and Y at the X 158 side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address 159 of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 160 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 161 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 163 B:k:Cij:: is explicitly allocated as the END.X function at node k 164 towards neighbor node i via jth Link between node i and node j. 165 e.g., B:2:C31:: represents END.X at N2 towards N3 via link3 (the 166 1st link between N2 and N3). Similarly, B:4:C52:: represents the 167 END.X at N4 towards N5 via link10. 169 A SID list is represented as where S1 is the first 170 SID to visit, S2 is the second SID to visit and S3 is the last SID 171 to visit along the SR path. 173 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 175 * IPv6 header with source address SA, destination addresses DA 176 and SRH as next-header 178 * SRH with SID list with SegmentsLeft = SL 180 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 182 the last SID to traverse. (S3, S2, S1; SL) represents the same 183 SID list but encoded in the SRH format where the rightmost SID 184 in the SRH is the first SID and the leftmost SID in the SRH is 185 the last SID. When referring to an SR policy in a high-level 186 use-case, it is simpler to use the notation. When 187 referring to an illustration of the detailed packet behavior, 188 the (S3, S2, S1; SL) notation is more convenient. 190 * (payload) represents the the payload of the packet. 192 SRH[SL] represents the SID pointed by the SL field in the first 193 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 194 and SRH[0] represents S3. 196 3. OAM Building Blocks 198 This section defines the various building blocks for implementing OAM 199 mechanisms in SRv6 networks. 201 3.1. O-flag in Segment Routing Header 203 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 204 Header (SRH) and how SR capable nodes use it. The SRH contains an 205 8-bit "Flags" field [I-D.draft-ietf-6man-segment- routing-header]. 206 This document defines the following bit in the SRH.Flags to carry the 207 O-flag: 209 0 1 2 3 4 5 6 7 210 +-+-+-+-+-+-+-+-+ 211 | |O| | 212 +-+-+-+-+-+-+-+-+ 214 Where: 216 O-flag: OAM flag. When set, it indicates that this packet is an 217 operations and management (OAM) packet. This document defines the 218 usage of the O-flag in the SRH.Flags. 220 The document does not define any other flag in the SRH.Flags and 221 meaning and processing of any other bit in SRH.Flags is outside of 222 the scope of this document. 224 3.1.1. O-flag Processing 226 The SRH.Flags.O-flag implements the "punt a timestamped copy and 227 forward" behavior. 229 Implementation of the O-flag is OPTIONAL. If a node does not support 230 the O-flag, then upon reception it simply ignores it. It is also 231 possible that a node is capable of supporting the O-bit but based on 232 a local decision it MAY ignore it during processing on some local 233 SIDs. 235 If a node supports the O-flag, it can optionally advertise its 236 potential via node capability advertisement in IGP [I-D.ietf-isis- 237 srv6- extensions] and BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. 239 When N receives a packet whose IPv6 DA is S and S is a local SID, the 240 pseudo-code associated with the SID S, as defined in section 4.3.1.1 241 of [I-D.ietf-6man-segment-routing-header], is modified as follows for 242 the O-flag processing. 244 S01.1. IF SRH.Flags.O-flag is set and local configuration permits 245 O-flag processing THEN 246 a. Make a copy of the packet. 247 b. Send the copied packet, along with an accurate timestamp 248 to the OAM process. ;; Ref1, Ref2 249 Ref1: An implementation SHOULD copy and record the timestamp as soon as 250 possible during packet processing. Timestamp is not carried in the packet 251 forwarded to the next hop. 252 Ref2: An implementation SHOULD NOT generate ICMP error during 253 local SID S processing. If local SID S processing requires generation 254 of an ICMP error, the error is generated by the local OAM process. 256 Please note that the O-flag processing happens before execution of 257 regular processing of the local SID S. 259 3.2. OAM Segments 261 OAM Segment IDs (SIDs) is another component of the SRv6 OAM building 262 Blocks. This document defines a couple of OAM SIDs. 264 3.3. End.OP: OAM Endpoint with Punt 266 Many scenarios require punting of SRv6 OAM packets at the desired 267 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 268 for short) represents a particular OAM function to implement the punt 269 behavior for an OAM packet. It is described using the pseudocode as 270 follows: 272 When N receives a packet destined to S and S is a local End.OP SID, N 273 does: 275 1. Send the packet to the OAM process ;; Ref1 277 Ref1: The local OAM process SHOULD NOT generate ICMP error during 278 local SID S processing. 280 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 281 to set the SRH.Flags.O-flag = 0. 283 3.4. End.OTP: OAM Endpoint with Timestamp and Punt 285 Scenarios demanding performance management of an SR policy/ path 286 requires hardware timestamping before hardware punts the packet to 287 the software for OAM processing. The "OAM Endpoint with Timestamp 288 and Punt" function (End.OTP for short) represents an OAM SID function 289 to implement the timestamp and punt behavior for an OAM packet. It 290 is described using the pseudocode as follows: 292 When N receives a packet destined to S and S is a local End.OTP SID, 293 N does: 295 1. Timestamp the packet ;; Ref1 297 2. Send the packet, along with an accurate timestamp, to the 298 OAM process ;; Ref2 300 Ref1: Timestamping SHOULD be done in hardware, as soon as possible 301 during the packet processing. 302 Ref2: The local OAM process SHOULD NOT generate ICMP error during 303 local SID S processing. 305 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 306 to set the SRH.Flags.O-flag = 0. 308 3.5. SRH TLV 310 [I-D.ietf-6man-segment-routing-header] defines TLVs of the Segment 311 Routing Header. 313 SRH TLV plays an important role in carrying OAM and Performance 314 Management (PM) metadata. 316 4. OAM Mechanisms 318 This section describes how OAM mechanisms can be implemented using 319 the OAM building blocks described in the previous section. 320 Additional OAM mechanisms will be added in a future revision of the 321 document. 323 [RFC4443] describes Internet Control Message Protocol for IPv6 324 (ICMPv6) that is used by IPv6 devices for network diagnostic and 325 error reporting purposes. As Segment Routing with IPv6 data plane 326 (SRv6) simply adds a new type of Routing Extension Header, existing 327 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 328 describes the applicability of ICMPv6 in the SRv6 network and how the 329 existing ICMPv6 mechanisms can be used for providing OAM 330 functionality. 332 The document does not propose any changes to the standard ICMPv6 333 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 335 4.1. Ping 337 There is no hardware or software change required for ping operation 338 at the classic IPv6 nodes in an SRv6 network. That includes the 339 classic IPv6 node with ingress, egress or transit roles. 340 Furthermore, no protocol changes are required to the standard ICMPv6 341 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 342 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 344 The following subsections outline some use cases of the ICMP ping in 345 the SRv6 networks. 347 4.1.1. Classic Ping 349 The existing mechanism to ping a remote IP prefix, along the shortest 350 path, continues to work without any modification. The initiator may 351 be an SRv6 node or a classic IPv6 node. Similarly, the egress or 352 transit may be an SRv6 capable node or a classic IPv6 node. 354 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 355 arbitrary segment list , it needs to initiate ICMPv6 ping 356 with an SR header containing the SID list . This is 357 illustrated using the topology in Figure 1. Assume all the links 358 have IGP metric 10 except both links between node2 and node3, which 359 have IGP metric set to 100. User issues a ping from node N1 to a 360 loopback of node 5, via segment list . 362 Figure 2 contains sample output for a ping request initiated at node 363 N1 to the loopback address of node N5 via a segment list . 366 > ping A:5:: via segment-list B:2:C31, B:4:C52 368 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 369 !!!!! 370 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 371 /0.749/0.931 ms 373 Figure 2 A sample ping output at an SRv6 capable node 375 All transit nodes process the echo request message like any other 376 data packet carrying SR header and hence do not require any change. 377 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 378 require any change to process the ICMPv6 echo request. For example, 379 in the ping example of Figure 2: 381 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 382 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 383 ICMPv6)(ICMPv6 Echo Request). 385 o Node N2, which is an SRv6 capable node, performs the standard SRH 386 processing. Specifically, it executes the END.X function 387 (B:2:C31) and forwards the packet on link3 to N3. 389 o Node N3, which is a classic IPv6 node, performs the standard IPv6 390 processing. Specifically, it forwards the echo request based on 391 DA B:4:C52 in the IPv6 header. 393 o Node N4, which is an SRv6 capable node, performs the standard SRH 394 processing. Specifically, it observes the END.X function 395 (B:4:C52) with PSP (Penultimate Segment POP) on the echo request 396 packet and removes the SRH and forwards the packet across link10 397 to N5. 399 o The echo request packet at N5 arrives as an IPv6 packet without an 400 SRH. Node N5, which is a classic IPv6 node, performs the standard 401 IPv6/ ICMPv6 processing on the echo request and responds, 402 accordingly. 404 4.1.2. Pinging a SID Function 406 The classic ping described in the previous section cannot be used to 407 ping a remote SID function, as explained using an example in the 408 following. 410 Consider the case where the user wants to ping the remote SID 411 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 412 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 413 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 414 receives the ICMPv6 echo request with DA set to B:4:C52 but the next 415 header is ICMPv6, instead of SRH. To solve this problem, the 416 initiator needs to mark the ICMPv6 echo request as an OAM packet. 418 The OAM packets are identified either by setting the O-flag in SRH or 419 by inserting the END.OP/ END.OTP SIDs at an appropriate place in the 420 SRH. The following illustration uses END.OTP SID but the procedures 421 are equally applicable to the END.OP SID. 423 In an SRv6 network, the user can exercise two flavors of the ping: 424 end-to-end ping or segment-by-segment ping, as outlined in the 425 following subsection. 427 4.1.2.1. End-to-end ping using END.OP/ END.OTP 429 The end-to-end ping illustration uses the END.OTP SID but the 430 procedures are equally applicable to the END.OP SID. 432 Consider the same example where the user wants to ping a remote SID 433 function B:4:C52, via B:2:C31, from node N1. To force a punt of the 434 ICMPv6 echo request at the node N4, node N1 inserts the END.OTP SID 435 just before the target SID B:4:C52 in the SRH. The ICMPv6 echo 436 request is processed at the individual nodes along the path as 437 follows: 439 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 440 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 441 NH=ICMPv6)(ICMPv6 Echo Request). 443 o Node N2, which is an SRv6 capable node, performs the standard SRH 444 processing. Specifically, it executes the END.X function 445 (B:2:C31) on the echo request packet. 447 o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, 448 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node 449 N3, which is a classic IPv6 node, performs the standard IPv6 450 processing. Specifically, it forwards the echo request based on 451 DA B:4:OTP in the IPv6 header. 453 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 454 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 455 processes the END.OTP SID, as described in the pseudocode in 456 Section 3. The packet gets time-stamped and punted to the ICMPv6 457 process for processing. The ICMPv6 process checks if the next SID 458 in SRH (the target SID B:4:C52) is locally programmed. 460 o If the target SID is not locally programmed, N4 responses with the 461 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 462 implemented (TBA)"); otherwise a success is returned. 464 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 466 Consider the same example where the user wants to ping a remote SID 467 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 468 the node N1 wants to get a response from each segment node in the SRH 469 as a "proof of transit". In other words, in the segment-by-segment 470 ping case, the node N1 expects a response from node N2 and node N4 471 for their respective local SID function. When a response to O-bit is 472 desired from the last SID in a SID-list, it is the responsibility of 473 the ingress node to use USP as the last SID. E.g., in this example, 474 the target SID B:4:C52 is a USP SID. 476 To force a punt of the ICMPv6 echo request at node N2 and node N4, 477 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 478 at the individual nodes along the path as follows: 480 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 481 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 482 NH=ICMPv6)(ICMPv6 Echo Request). 484 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 485 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet, 486 it processes the O-flag in SRH, as described in the pseudocode in 487 Section 3. A time-stamped copy of the packet gets punted to the 488 ICMPv6 process for processing. Node N2 continues to apply the 489 B:2:C31 SID function on the original packet and forwards it, 490 accordingly. As B:4:C52 is a USP SID, N2 does not remove the SRH. 491 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 492 locally programmed or not and responds to the ICMPv6 Echo Request. 494 o If the target SID is not locally programmed, N4 responses with the 495 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 496 implemented (TBA)"); otherwise a success is returned. Please note 497 that, as mentioned in Section 3, if node N2 does not support the 498 O-flag, it simply ignores it and process the local SID, B:2:C31. 500 o Node N3, which is a classic IPv6 node, performs the standard IPv6 501 processing. Specifically, it forwards the echo request based on 502 DA B:4:C52 in the IPv6 header. 504 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 505 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 506 processes the O-flag in SRH, as described in the pseudocode in 507 Section 3. A time-stamped copy of the packet gets punted to the 508 ICMPv6 process for processing. The ICMPv6 process at node N4 509 checks if its local SID (B:4:C52) is locally programmed or not and 510 responds to the ICMPv6 Echo Request. 512 o If the target SID is not locally programmed, N4 responses with the 513 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 514 implemented (TBA)"); otherwise a success is returned. 516 Support for O-flag is part of node capability advertisement. That 517 enables node N1 to know which segment nodes are capable of responding 518 to the ICMPv6 echo request. Node N1 processes the echo responses and 519 presents data to the user, accordingly. 521 Please note that segment-by-segment ping can be used to address proof 522 of transit use-case. 524 4.1.3. Error Reporting 526 Any IPv6 node can use ICMPv6 control messages to report packet 527 processing errors to the host that originated the datagram packet. 528 To name a few such scenarios: 530 o If the router receives an undeliverable IP datagram, or 532 o If the router receives a packet with a Hop Limit of zero, or 534 o If the router receives a packet such that if the router decrements 535 the packet's Hop Limit it becomes zero, or 537 o If the router receives a packet with problem with a field in the 538 IPv6 header or the extension headers such that it cannot complete 539 processing the packet, or 541 o If the router cannot forward a packet because the packet is larger 542 than the MTU of the outgoing link. 544 In the scenarios listed above, the ICMPv6 response also contains the 545 IP header, IP extension headers and leading payload octets of the 546 "original datagram" to which the ICMPv6 message is a response. 547 Specifically, the "Destination Unreachable Message", "Time Exceeded 548 Message", "Packet Too Big Message" and "Parameter Problem Message" 549 ICMPV6 messages can contain as much of the invoking packet as 550 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 551 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 552 packet contains the SR header. The packet originator can use this 553 information for diagnostic purposes. For example, traceroute can use 554 this information as detailed in the following subsection. 556 4.2. Traceroute 558 There is no hardware or software change required for traceroute 559 operation at the classic IPv6 nodes in an SRv6 network. That 560 includes the classic IPv6 node with ingress, egress or transit roles. 561 Furthermore, no protocol changes are required to the standard 562 traceroute operations. In other words, existing traceroute 563 mechanisms work seamlessly in the SRv6 networks. 565 The following subsections outline some use cases of the traceroute in 566 the SRv6 networks. 568 4.2.1. Classic Traceroute 570 The existing mechanism to traceroute a remote IP prefix, along the 571 shortest path, continues to work without any modification. The 572 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 573 egress or transit may be an SRv6 node or a classic IPv6 node. 575 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 576 via an arbitrary segment list , it needs to initiate 577 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 579 the links have IGP metric 10 except both links between node2 and 580 node3, which have IGP metric set to 100. User issues a traceroute 581 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 583 request. 585 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 587 Tracing the route to B5:: 588 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 589 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 590 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 591 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 592 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 593 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 594 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 596 Figure 3 A sample traceroute output at an SRv6 capable node 598 Please note that information for hop2 is returned by N3, which is a 599 classic IPv6 node. Nonetheless, the ingress node is able to display 600 SR header contents as the packet travels through the IPv6 classic 601 node. This is because the "Time Exceeded Message" ICMPv6 message can 602 contain as much of the invoking packet as possible without the ICMPv6 603 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 604 also included in these ICMPv6 messages initiated by the classic IPv6 605 transit nodes that are not running SRv6 software. Specifically, a 606 node generating ICMPv6 message containing a copy of the invoking 607 packet does not need to understand the extension header(s) in the 608 invoking packet. 610 The segment list information returned for hop1 is returned by N2, 611 which is an SRv6 capable node. Just like for hop2, the ingress node 612 is able to display SR header contents for hop1. 614 There is no difference in processing of the traceroute probe at an 615 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 616 classic and SRv6 capable nodes may use the address of the interface 617 on which probe was received as the source address in the ICMPv6 618 response. ICMP extensions defined in [RFC5837] can be used to also 619 display information about the IP interface through which the datagram 620 would have been forwarded had it been forwardable, and the IP next 621 hop to which the datagram would have been forwarded, the IP interface 622 upon which a datagram arrived, the sub-IP component of an IP 623 interface upon which a datagram arrived. 625 The information about the IP address of the incoming interface on 626 which the traceroute probe was received by the reporting node is very 627 useful. This information can also be used to verify if SID functions 628 B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 629 respectively. Specifically, the information displayed for hop2 630 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 631 This matches with the expected interface bound to END.X function 632 B:2:C31 (link3). Similarly, the information displayed for hop5 633 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 634 This matches with the expected interface bound to the END.X function 635 B:4:C52 (link10). 637 4.2.2. Traceroute to a SID Function 639 The classic traceroute described in the previous section cannot be 640 used to traceroute a remote SID function, as explained using an 641 example in the following. 643 Consider the case where the user wants to traceroute the remote SID 644 function B:4:C52, via B:2:C31, from node N1. The trace route fails 645 at N4. This is because the node N4 trace route probe where next 646 header is UDP or ICMPv6, instead of SRH (even though the hop limit is 647 set to 1). To solve this problem, the initiator needs to mark the 648 ICMPv6 echo request as an OAM packet. 650 The OAM packets are identified either by setting the O-flag in SRH or 651 by inserting the END.OP or END.OTP SID at an appropriate place in the 652 SRH. 654 In an SRv6 network, the user can exercise two flavors of the 655 traceroute: hop-by-hop traceroute or overlay traceroute. 657 o In hop-by-hop traceroute, user gets responses from all nodes 658 including classic IPv6 transit nodes, SRv6 capable transit nodes 659 as well as SRv6 capable segment endpoints. E.g., consider the 660 example where the user wants to traceroute to a remote SID 661 function B:4:C52, via B:2:C31, from node N1. The traceroute 662 output will also display information about node3, which is a 663 transit (underlay) node. 665 o The overlay traceroute, on the other hand, does not trace the 666 underlay nodes. In other words, the overlay traceroute only 667 displays the nodes that acts as SRv6 segments along the route. 668 I.e., in the example where the user wants to traceroute to a 669 remote SID function B:4:C52, via B:2:C31, from node N1, the 670 overlay traceroute would only display the traceroute information 671 from node N2 and node N4; it will not display information from 672 node 3. 674 4.2.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 676 In this section, hop-by-hop traceroute to a SID function is 677 exemplified using UDP probes. However, the procedure is equally 678 applicable to other implementation of traceroute mechanism. 680 Furthermore, the illustration uses the END.OTP SID but the procedures 681 are equally applicable to the END.OP SID. 683 Consider the same example where the user wants to traceroute to a 684 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 685 punt of the traceroute probe only at the node N4, node N1 inserts the 686 END.OTP SID just before the target SID B:4:C52 in the SRH. The 687 traceroute probe is processed at the individual nodes along the path 688 as follows: 690 o Node N1 initiates a traceroute probe packet with a monotonically 691 increasing value of hop count and SRH as follows (A:1::, 692 B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; NH=UDP)(Traceroute 693 probe). 695 o When node N2 receives the packet with hop-count = 1, it processes 696 the hop count expiry. Specifically, the node N2 responses with 697 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 698 exceeded in Transit"). 700 o When Node N2 receives the packet with hop-count > 1, it performs 701 the standard SRH processing. Specifically, it executes the END.X 702 function (B:2:C31) on the traceroute probe. 704 o When node N3, which is a classic IPv6 node, receives the packet 705 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 706 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the hop 707 count expiry. Specifically, the node N3 responses with the ICMPv6 708 message (Type: "Time Exceeded", Code: "Time to Live exceeded in 709 Transit"). 711 o When node N3, which is a classic IPv6 node, receives the packet 712 with hop-count > 1, it performs the standard IPv6 processing. 713 Specifically, it forwards the traceroute probe based on DA B:4:OTP 714 in the IPv6 header. 716 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 717 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 718 processes the END.OTP SID, as described in the pseudocode in 719 Section 3. The packet gets timestamped and punted to the 720 traceroute process for processing. The traceroute process checks 721 if the next SID in SRH (the target SID B:4:C52) is locally 722 programmed. 724 o If the target SID B:4:C52 is locally programmed, node N4 responses 725 with the ICMPv6 message (Type: Destination unreachable, Code: Port 726 Unreachable). If the target SID B:4:C52 is not a local SID, node 727 N4 silently drops the traceroute probe. 729 Figure 4 displays a sample traceroute output for this example. 731 > traceroute srv6 B:4:C52 via segment-list B:2:C31 733 Tracing the route to SID function B:4:C52 734 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 735 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 736 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 737 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 738 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 739 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 741 Figure 4 A sample output for hop-by-hop traceroute to a SID function 743 4.2.2.2. Tracing SRv6 Overlay 745 The overlay traceroute does not trace the underlay nodes, i.e., only 746 displays the nodes that acts as SRv6 segments along the path. This 747 is achieved by setting the SRH.Flags.O bit. 749 In this section, overlay traceroute to a SID function is exemplified 750 using UDP probes. However, the procedure is equally applicable to 751 other implementation of traceroute mechanism. 753 Consider the same example where the user wants to traceroute to a 754 remote SID function B:4:C52, via B:2:C31, from node N1. 756 o Node N1 initiates a traceroute probe with SRH as follows (A:1::, 757 B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 758 NH=UDP)(Traceroute Probe). Please note that the hop-count is set 759 to 64 to skip the underlay nodes from tracing. The O-flag in SRH 760 is set to make the overlay nodes (nodes processing the SRH) 761 respond. 763 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 764 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 765 processes the O-flag in SRH, as described in the pseudocode in 766 Section 3. A time-stamped copy of the packet gets punted to the 767 traceroute process for processing. Node N2 continues to apply the 768 B:2:C31 SID function on the original packet and forwards it, 769 accordingly. The traceroute process at node N2 checks if its 770 local SID (B:2:C31) is locally programmed. If the SID is not 771 locally programmed, it silently drops the packet. Otherwise, it 772 performs the egress check by looking at the SL value in SRH. 774 o As SL is not equal to zero (i.e., it's not egress node), node N2 775 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: 776 "O-flag punt at Transit (TBA)"). Please note that, as mentioned 777 in Section 3, if node N2 does not support the O-flag, it simply 778 ignores it and processes the local SID, B:2:C31. 780 o When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 781 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 782 performs the standard IPv6 processing. Specifically, it forwards 783 the traceroute probe based on DA B:4:C52 in the IPv6 header. 784 Please note that there is no hop-count expiration at the transit 785 nodes. 787 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 788 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 789 processes the O-flag in SRH, as described in the pseudocode in 790 Section 3. A time-stamped copy of the packet gets punted to the 791 traceroute process for processing. The traceroute process at node 792 N4 checks if its local SID (B:2:C31) is locally programmed. 794 o If the SID is not locally programmed, it silently drops the 795 packet. Otherwise, it performs the egress check by looking at the 796 SL value in SRH. As SL is equal to zero (i.e., N4 is the egress 797 node), node N4 tries to consume the UDP probe. As UDP probe is 798 set to access an invalid port, the node N4 responses with the 799 ICMPv6 message (Type: Destination unreachable, Code: Port 800 Unreachable) 802 Figure 5 displays a sample overlay traceroute output for this 803 example. Please note that the underlay node N3 does not appear in 804 the output. 806 Tracing the route to SID function B:4:C52 807 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 808 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 809 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 810 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=0) 812 Figure 5 A sample output for overlay traceroute to a SID function 814 4.3. Monitoring of SRv6 Paths 816 In the recent past, network operators are interested in performing 817 network OAM functions in a centralized manner. Various data models 818 like YANG are available to collect data from the network and manage 819 it from a centralized entity. 821 SR technology enables a centralized OAM entity to perform path 822 monitoring from centralized OAM entity without control plane 823 intervention on monitored nodes. [RFC 8403] describes such a 824 centralized OAM mechanism. Specifically, the draft describes a 825 procedure that can be used to perform path continuity check between 826 any nodes within an SR domain from a centralized monitoring system, 827 with minimal or no control plane intervene on the nodes. However, 828 the draft focuses on SR networks with MPLS data plane. The same 829 concept applies to the SRv6 networks. This document describes how 830 the concept can be used to perform path monitoring in an SRv6 831 network. This document describes how the concept can be used to 832 perform path monitoring in an SRv6 network as follows. 834 In the above reference topology, N100 is the centralized monitoring 835 system implementing an END function B:100:1::. In order to verify a 836 segment list , N100 generates a probe packet with 837 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller 838 routes the probe packet towards the first segment, which is B:2:C31. 839 N2 performs the standard SRH processing and forward it over link3 840 with the DA of IPv6 packet set to B:4:C52. N4 also performs the 841 normal SRH processing and forward it over link10 with the DA of IPv6 842 packet set to B:100:1::. This makes the probe loops back to the 843 centralized monitoring system. 845 In the reference topology in Figure 1, N100 uses an IGP protocol like 846 OSPF or ISIS to get the topology view within the IGP domain. N100 847 can also use BGP-LS to get the complete view of an inter-domain 848 topology. In other words, the controller leverages the visibility of 849 the topology to monitor the paths between the various endpoints 850 without control plane intervention required at the monitored nodes. 852 5. Implementation Status 854 This section is to be removed prior to publishing as an RFC. 856 See [I-D.matsushima-spring-srv6-deployment-status] for updated 857 deployment and interoperability reports. 859 6. Security Considerations 861 This document does not define any new protocol extensions and relies 862 on existing procedures defined for ICMP. This document does not 863 impose any additional security challenges to be considered beyond 864 security considerations described in [RFC4884], [RFC4443], [RFC792], 865 RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] 866 and [I-D.ietf-spring-srv6-network-programming]. 868 7. IANA Considerations 870 7.1. ICMPv6 type Numbers RegistrySEC 872 This document defines one ICMPv6 Message, a type that has been 873 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 874 Specifically, it requests to add the following to the "ICMPv6 Type 875 Numbers" registry: 877 TBA (suggested value: 162) SRv6 OAM Message. 879 The document also requests the creation of a new IANA registry to the 880 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 881 OAM Message" with the following codes: 883 Code Name Reference 884 -------------------------------------------------------- 885 0 No Error This document 886 1 SID is not locally implemented This document 887 2 O-flag punt at Transit This document 889 7.2. SRv6 OAM Endpoint Types 891 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 892 Behaviors Registry" sub-registry belonging to the top-level "Segment- 893 routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- 894 spring- srv6-network-programming], the following allocations: 896 +------------------+-------------------+-----------+ 897 | Value (Suggested | Endpoint Behavior | Reference | 898 | Value) | | | 899 +------------------+-------------------+-----------+ 900 | TBA (40) | End.OP | [This.ID] | 901 | TBA (41) | End.OTP | [This.ID] | 902 +------------------+-------------------+-----------+ 904 8. Acknowledgements 906 The authors would like to thank Gaurav Naik for his review comments. 908 9. Contributors 910 The following people have contributed to this document: 912 Robert Raszuk 913 Bloomberg LP 914 Email: robert@raszuk.net 916 John Leddy 917 Individual 918 Email: john@leddy.net 920 Gaurav Dawra 921 LinkedIn 922 Email: gdawra.ietf@gmail.com 924 Bart Peirens 925 Proximus 926 Email: bart.peirens@proximus.com 928 Nagendra Kumar 929 Cisco Systems, Inc. 930 Email: naikumar@cisco.com 932 Carlos Pignataro 933 Cisco Systems, Inc. 934 Email: cpignata@cisco.com 936 Rakesh Gandhi 937 Cisco Systems, Inc. 938 Canada 939 Email: rgandhi@cisco.com 941 Frank Brockners 942 Cisco Systems, Inc. 943 Germany 944 Email: fbrockne@cisco.com 946 Darren Dukes 947 Cisco Systems, Inc. 948 Email: ddukes@cisco.com 949 Cheng Li 950 Huawei 951 Email: chengli13@huawei.com 953 Faisal Iqbal 954 Individual 955 Email: faisal.ietf@gmail.com 957 10. References 959 10.1. Normative References 961 [I-D.ietf-6man-segment-routing-header] 962 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 963 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 964 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 965 progress), October 2019. 967 [I-D.ietf-spring-srv6-network-programming] 968 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 969 Matsushima, S., and Z. Li, "SRv6 Network Programming", 970 draft-ietf-spring-srv6-network-programming-05 (work in 971 progress), October 2019. 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, 975 DOI 10.17487/RFC2119, March 1997, 976 . 978 10.2. Informative References 980 [I-D.matsushima-spring-srv6-deployment-status] 981 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 982 Implementation and Deployment Status", draft-matsushima- 983 spring-srv6-deployment-status-02 (work in progress), 984 October 2019. 986 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 987 RFC 792, DOI 10.17487/RFC0792, September 1981, 988 . 990 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 991 Control Message Protocol (ICMPv6) for the Internet 992 Protocol Version 6 (IPv6) Specification", STD 89, 993 RFC 4443, DOI 10.17487/RFC4443, March 2006, 994 . 996 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 997 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 998 DOI 10.17487/RFC4884, April 2007, 999 . 1001 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 1002 N., and JR. Rivers, "Extending ICMP for Interface and 1003 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 1004 April 2010, . 1006 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 1007 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 1008 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 1009 2018, . 1011 Authors' Addresses 1013 Zafar Ali 1014 Cisco Systems 1016 Email: zali@cisco.com 1018 Clarence Filsfils 1019 Cisco Systems 1021 Email: cfilsfil@cisco.com 1023 Satoru Matsushima 1024 Softbank 1026 Email: satoru.matsushima@g.softbank.co.jp 1028 Daniel Voyer 1029 Bell Canada 1031 Email: daniel.voyer@bell.ca 1033 Mach Chen 1034 Huawei 1036 Email: mach.chen@huawei.com