idnits 2.17.1 draft-ietf-6man-spring-srv6-oam-03.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 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 5 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: To perform ICMPv6 ping to a target SID an echo request message is generated by the initiator with the END.OP or END.OTP SID in the segment-list of the SRH immediately preceding the target SID. There MAY or MAY NOT be additional segments preceding the END.OP/ END.OTP SID. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: To traceroute a target SID a probe message is generated by the initiator with the END.OP or END.OTP SID in the segment-list of the SRH immediately preceding the target SID. There MAY or MAY NOT be additional segments preceding the END.OP/ END.OTP SID. -- The document date (December 18, 2019) is 1590 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 190, but not defined -- Looks like a reference, but probably isn't: '2' on line 191 -- Looks like a reference, but probably isn't: '1' on line 191 -- Looks like a reference, but probably isn't: '0' on line 192 == Missing Reference: 'RFC7011' is mentioned on line 230, but not defined == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line 241, but not defined == Missing Reference: 'RFC792' is mentioned on line 701, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 660, but not defined == Unused Reference: 'RFC0792' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 843, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-06 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-04 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 5 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: June 20, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 December 18, 2019 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-03 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 June 20, 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 . . . . . . . . . . . . . 7 72 3.4. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 7 73 4. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 8 76 4.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 9 77 4.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 11 79 4.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 12 80 4.3. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 15 81 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. ICMPv6 type Numbers RegistrySEC . . . . . . . . . . . . . 16 85 7.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 16 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 10.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 This document defines building blocks for Operations, Administration, 96 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 97 (SRv6). The document also describes some SRv6 OAM mechanisms. 99 2. Conventions Used in This Document 101 2.1. Abbreviations 103 The following abbreviations are used in this document: 105 SID: Segment ID. 107 SL: Segment Left. 109 SR: Segment Routing. 111 SRH: Segment Routing Header. 113 SRv6: Segment Routing with IPv6 Data plane. 115 TC: Traffic Class. 117 ICMPv6: ICMPv6 Specification [RFC4443]. 119 2.2. Terminology and Reference Topology 121 This document uses the terminology defined in [I-D.ietf- spring-srv6- 122 network-programming]. The readers are expected to be familiar with 123 the same. 125 Throughout the document, the following simple topology is used for 126 illustration. 128 +--------------------------| N100 |------------------------+ 129 | | 130 ====== link1====== link3------ link5====== link9------ 131 ||N1||======||N2||======| N3 |======||N4||======| N5 | 132 || ||------|| ||------| |------|| ||------| | 133 ====== link2====== link4------ link6======link10------ 134 | | 135 | ------ | 136 +-------| N6 |---------+ 137 link7 | | link8 138 ------ 140 Figure 1 Reference Topology 142 In the reference topology: 144 Nodes N1, N2, and N4 are SRv6 capable nodes. 146 Nodes N3, N5 and N6 are classic IPv6 nodes. 148 Node N100 is a controller. 150 Node k has a classic IPv6 loopback address A:k::/128. 152 A SID at node k with locator block B and function F is represented 153 by B:k:F::. 155 The IPv6 address of the nth Link between node X and Y at the X 156 side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address 157 of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 158 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 159 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 161 B:k:Cij:: is explicitly allocated as the END.X function at node k 162 towards neighbor node i via jth Link between node i and node j. 163 e.g., B:2:C31:: represents END.X at N2 towards N3 via link3 (the 164 1st link between N2 and N3). Similarly, B:4:C52:: represents the 165 END.X at N4 towards N5 via link10. 167 A SID list is represented as where S1 is the first 168 SID to visit, S2 is the second SID to visit and S3 is the last SID 169 to visit along the SR path. 171 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 173 * IPv6 header with source address SA, destination addresses DA 174 and SRH as next-header 176 * SRH with SID list with SegmentsLeft = SL 178 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 180 the last SID to traverse. (S3, S2, S1; SL) represents the same 181 SID list but encoded in the SRH format where the rightmost SID 182 in the SRH is the first SID and the leftmost SID in the SRH is 183 the last SID. When referring to an SR policy in a high-level 184 use-case, it is simpler to use the notation. When 185 referring to an illustration of the detailed packet behavior, 186 the (S3, S2, S1; SL) notation is more convenient. 188 * (payload) represents the the payload of the packet. 190 SRH[SL] represents the SID pointed by the SL field in the first 191 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 192 and SRH[0] represents S3. 194 3. OAM Building Blocks 196 This section defines the various building blocks for implementing OAM 197 mechanisms in SRv6 networks. 199 3.1. O-flag in Segment Routing Header 201 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 202 Header (SRH) and how SR capable nodes use it. The SRH contains an 203 8-bit "Flags" field [I-D.draft-ietf-6man-segment- routing-header]. 204 This document defines the following bit in the SRH.Flags to carry the 205 O-flag: 207 0 1 2 3 4 5 6 7 208 +-+-+-+-+-+-+-+-+ 209 | |O| | 210 +-+-+-+-+-+-+-+-+ 212 Where: 214 O-flag: OAM flag. When set, it indicates that this packet is an 215 operations and management (OAM) packet. This document defines the 216 usage of the O-flag in the SRH.Flags. 218 The document does not define any other flag in the SRH.Flags and 219 meaning and processing of any other bit in SRH.Flags is outside of 220 the scope of this document. 222 3.1.1. O-flag Processing 224 The SRH.Flags.O-flag implements the "punt a timestamped copy of the 225 packet" behavior. This enables an SRv6 Endpoint node to send a 226 timestamped copy of the packets marked with o-flag to a local OAM 227 process. To prevent multiple evaluations of the datagram, the OAM 228 process MUST NOT respond to any upper-layer header (like ICMP, UDP, 229 etc.) payload. However, the OAM process MAY export the time-stamped 230 copy of the packet to a controller using e.g., IPFIX [RFC7011]. To 231 avoid hitting any performance impact, the processing node SHOULD 232 rate-limit the number of packets punted to the OAM process. 233 Specification of the OAM process or the external controller 234 operations are beyond the scope of this document. 236 Implementation of the O-flag is OPTIONAL. If a node does not support 237 the O-flag, then upon reception it simply ignores it. 239 If a node supports the O-flag, it can optionally advertise its 240 potential via node capability advertisement in IGP [I-D.ietf-isis- 241 srv6- extensions] and BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. 243 When N receives a packet whose IPv6 DA is S and S is a local SID, the 244 line S01 of the the pseudo-code associated with the SID S, as defined 245 in section 4.3.1.1 of [I-D.ietf-6man-segment-routing-header], is 246 modified as follows for the O-flag processing. 248 S01.1. IF SRH.Flags.O-flag is set and local configuration permits 249 O-flag processing THEN 250 a. Make a copy of the packet. 251 b. Send the copied packet, along with a timestamp 252 to the OAM process. ;; Ref1 253 Ref1: An implementation SHOULD copy and record the timestamp as soon as 254 possible during packet processing. Timestamp is not carried in the packet 255 forwarded to the next hop. 257 Please note that the O-flag processing happens before execution of 258 regular processing of the local SID S. 260 3.2. OAM Segments 262 The presence of an OAM SID in the Destination address of the IPv6 263 header instructs the segment endpoint implementing the OAM SID that 264 the content of the packet is of interest to the node and to process 265 the upper-layer payload, accordingly. 267 3.3. End.OP: OAM Endpoint with Punt 269 When N receives a packet destined to S and S is a local End.OP SID, N 270 does: 272 S01. Send the packet to the OAM process 274 The local OAM process further processes the packet, this MAY involve 275 processing protocol layers above IPv6. For example, ping and 276 traceroute will require ICMP or UDP protocol processing. Once the 277 packet leaves the IPv6 layer the processing is considered host 278 processing and the upper layer protocols MUST be processed as such. 280 3.4. End.OTP: OAM Endpoint with Timestamp and Punt 282 When N receives a packet destined to S and S is a local End.OTP SID, 283 N does: 285 S01.1. Timestamp the packet ;; Ref1 286 S01.2. Send the packet, along with a timestamp, to the 287 OAM process 288 Ref1: Timestamping SHOULD be done in hardware, as soon as possible 289 during the packet processing. 291 The local OAM process further processes the packet, this MAY involve 292 processing protocol layers above IPv6. For example, ping and 293 traceroute will require ICMP or UDP protocol processing. Once the 294 packet leaves the IPv6 layer the processing is considered host 295 processing and the upper layer protocols MUST be processed as such. 297 4. OAM Mechanisms 299 This section describes how OAM mechanisms can be implemented using 300 the OAM building blocks described in the previous section. 302 [RFC4443] describes Internet Control Message Protocol for IPv6 303 (ICMPv6) that is used by IPv6 devices for network diagnostic and 304 error reporting purposes. As Segment Routing with IPv6 data plane 305 (SRv6) simply adds a new type of Routing Extension Header, existing 306 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 307 describes the applicability of ICMPv6 in the SRv6 network and how the 308 existing ICMPv6 mechanisms can be used for providing OAM 309 functionality. 311 The document does not propose any changes to the standard ICMPv6 312 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 314 4.1. Ping 316 The following subsections outline some use cases of the ICMP ping in 317 the SRv6 networks. 319 4.1.1. Classic Ping 321 The existing mechanism to ping a remote IP prefix, along the shortest 322 path, continues to work without any modification. The initiator may 323 be an SRv6 node or a classic IPv6 node. Similarly, the egress or 324 transit may be an SRv6 capable node or a classic IPv6 node. 326 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 327 arbitrary segment list , it needs to initiate ICMPv6 ping 328 with an SR header containing the SID list . This is 329 illustrated using the topology in Figure 1. Assume all the links 330 have IGP metric 10 except both links between node2 and node3, which 331 have IGP metric set to 100. User issues a ping from node N1 to a 332 loopback of node 5, via segment list . 334 Figure 2 contains sample output for a ping request initiated at node 335 N1 to the loopback address of node N5 via a segment list . 338 > ping A:5:: via segment-list B:2:C31, B:4:C52 340 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 341 !!!!! 342 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 343 /0.749/0.931 ms 345 Figure 2 A sample ping output at an SRv6 capable node 347 All transit nodes process the echo request message like any other 348 data packet carrying SR header and hence do not require any change. 349 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 350 require any change to process the ICMPv6 echo request. For example, 351 in the ping example of Figure 2: 353 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 354 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 355 ICMPv6)(ICMPv6 Echo Request). 357 o Node N2, which is an SRv6 capable node, performs the standard SRH 358 processing. Specifically, it executes the END.X function 359 (B:2:C31) and forwards the packet on link3 to N3. 361 o Node N3, which is a classic IPv6 node, performs the standard IPv6 362 processing. Specifically, it forwards the echo request based on 363 DA B:4:C52 in the IPv6 header. 365 o Node N4, which is an SRv6 capable node, performs the standard SRH 366 processing. Specifically, it observes the END.X function 367 (B:4:C52) with PSP (Penultimate Segment POP) on the echo request 368 packet and removes the SRH and forwards the packet across link10 369 to N5. 371 o The echo request packet at N5 arrives as an IPv6 packet without an 372 SRH. Node N5, which is a classic IPv6 node, performs the standard 373 IPv6/ ICMPv6 processing on the echo request and responds, 374 accordingly. 376 4.1.2. Pinging a SID 378 The classic ping described in the previous section cannot be used to 379 ping a remote SID function, as explained using an example in the 380 following. 382 Consider the case where the user wants to ping the remote SID 383 function B:4:C52 from node N1. Node N1 constructs the ping packet 384 (A:1::, B:4:C52)(ICMPv6 Echo Request). The ping fails because the 385 node N4 receives the ICMPv6 echo request with DA set to B:4:C52 but 386 the next header is ICMPv6, instead of SRH. 388 To perform ICMPv6 ping to a target SID an echo request message is 389 generated by the initiator with the END.OP or END.OTP SID in the 390 segment-list of the SRH immediately preceding the target SID. There 391 MAY or MAY NOT be additional segments preceding the END.OP/ END.OTP 392 SID. 394 When the node instantiating a SID S of type END.OP or END.OTP 395 receives a packet with S in the destination address of the IPv6 396 header it sends it to the OAM process. The OAM process verifies the 397 segment following S is a locally instantiated SID. It then processes 398 the Upper layer header of the packet, as a host, responding to the 399 echo request message in the ICMPv6 payload. 401 When the segment following S is not verified by the OAM process an 402 ICMPv6 error message type 4 (parameter problem) code 0 (erroneous 403 header field encountered) with pointer set to the segment following S 404 (the target SID) is generated for the packet and the packet is 405 discarded. 407 An implementation of the OAM process SID verification SHOULD do the 408 following: 410 o Verify that the SID is locally instantiated. 412 o Verify that the SID is instantiated in the data plane (this may 413 include verification of the SID in NPUs or forwarding hardware, as 414 applicable). 416 4.1.2.1. Ping using END.OP/ END.OTP 418 This section uses END.OTP SID for the ping illustration but the 419 procedures are equally applicable to the END.OP SID. 421 Consider the example where the user wants to ping a remote SID 422 function B:4:C52, via B:2:C31, from node N1. To force a punt of the 423 ICMPv6 echo request at the node N4, node N1 inserts the END.OTP SID 424 just before the target SID B:4:C52 in the SRH. The ICMPv6 echo 425 request is processed at the individual nodes along the path as 426 follows: 428 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 429 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 430 NH=ICMPv6)(ICMPv6 Echo Request). 432 o Node N2, which is an SRv6 capable node, performs the standard SRH 433 processing. Specifically, it executes the END.X function 434 (B:2:C31) on the echo request packet. 436 o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, 437 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node 438 N3, which is a classic IPv6 node, performs the standard IPv6 439 processing. Specifically, it forwards the echo request based on 440 DA B:4:OTP in the IPv6 header. 442 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 443 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 444 processes the END.OTP SID, as described in the pseudocode in 445 Section 3. The packet gets time-stamped and punted to the OAM 446 process for processing. The OAM process checks if the next SID in 447 SRH (the target SID B:4:C52) is locally programmed. 449 o If the next SID is not locally programmed, the OAM process returns 450 an ICMPv6 error message type 4 (parameter problem) code 0 451 (erroneous header field encountered) with pointer set to the 452 target SID B:4:C52 and the packet is discarded. 454 o If the next SID is locally programmed, the node processes the 455 upper layer header. As part of the upper layer header (ICMPv6) 456 processing node N4 sends the ICMPv6 Echo Reply message [RFC4443]. 458 4.2. Traceroute 460 There is no hardware or software change required for traceroute 461 operation at the classic IPv6 nodes in an SRv6 network. That 462 includes the classic IPv6 node with ingress, egress or transit roles. 463 Furthermore, no protocol changes are required to the standard 464 traceroute operations. In other words, existing traceroute 465 mechanisms work seamlessly in the SRv6 networks. 467 The following subsections outline some use cases of the traceroute in 468 the SRv6 networks. 470 4.2.1. Classic Traceroute 472 The existing mechanism to traceroute a remote IP prefix, along the 473 shortest path, continues to work without any modification. The 474 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 475 egress or transit may be an SRv6 node or a classic IPv6 node. 477 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 478 via an arbitrary segment list , it needs to initiate 479 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 481 the links have IGP metric 10 except both links between node2 and 482 node3, which have IGP metric set to 100. User issues a traceroute 483 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 485 request. 487 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 489 Tracing the route to A:5:: 490 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 491 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 492 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 493 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 494 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 495 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 496 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 498 Figure 3 A sample traceroute output at an SRv6 capable node 500 Please note that information for hop2 is returned by N3, which is a 501 classic IPv6 node. Nonetheless, the ingress node is able to display 502 SR header contents as the packet travels through the IPv6 classic 503 node. This is because the "Time Exceeded Message" ICMPv6 message can 504 contain as much of the invoking packet as possible without the ICMPv6 505 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 506 also included in these ICMPv6 messages initiated by the classic IPv6 507 transit nodes that are not running SRv6 software. Specifically, a 508 node generating ICMPv6 message containing a copy of the invoking 509 packet does not need to understand the extension header(s) in the 510 invoking packet. 512 The segment list information returned for hop1 is returned by N2, 513 which is an SRv6 capable node. Just like for hop2, the ingress node 514 is able to display SR header contents for hop1. 516 There is no difference in processing of the traceroute probe at an 517 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 518 classic and SRv6 capable nodes may use the address of the interface 519 on which probe was received as the source address in the ICMPv6 520 response. ICMP extensions defined in [RFC5837] can be used to also 521 display information about the IP interface through which the datagram 522 would have been forwarded had it been forwardable, and the IP next 523 hop to which the datagram would have been forwarded, the IP interface 524 upon which a datagram arrived, the sub-IP component of an IP 525 interface upon which a datagram arrived. 527 The information about the IP address of the incoming interface on 528 which the traceroute probe was received by the reporting node is very 529 useful. This information can also be used to verify if SID functions 530 B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 531 respectively. Specifically, the information displayed for hop2 532 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 533 This matches with the expected interface bound to END.X function 534 B:2:C31 (link3). Similarly, the information displayed for hop5 535 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 536 This matches with the expected interface bound to the END.X function 537 B:4:C52 (link10). 539 4.2.2. Traceroute to a SID 541 The classic traceroute described in the previous section cannot be 542 used to traceroute a remote SID function, as explained using an 543 example in the following. 545 Consider the case where the user wants to traceroute the remote SID 546 function B:4:C52 from node N1. The trace route fails at N4. This is 547 because the node N4 receives a trace route probe where next header is 548 UDP or ICMPv6, instead of SRH (even though the hop limit is set to 549 1). 551 To traceroute a target SID a probe message is generated by the 552 initiator with the END.OP or END.OTP SID in the segment-list of the 553 SRH immediately preceding the target SID. There MAY or MAY NOT be 554 additional segments preceding the END.OP/ END.OTP SID. 556 The node instantiating a SID S of type END.OP or END.OTP receives a 557 packet with S in the destination address of the IPv6 header and sends 558 it to the OAM process (before processing the TTL). The OAM process 559 verifies the segment following S is a locally instantiated SID. It 560 then processes the Upper layer header of the packet, as a host, 561 responding to the probe message. 563 When the segment following S is not verified by the OAM process an 564 ICMPv6 error message type 4 (parameter problem) code 0 (erroneous 565 header field encountered) with pointer set to the segment following S 566 (the target SID) is generated for the packet and the packet is 567 discarded. 569 An implementation of the OAM process SID verification SHOULD do the 570 following: 572 o Verify that the SID is locally instantiated. 574 o Verify that the SID is instantiated in the data plane (this may 575 include verification of the SID in NPUs or forwarding hardware, as 576 applicable). 578 4.2.2.1. Traceroute using END.OP/ END.OTP 580 In this section, hop-by-hop traceroute to a SID function is 581 exemplified using UDP probes. However, the procedure is equally 582 applicable to other implementation of traceroute mechanism. 583 Furthermore, the illustration uses the END.OTP SID but the procedures 584 are equally applicable to the END.OP SID. 586 Consider the same example where the user wants to traceroute to a 587 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 588 punt of the traceroute probe only at the node N4, node N1 inserts the 589 END.OTP SID just before the target SID B:4:C52 in the SRH. The 590 traceroute probe is processed at the individual nodes along the path 591 as follows: 593 o Node N1 initiates a traceroute probe packet with a monotonically 594 increasing value of hop count and SRH as follows (A:1::, 595 B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; NH=UDP)(Traceroute 596 probe). 598 o When node N2 receives the packet with hop-count = 1, it processes 599 the hop count expiry. Specifically, the node N2 responses with 600 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 601 exceeded in Transit"). 603 o When Node N2 receives the packet with hop-count > 1, it performs 604 the standard SRH processing. Specifically, it executes the END.X 605 function (B:2:C31) on the traceroute probe. 607 o When node N3, which is a classic IPv6 node, receives the packet 608 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 609 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the hop 610 count expiry. Specifically, the node N3 responses with the ICMPv6 611 message (Type: "Time Exceeded", Code: "Time to Live exceeded in 612 Transit"). 614 o When node N3, which is a classic IPv6 node, receives the packet 615 with hop-count > 1, it performs the standard IPv6 processing. 616 Specifically, it forwards the traceroute probe based on DA B:4:OTP 617 in the IPv6 header. 619 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 620 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 621 processes the END.OTP SID, as described in the pseudocode in 622 Section 3. Before hop-limit processing, the packet gets 623 timestamped and punted to the OAM process for processing. The OAM 624 process checks if the next SID in SRH (the target SID B:4:C52) is 625 locally programmed. 627 o If the next SID is not locally programmed, the OAM process returns 628 an ICMPv6 error message type 4 (parameter problem) code 0 629 (erroneous header field encountered) with pointer set to the 630 target SID B:4:C52 and the packet is discarded. 632 o If the next SID is locally programmed, the node processes the 633 upper layer header. As part of the upper layer header processing 634 node N4 responses with the ICMPv6 message (Type: Destination 635 unreachable, Code: Port Unreachable). 637 Figure 4 displays a sample traceroute output for this example. 639 > traceroute srv6 B:4:C52 via segment-list B:2:C31 641 Tracing the route to SID function B:4:C52 642 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 643 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 644 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 645 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 646 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 647 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 649 Figure 4 A sample output for hop-by-hop traceroute to a SID function 651 4.3. Monitoring of SRv6 Paths 653 In the recent past, network operators are interested in performing 654 network OAM functions in a centralized manner. Various data models 655 like YANG are available to collect data from the network and manage 656 it from a centralized entity. 658 SR technology enables a centralized OAM entity to perform path 659 monitoring from centralized OAM entity without control plane 660 intervention on monitored nodes. [RFC 8403] describes such a 661 centralized OAM mechanism. Specifically, the draft describes a 662 procedure that can be used to perform path continuity check between 663 any nodes within an SR domain from a centralized monitoring system, 664 with minimal or no control plane intervene on the nodes. However, 665 the draft focuses on SR networks with MPLS data plane. The same 666 concept applies to the SRv6 networks. This document describes how 667 the concept can be used to perform path monitoring in an SRv6 668 network. This document describes how the concept can be used to 669 perform path monitoring in an SRv6 network as follows. 671 In the above reference topology, N100 is the centralized monitoring 672 system implementing an END function B:100:1::. In order to verify a 673 segment list , N100 generates a probe packet with 674 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller 675 routes the probe packet towards the first segment, which is B:2:C31. 676 N2 performs the standard SRH processing and forward it over link3 677 with the DA of IPv6 packet set to B:4:C52. N4 also performs the 678 normal SRH processing and forward it over link10 with the DA of IPv6 679 packet set to B:100:1::. This makes the probe loops back to the 680 centralized monitoring system. 682 In the reference topology in Figure 1, N100 uses an IGP protocol like 683 OSPF or ISIS to get the topology view within the IGP domain. N100 684 can also use BGP-LS to get the complete view of an inter-domain 685 topology. In other words, the controller leverages the visibility of 686 the topology to monitor the paths between the various endpoints 687 without control plane intervention required at the monitored nodes. 689 5. Implementation Status 691 This section is to be removed prior to publishing as an RFC. 693 See [I-D.matsushima-spring-srv6-deployment-status] for updated 694 deployment and interoperability reports. 696 6. Security Considerations 698 This document does not define any new protocol extensions and relies 699 on existing procedures defined for ICMP. This document does not 700 impose any additional security challenges to be considered beyond 701 security considerations described in [RFC4884], [RFC4443], [RFC792], 702 RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] 703 and [I-D.ietf-spring-srv6-network-programming]. 705 7. IANA Considerations 707 7.1. ICMPv6 type Numbers RegistrySEC 709 This document defines one ICMPv6 Message, a type that has been 710 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 711 Specifically, it requests to add the following to the "ICMPv6 Type 712 Numbers" registry: 714 TBA (suggested value: 162) SRv6 OAM Message. 716 The document also requests the creation of a new IANA registry to the 717 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 718 OAM Message" with the following codes: 720 Code Name Reference 721 -------------------------------------------------------- 722 0 No Error This document 723 1 SID is not locally implemented This document 724 2 O-flag punt at Transit This document 726 7.2. SRv6 OAM Endpoint Types 728 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 729 Behaviors Registry" sub-registry belonging to the top-level "Segment- 730 routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- 731 spring- srv6-network-programming], the following allocations: 733 +------------------+-------------------+-----------+ 734 | Value (Suggested | Endpoint Behavior | Reference | 735 | Value) | | | 736 +------------------+-------------------+-----------+ 737 | TBA (40) | End.OP | [This.ID] | 738 | TBA (41) | End.OTP | [This.ID] | 739 +------------------+-------------------+-----------+ 741 8. Acknowledgements 743 The authors would like to thank Gaurav Naik for his review comments. 745 9. Contributors 747 The following people have contributed to this document: 749 Robert Raszuk 750 Bloomberg LP 751 Email: robert@raszuk.net 753 John Leddy 754 Individual 755 Email: john@leddy.net 757 Gaurav Dawra 758 LinkedIn 759 Email: gdawra.ietf@gmail.com 761 Bart Peirens 762 Proximus 763 Email: bart.peirens@proximus.com 765 Nagendra Kumar 766 Cisco Systems, Inc. 767 Email: naikumar@cisco.com 769 Carlos Pignataro 770 Cisco Systems, Inc. 771 Email: cpignata@cisco.com 772 Rakesh Gandhi 773 Cisco Systems, Inc. 774 Canada 775 Email: rgandhi@cisco.com 777 Frank Brockners 778 Cisco Systems, Inc. 779 Germany 780 Email: fbrockne@cisco.com 782 Darren Dukes 783 Cisco Systems, Inc. 784 Email: ddukes@cisco.com 786 Cheng Li 787 Huawei 788 Email: chengli13@huawei.com 790 Faisal Iqbal 791 Individual 792 Email: faisal.ietf@gmail.com 794 10. References 796 10.1. Normative References 798 [I-D.ietf-6man-segment-routing-header] 799 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 800 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 801 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 802 progress), October 2019. 804 [I-D.ietf-spring-srv6-network-programming] 805 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 806 Matsushima, S., and Z. Li, "SRv6 Network Programming", 807 draft-ietf-spring-srv6-network-programming-06 (work in 808 progress), December 2019. 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, 812 DOI 10.17487/RFC2119, March 1997, 813 . 815 10.2. Informative References 817 [I-D.matsushima-spring-srv6-deployment-status] 818 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 819 Implementation and Deployment Status", draft-matsushima- 820 spring-srv6-deployment-status-04 (work in progress), 821 December 2019. 823 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 824 RFC 792, DOI 10.17487/RFC0792, September 1981, 825 . 827 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 828 Control Message Protocol (ICMPv6) for the Internet 829 Protocol Version 6 (IPv6) Specification", STD 89, 830 RFC 4443, DOI 10.17487/RFC4443, March 2006, 831 . 833 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 834 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 835 DOI 10.17487/RFC4884, April 2007, 836 . 838 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 839 N., and JR. Rivers, "Extending ICMP for Interface and 840 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 841 April 2010, . 843 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 844 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 845 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 846 2018, . 848 Authors' Addresses 850 Zafar Ali 851 Cisco Systems 853 Email: zali@cisco.com 855 Clarence Filsfils 856 Cisco Systems 858 Email: cfilsfil@cisco.com 859 Satoru Matsushima 860 Softbank 862 Email: satoru.matsushima@g.softbank.co.jp 864 Daniel Voyer 865 Bell Canada 867 Email: daniel.voyer@bell.ca 869 Mach Chen 870 Huawei 872 Email: mach.chen@huawei.com