idnits 2.17.1 draft-ietf-6man-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 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 3, 2019) is 1630 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 863, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 822, but not defined == Unused Reference: 'RFC0792' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 1005, 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 6, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 November 3, 2019 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-01 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 6, 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, N 240 executes the following pseudo-code, before the execution of the local 241 SID S. Specifically, for the SID defined in section 4.3.1.1 of [I- 242 D.ietf-6man-segment-routing-header], the O-flag processing happens 243 immediately following S01. 245 S01.1. IF SRH.Flags.O-flag is one and local configuration permits 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, Ref3 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. 255 Ref3: If multiple SRH are present with O-flag set, an implementation 256 SHOULD only send one copy of the packet to the OAM process. 258 3.2. OAM Segments 260 OAM Segment IDs (SIDs) is another component of the SRv6 OAM building 261 Blocks. This document defines a couple of OAM SIDs. 263 3.3. End.OP: OAM Endpoint with Punt 265 Many scenarios require punting of SRv6 OAM packets at the desired 266 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 267 for short) represents a particular OAM function to implement the punt 268 behavior for an OAM packet. It is described using the pseudocode as 269 follows: 271 When N receives a packet destined to S and S is a local End.OP SID, N 272 does: 274 1. Send the packet to the OAM process ;; Ref1 276 Ref1: The local OAM process SHOULD NOT generate ICMP error during 277 local SID S processing. 279 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 280 to set the SRH.Flags.O-flag = 0. 282 3.4. End.OTP: OAM Endpoint with Timestamp and Punt 284 Scenarios demanding performance management of an SR policy/ path 285 requires hardware timestamping before hardware punts the packet to 286 the software for OAM processing. The "OAM Endpoint with Timestamp 287 and Punt" function (End.OTP for short) represents an OAM SID function 288 to implement the timestamp and punt behavior for an OAM packet. It 289 is described using the pseudocode as follows: 291 When N receives a packet destined to S and S is a local End.OTP SID, 292 N does: 294 1. Timestamp the packet ;; Ref1 296 2. Send the packet, along with an accurate timestamp, to the 297 OAM process ;; Ref2 299 Ref1: Timestamping SHOULD be done in hardware, as soon as possible 300 during the packet processing. 301 Ref2: The local OAM process SHOULD NOT generate ICMP error during 302 local SID S processing. 304 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 305 to set the SRH.Flags.O-flag = 0. 307 3.5. SRH TLV 309 [I-D.ietf-6man-segment-routing-header] defines TLVs of the Segment 310 Routing Header. 312 SRH TLV plays an important role in carrying OAM and Performance 313 Management (PM) metadata. 315 4. OAM Mechanisms 317 This section describes how OAM mechanisms can be implemented using 318 the OAM building blocks described in the previous section. 319 Additional OAM mechanisms will be added in a future revision of the 320 document. 322 [RFC4443] describes Internet Control Message Protocol for IPv6 323 (ICMPv6) that is used by IPv6 devices for network diagnostic and 324 error reporting purposes. As Segment Routing with IPv6 data plane 325 (SRv6) simply adds a new type of Routing Extension Header, existing 326 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 327 describes the applicability of ICMPv6 in the SRv6 network and how the 328 existing ICMPv6 mechanisms can be used for providing OAM 329 functionality. 331 The document does not propose any changes to the standard ICMPv6 332 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 334 4.1. Ping 336 There is no hardware or software change required for ping operation 337 at the classic IPv6 nodes in an SRv6 network. That includes the 338 classic IPv6 node with ingress, egress or transit roles. 339 Furthermore, no protocol changes are required to the standard ICMPv6 340 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 341 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 343 The following subsections outline some use cases of the ICMP ping in 344 the SRv6 networks. 346 4.1.1. Classic Ping 348 The existing mechanism to ping a remote IP prefix, along the shortest 349 path, continues to work without any modification. The initiator may 350 be an SRv6 node or a classic IPv6 node. Similarly, the egress or 351 transit may be an SRv6 capable node or a classic IPv6 node. 353 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 354 arbitrary segment list , it needs to initiate ICMPv6 ping 355 with an SR header containing the SID list . This is 356 illustrated using the topology in Figure 1. Assume all the links 357 have IGP metric 10 except both links between node2 and node3, which 358 have IGP metric set to 100. User issues a ping from node N1 to a 359 loopback of node 5, via segment list . 361 Figure 2 contains sample output for a ping request initiated at node 362 N1 to the loopback address of node N5 via a segment list . 365 > ping A:5:: via segment-list B:2:C31, B:4:C52 367 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 368 !!!!! 369 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 370 /0.749/0.931 ms 372 Figure 2 A sample ping output at an SRv6 capable node 374 All transit nodes process the echo request message like any other 375 data packet carrying SR header and hence do not require any change. 376 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 377 require any change to process the ICMPv6 echo request. For example, 378 in the ping example of Figure 2: 380 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 381 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 382 ICMPv6)(ICMPv6 Echo Request). 384 o Node N2, which is an SRv6 capable node, performs the standard SRH 385 processing. Specifically, it executes the END.X function 386 (B:2:C31) and forwards the packet on link3 to N3. 388 o Node N3, which is a classic IPv6 node, performs the standard IPv6 389 processing. Specifically, it forwards the echo request based on 390 DA B:4:C52 in the IPv6 header. 392 o Node N4, which is an SRv6 capable node, performs the standard SRH 393 processing. Specifically, it observes the END.X function 394 (B:4:C52) with PSP (Penultimate Segment POP) on the echo request 395 packet and removes the SRH and forwards the packet across link10 396 to N5. 398 o The echo request packet at N5 arrives as an IPv6 packet without an 399 SRH. Node N5, which is a classic IPv6 node, performs the standard 400 IPv6/ ICMPv6 processing on the echo request and responds, 401 accordingly. 403 4.1.2. Pinging a SID Function 405 The classic ping described in the previous section cannot be used to 406 ping a remote SID function, as explained using an example in the 407 following. 409 Consider the case where the user wants to ping the remote SID 410 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 411 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 412 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 413 receives the ICMPv6 echo request with DA set to B:4:C52 but the next 414 header is ICMPv6, instead of SRH. To solve this problem, the 415 initiator needs to mark the ICMPv6 echo request as an OAM packet. 417 The OAM packets are identified either by setting the O-flag in SRH or 418 by inserting the END.OP/ END.OTP SIDs at an appropriate place in the 419 SRH. The following illustration uses END.OTP SID but the procedures 420 are equally applicable to the END.OP SID. 422 In an SRv6 network, the user can exercise two flavors of the ping: 423 end-to-end ping or segment-by-segment ping, as outlined in the 424 following subsection. 426 4.1.2.1. End-to-end ping using END.OP/ END.OTP 428 The end-to-end ping illustration uses the END.OTP SID but the 429 procedures are equally applicable to the END.OP SID. 431 Consider the same example where the user wants to ping a remote SID 432 function B:4:C52, via B:2:C31, from node N1. To force a punt of the 433 ICMPv6 echo request at the node N4, node N1 inserts the END.OTP SID 434 just before the target SID B:4:C52 in the SRH. The ICMPv6 echo 435 request is processed at the individual nodes along the path as 436 follows: 438 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 439 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 440 NH=ICMPv6)(ICMPv6 Echo Request). 442 o Node N2, which is an SRv6 capable node, performs the standard SRH 443 processing. Specifically, it executes the END.X function 444 (B:2:C31) on the echo request packet. 446 o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, 447 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node 448 N3, which is a classic IPv6 node, performs the standard IPv6 449 processing. Specifically, it forwards the echo request based on 450 DA B:4:OTP in the IPv6 header. 452 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 453 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 454 processes the END.OTP SID, as described in the pseudocode in 455 Section 3. The packet gets time-stamped and punted to the ICMPv6 456 process for processing. The ICMPv6 process checks if the next SID 457 in SRH (the target SID B:4:C52) is locally programmed. 459 o If the target SID is not locally programmed, N4 responses with the 460 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 461 implemented (TBA)"); otherwise a success is returned. 463 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 465 Consider the same example where the user wants to ping a remote SID 466 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 467 the node N1 wants to get a response from each segment node in the SRH 468 as a "proof of transit". In other words, in the segment-by-segment 469 ping case, the node N1 expects a response from node N2 and node N4 470 for their respective local SID function. When a response to O-bit is 471 desired from the last SID in a SID-list, it is the responsibility of 472 the ingress node to use USP as the last SID. E.g., in this example, 473 the target SID B:4:C52 is a USP SID. 475 To force a punt of the ICMPv6 echo request at node N2 and node N4, 476 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 477 at the individual nodes along the path as follows: 479 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 480 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 481 NH=ICMPv6)(ICMPv6 Echo Request). 483 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 484 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet, 485 it processes the O-flag in SRH, as described in the pseudocode in 486 Section 3. A time-stamped copy of the packet gets punted to the 487 ICMPv6 process for processing. Node N2 continues to apply the 488 B:2:C31 SID function on the original packet and forwards it, 489 accordingly. As B:4:C52 is a USP SID, N2 does not remove the SRH. 490 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 491 locally programmed or not and responds to the ICMPv6 Echo Request. 493 o If the target SID is not locally programmed, N4 responses with the 494 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 495 implemented (TBA)"); otherwise a success is returned. Please note 496 that, as mentioned in Section 3, if node N2 does not support the 497 O-flag, it simply ignores it and process the local SID, B:2:C31. 499 o Node N3, which is a classic IPv6 node, performs the standard IPv6 500 processing. Specifically, it forwards the echo request based on 501 DA B:4:C52 in the IPv6 header. 503 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 504 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 505 processes the O-flag in SRH, as described in the pseudocode in 506 Section 3. A time-stamped copy of the packet gets punted to the 507 ICMPv6 process for processing. The ICMPv6 process at node N4 508 checks if its local SID (B:4:C52) is locally programmed or not and 509 responds to the ICMPv6 Echo Request. 511 o If the target SID is not locally programmed, N4 responses with the 512 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 513 implemented (TBA)"); otherwise a success is returned. 515 Support for O-flag is part of node capability advertisement. That 516 enables node N1 to know which segment nodes are capable of responding 517 to the ICMPv6 echo request. Node N1 processes the echo responses and 518 presents data to the user, accordingly. 520 Please note that segment-by-segment ping can be used to address proof 521 of transit use-case. 523 4.1.3. Error Reporting 525 Any IPv6 node can use ICMPv6 control messages to report packet 526 processing errors to the host that originated the datagram packet. 527 To name a few such scenarios: 529 o If the router receives an undeliverable IP datagram, or 531 o If the router receives a packet with a Hop Limit of zero, or 533 o If the router receives a packet such that if the router decrements 534 the packet's Hop Limit it becomes zero, or 536 o If the router receives a packet with problem with a field in the 537 IPv6 header or the extension headers such that it cannot complete 538 processing the packet, or 540 o If the router cannot forward a packet because the packet is larger 541 than the MTU of the outgoing link. 543 In the scenarios listed above, the ICMPv6 response also contains the 544 IP header, IP extension headers and leading payload octets of the 545 "original datagram" to which the ICMPv6 message is a response. 546 Specifically, the "Destination Unreachable Message", "Time Exceeded 547 Message", "Packet Too Big Message" and "Parameter Problem Message" 548 ICMPV6 messages can contain as much of the invoking packet as 549 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 550 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 551 packet contains the SR header. The packet originator can use this 552 information for diagnostic purposes. For example, traceroute can use 553 this information as detailed in the following subsection. 555 4.2. Traceroute 557 There is no hardware or software change required for traceroute 558 operation at the classic IPv6 nodes in an SRv6 network. That 559 includes the classic IPv6 node with ingress, egress or transit roles. 560 Furthermore, no protocol changes are required to the standard 561 traceroute operations. In other words, existing traceroute 562 mechanisms work seamlessly in the SRv6 networks. 564 The following subsections outline some use cases of the traceroute in 565 the SRv6 networks. 567 4.2.1. Classic Traceroute 569 The existing mechanism to traceroute a remote IP prefix, along the 570 shortest path, continues to work without any modification. The 571 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 572 egress or transit may be an SRv6 node or a classic IPv6 node. 574 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 575 via an arbitrary segment list , it needs to initiate 576 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 578 the links have IGP metric 10 except both links between node2 and 579 node3, which have IGP metric set to 100. User issues a traceroute 580 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 582 request. 584 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 586 Tracing the route to B5:: 587 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 588 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 589 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 590 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 591 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 592 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 593 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 595 Figure 3 A sample traceroute output at an SRv6 capable node 597 Please note that information for hop2 is returned by N3, which is a 598 classic IPv6 node. Nonetheless, the ingress node is able to display 599 SR header contents as the packet travels through the IPv6 classic 600 node. This is because the "Time Exceeded Message" ICMPv6 message can 601 contain as much of the invoking packet as possible without the ICMPv6 602 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 603 also included in these ICMPv6 messages initiated by the classic IPv6 604 transit nodes that are not running SRv6 software. Specifically, a 605 node generating ICMPv6 message containing a copy of the invoking 606 packet does not need to understand the extension header(s) in the 607 invoking packet. 609 The segment list information returned for hop1 is returned by N2, 610 which is an SRv6 capable node. Just like for hop2, the ingress node 611 is able to display SR header contents for hop1. 613 There is no difference in processing of the traceroute probe at an 614 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 615 classic and SRv6 capable nodes may use the address of the interface 616 on which probe was received as the source address in the ICMPv6 617 response. ICMP extensions defined in [RFC5837] can be used to also 618 display information about the IP interface through which the datagram 619 would have been forwarded had it been forwardable, and the IP next 620 hop to which the datagram would have been forwarded, the IP interface 621 upon which a datagram arrived, the sub-IP component of an IP 622 interface upon which a datagram arrived. 624 The information about the IP address of the incoming interface on 625 which the traceroute probe was received by the reporting node is very 626 useful. This information can also be used to verify if SID functions 627 B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 628 respectively. Specifically, the information displayed for hop2 629 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 630 This matches with the expected interface bound to END.X function 631 B:2:C31 (link3). Similarly, the information displayed for hop5 632 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 633 This matches with the expected interface bound to the END.X function 634 B:4:C52 (link10). 636 4.2.2. Traceroute to a SID Function 638 The classic traceroute described in the previous section cannot be 639 used to traceroute a remote SID function, as explained using an 640 example in the following. 642 Consider the case where the user wants to traceroute the remote SID 643 function B:4:C52, via B:2:C31, from node N1. The trace route fails 644 at N4. This is because the node N4 trace route probe where next 645 header is UDP or ICMPv6, instead of SRH (even though the hop limit is 646 set to 1). To solve this problem, the initiator needs to mark the 647 ICMPv6 echo request as an OAM packet. 649 The OAM packets are identified either by setting the O-flag in SRH or 650 by inserting the END.OP or END.OTP SID at an appropriate place in the 651 SRH. 653 In an SRv6 network, the user can exercise two flavors of the 654 traceroute: hop-by-hop traceroute or overlay traceroute. 656 o In hop-by-hop traceroute, user gets responses from all nodes 657 including classic IPv6 transit nodes, SRv6 capable transit nodes 658 as well as SRv6 capable segment endpoints. E.g., consider the 659 example where the user wants to traceroute to a remote SID 660 function B:4:C52, via B:2:C31, from node N1. The traceroute 661 output will also display information about node3, which is a 662 transit (underlay) node. 664 o The overlay traceroute, on the other hand, does not trace the 665 underlay nodes. In other words, the overlay traceroute only 666 displays the nodes that acts as SRv6 segments along the route. 667 I.e., in the example where the user wants to traceroute to a 668 remote SID function B:4:C52, via B:2:C31, from node N1, the 669 overlay traceroute would only display the traceroute information 670 from node N2 and node N4; it will not display information from 671 node 3. 673 4.2.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 675 In this section, hop-by-hop traceroute to a SID function is 676 exemplified using UDP probes. However, the procedure is equally 677 applicable to other implementation of traceroute mechanism. 679 Furthermore, the illustration uses the END.OTP SID but the procedures 680 are equally applicable to the END.OP SID. 682 Consider the same example where the user wants to traceroute to a 683 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 684 punt of the traceroute probe only at the node N4, node N1 inserts the 685 END.OTP SID just before the target SID B:4:C52 in the SRH. The 686 traceroute probe is processed at the individual nodes along the path 687 as follows: 689 o Node N1 initiates a traceroute probe packet with a monotonically 690 increasing value of hop count and SRH as follows (A:1::, 691 B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; NH=UDP)(Traceroute 692 probe). 694 o When node N2 receives the packet with hop-count = 1, it processes 695 the hop count expiry. Specifically, the node N2 responses with 696 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 697 exceeded in Transit"). 699 o When Node N2 receives the packet with hop-count > 1, it performs 700 the standard SRH processing. Specifically, it executes the END.X 701 function (B:2:C31) on the traceroute probe. 703 o When node N3, which is a classic IPv6 node, receives the packet 704 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 705 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the hop 706 count expiry. Specifically, the node N3 responses with the ICMPv6 707 message (Type: "Time Exceeded", Code: "Time to Live exceeded in 708 Transit"). 710 o When node N3, which is a classic IPv6 node, receives the packet 711 with hop-count > 1, it performs the standard IPv6 processing. 712 Specifically, it forwards the traceroute probe based on DA B:4:OTP 713 in the IPv6 header. 715 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 716 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 717 processes the END.OTP SID, as described in the pseudocode in 718 Section 3. The packet gets timestamped and punted to the 719 traceroute process for processing. The traceroute process checks 720 if the next SID in SRH (the target SID B:4:C52) is locally 721 programmed. 723 o If the target SID B:4:C52 is locally programmed, node N4 responses 724 with the ICMPv6 message (Type: Destination unreachable, Code: Port 725 Unreachable). If the target SID B:4:C52 is not a local SID, node 726 N4 silently drops the traceroute probe. 728 Figure 4 displays a sample traceroute output for this example. 730 > traceroute srv6 B:4:C52 via segment-list B:2:C31 732 Tracing the route to SID function B:4:C52 733 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 734 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 735 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 736 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 737 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 738 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 740 Figure 4 A sample output for hop-by-hop traceroute to a SID function 742 4.2.2.2. Tracing SRv6 Overlay 744 The overlay traceroute does not trace the underlay nodes, i.e., only 745 displays the nodes that acts as SRv6 segments along the path. This 746 is achieved by setting the SRH.Flags.O bit. 748 In this section, overlay traceroute to a SID function is exemplified 749 using UDP probes. However, the procedure is equally applicable to 750 other implementation of traceroute mechanism. 752 Consider the same example where the user wants to traceroute to a 753 remote SID function B:4:C52, via B:2:C31, from node N1. 755 o Node N1 initiates a traceroute probe with SRH as follows (A:1::, 756 B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 757 NH=UDP)(Traceroute Probe). Please note that the hop-count is set 758 to 64 to skip the underlay nodes from tracing. The O-flag in SRH 759 is set to make the overlay nodes (nodes processing the SRH) 760 respond. 762 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 763 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 764 processes the O-flag in SRH, as described in the pseudocode in 765 Section 3. A time-stamped copy of the packet gets punted to the 766 traceroute process for processing. Node N2 continues to apply the 767 B:2:C31 SID function on the original packet and forwards it, 768 accordingly. The traceroute process at node N2 checks if its 769 local SID (B:2:C31) is locally programmed. If the SID is not 770 locally programmed, it silently drops the packet. Otherwise, it 771 performs the egress check by looking at the SL value in SRH. 773 o As SL is not equal to zero (i.e., it's not egress node), node N2 774 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: 775 "O-flag punt at Transit (TBA)"). Please note that, as mentioned 776 in Section 3, if node N2 does not support the O-flag, it simply 777 ignores it and processes the local SID, B:2:C31. 779 o When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 780 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 781 performs the standard IPv6 processing. Specifically, it forwards 782 the traceroute probe based on DA B:4:C52 in the IPv6 header. 783 Please note that there is no hop-count expiration at the transit 784 nodes. 786 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 787 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 788 processes the O-flag in SRH, as described in the pseudocode in 789 Section 3. A time-stamped copy of the packet gets punted to the 790 traceroute process for processing. The traceroute process at node 791 N4 checks if its local SID (B:2:C31) is locally programmed. 793 o If the SID is not locally programmed, it silently drops the 794 packet. Otherwise, it performs the egress check by looking at the 795 SL value in SRH. As SL is equal to zero (i.e., N4 is the egress 796 node), node N4 tries to consume the UDP probe. As UDP probe is 797 set to access an invalid port, the node N4 responses with the 798 ICMPv6 message (Type: Destination unreachable, Code: Port 799 Unreachable) 801 Figure 5 displays a sample overlay traceroute output for this 802 example. Please note that the underlay node N3 does not appear in 803 the output. 805 Tracing the route to SID function B:4:C52 806 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 807 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 808 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 809 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=0) 811 Figure 5 A sample output for overlay traceroute to a SID function 813 4.3. Monitoring of SRv6 Paths 815 In the recent past, network operators are interested in performing 816 network OAM functions in a centralized manner. Various data models 817 like YANG are available to collect data from the network and manage 818 it from a centralized entity. 820 SR technology enables a centralized OAM entity to perform path 821 monitoring from centralized OAM entity without control plane 822 intervention on monitored nodes. [RFC 8403] describes such a 823 centralized OAM mechanism. Specifically, the draft describes a 824 procedure that can be used to perform path continuity check between 825 any nodes within an SR domain from a centralized monitoring system, 826 with minimal or no control plane intervene on the nodes. However, 827 the draft focuses on SR networks with MPLS data plane. The same 828 concept applies to the SRv6 networks. This document describes how 829 the concept can be used to perform path monitoring in an SRv6 830 network. This document describes how the concept can be used to 831 perform path monitoring in an SRv6 network as follows. 833 In the above reference topology, N100 is the centralized monitoring 834 system implementing an END function B:100:1::. In order to verify a 835 segment list , N100 generates a probe packet with 836 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller 837 routes the probe packet towards the first segment, which is B:2:C31. 838 N2 performs the standard SRH processing and forward it over link3 839 with the DA of IPv6 packet set to B:4:C52. N4 also performs the 840 normal SRH processing and forward it over link10 with the DA of IPv6 841 packet set to B:100:1::. This makes the probe loops back to the 842 centralized monitoring system. 844 In the reference topology in Figure 1, N100 uses an IGP protocol like 845 OSPF or ISIS to get the topology view within the IGP domain. N100 846 can also use BGP-LS to get the complete view of an inter-domain 847 topology. In other words, the controller leverages the visibility of 848 the topology to monitor the paths between the various endpoints 849 without control plane intervention required at the monitored nodes. 851 5. Implementation Status 853 This section is to be removed prior to publishing as an RFC. 855 See [I-D.matsushima-spring-srv6-deployment-status] for updated 856 deployment and interoperability reports. 858 6. Security Considerations 860 This document does not define any new protocol extensions and relies 861 on existing procedures defined for ICMP. This document does not 862 impose any additional security challenges to be considered beyond 863 security considerations described in [RFC4884], [RFC4443], [RFC792], 864 RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] 865 and [I-D.ietf-spring-srv6-network-programming]. 867 7. IANA Considerations 869 7.1. ICMPv6 type Numbers RegistrySEC 871 This document defines one ICMPv6 Message, a type that has been 872 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 873 Specifically, it requests to add the following to the "ICMPv6 Type 874 Numbers" registry: 876 TBA (suggested value: 162) SRv6 OAM Message. 878 The document also requests the creation of a new IANA registry to the 879 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 880 OAM Message" with the following codes: 882 Code Name Reference 883 -------------------------------------------------------- 884 0 No Error This document 885 1 SID is not locally implemented This document 886 2 O-flag punt at Transit This document 888 7.2. SRv6 OAM Endpoint Types 890 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 891 Behaviors Registry" sub-registry belonging to the top-level "Segment- 892 routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- 893 spring- srv6-network-programming], the following allocations: 895 +------------------+-------------------+-----------+ 896 | Value (Suggested | Endpoint Behavior | Reference | 897 | Value) | | | 898 +------------------+-------------------+-----------+ 899 | TBA (40) | End.OP | [This.ID] | 900 | TBA (41) | End.OTP | [This.ID] | 901 +------------------+-------------------+-----------+ 903 8. Acknowledgements 905 The authors would like to thank Gaurav Naik for his review comments. 907 9. Contributors 909 The following people have contributed to this document: 911 Robert Raszuk 912 Bloomberg LP 913 Email: robert@raszuk.net 915 John Leddy 916 Individual 917 Email: john@leddy.net 919 Gaurav Dawra 920 LinkedIn 921 Email: gdawra.ietf@gmail.com 923 Bart Peirens 924 Proximus 925 Email: bart.peirens@proximus.com 927 Nagendra Kumar 928 Cisco Systems, Inc. 929 Email: naikumar@cisco.com 931 Carlos Pignataro 932 Cisco Systems, Inc. 933 Email: cpignata@cisco.com 935 Rakesh Gandhi 936 Cisco Systems, Inc. 937 Canada 938 Email: rgandhi@cisco.com 940 Frank Brockners 941 Cisco Systems, Inc. 942 Germany 943 Email: fbrockne@cisco.com 945 Darren Dukes 946 Cisco Systems, Inc. 947 Email: ddukes@cisco.com 948 Cheng Li 949 Huawei 950 Email: chengli13@huawei.com 952 Faisal Iqbal 953 Individual 954 Email: faisal.ietf@gmail.com 956 10. References 958 10.1. Normative References 960 [I-D.ietf-6man-segment-routing-header] 961 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 962 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 963 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 964 progress), October 2019. 966 [I-D.ietf-spring-srv6-network-programming] 967 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 968 Matsushima, S., and Z. Li, "SRv6 Network Programming", 969 draft-ietf-spring-srv6-network-programming-05 (work in 970 progress), October 2019. 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, 974 DOI 10.17487/RFC2119, March 1997, 975 . 977 10.2. Informative References 979 [I-D.matsushima-spring-srv6-deployment-status] 980 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 981 Implementation and Deployment Status", draft-matsushima- 982 spring-srv6-deployment-status-02 (work in progress), 983 October 2019. 985 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 986 RFC 792, DOI 10.17487/RFC0792, September 1981, 987 . 989 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 990 Control Message Protocol (ICMPv6) for the Internet 991 Protocol Version 6 (IPv6) Specification", STD 89, 992 RFC 4443, DOI 10.17487/RFC4443, March 2006, 993 . 995 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 996 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 997 DOI 10.17487/RFC4884, April 2007, 998 . 1000 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 1001 N., and JR. Rivers, "Extending ICMP for Interface and 1002 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 1003 April 2010, . 1005 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 1006 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 1007 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 1008 2018, . 1010 Authors' Addresses 1012 Zafar Ali 1013 Cisco Systems 1015 Email: zali@cisco.com 1017 Clarence Filsfils 1018 Cisco Systems 1020 Email: cfilsfil@cisco.com 1022 Satoru Matsushima 1023 Softbank 1025 Email: satoru.matsushima@g.softbank.co.jp 1027 Daniel Voyer 1028 Bell Canada 1030 Email: daniel.voyer@bell.ca 1032 Mach Chen 1033 Huawei 1035 Email: mach.chen@huawei.com