idnits 2.17.1 draft-ali-6man-spring-srv6-oam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 102 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 219: '...of the O-flag is OPTIONAL. A node MAY ...' RFC 2119 keyword, line 221: '...d on a local decision it MAY ignore it...' RFC 2119 keyword, line 271: '...ntaining END.OP SID, it is RECOMMENDED...' RFC 2119 keyword, line 296: '...taining END.OTP SID, it is RECOMMENDED...' RFC 2119 keyword, line 841: '...t reserved field MUST be set to zero u...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 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: 'RFC4302' is mentioned on line 854, but not defined == Missing Reference: 'I-D.6man-extension-header-insertion' is mentioned on line 861, but not defined == Missing Reference: 'I-D.spring-srv6-network-programming' is mentioned on line 879, but not defined == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-oam-usecase' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-data' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-transport' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 1062, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group Z. Ali 2 Internet-Draft C. Filsfils 3 Intended status: Standards Track N. Kumar 4 Expires: September 10, 2019 C. Pignataro 5 R. Gandhi 6 F. Brockners 7 Cisco Systems, Inc. 8 J. Leddy 9 Individual 10 S. Matsushima 11 SoftBank 12 R. Raszuk 13 Bloomberg LP 14 D. Voyer 15 Bell Canada 16 G. Dawra 17 LinkedIn 18 B. Peirens 19 Proximus 20 M. Chen 21 C. Li 22 Huawei 23 F. Iqbal 24 Individual 25 G. Naik 26 Drexel University 27 March 11, 2019 29 Operations, Administration, and Maintenance (OAM) in Segment 30 Routing Networks with IPv6 Data plane (SRv6) 31 draft-ali-6man-spring-srv6-oam-00.txt 33 Abstract 35 This document defines building blocks for Operations, Administration, 36 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 37 (SRv6). The document also describes some SRv6 OAM mechanisms. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 70 1. Introduction.........................................................3 71 2. Conventions Used in This Document..............................3 72 2.1. Abbreviations.............................................3 73 2.2. Terminology and Reference Topology........................3 74 3. OAM Building Blocks............................................4 75 3.1. O-flag in Segment Routing Header..........................4 76 3.1.1. O-flag Processing....................................5 77 3.2. OAM Segments..............................................5 78 3.2.1. End.OP: OAM Endpoint with Punt.......................6 79 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt........6 80 3.3. SRH TLV...................................................7 81 4. OAM Mechanisms.................................................7 82 4.1. Ping......................................................7 83 4.1.1. Classic Ping.........................................7 84 4.1.2. Pinging a SID Function...............................9 85 4.2. Error Reporting..........................................11 86 4.3. Traceroute...............................................11 87 4.3.1. Classic Traceroute..................................12 88 4.3.2. Traceroute to a SID Function........................13 89 4.4. OAM Data Piggybacked in Data traffic.....................17 90 4.4.1. IOAM Data Field Encapsulation in SRH................17 91 4.4.2. Procedure...........................................18 92 4.5. Monitoring of SRv6 Paths.................................20 93 5. Security Considerations.......................................20 94 6. IANA Considerations...........................................21 95 6.1. ICMPv6 type Numbers Registry.............................21 96 6.2. SRv6 OAM Endpoint Types..................................21 97 6.3. SRv6 IOAM TLV............................................21 98 7. References....................................................22 99 7.1. Normative References.....................................22 100 7.2. Informative References...................................23 102 1. Introduction 104 This document defines building blocks for 105 Operations, Administration, and Maintenance (OAM) in Segment Routing 106 Networks with IPv6 Dataplane (SRv6). The document also describes 107 some SRv6 OAM mechanisms. 109 2. Conventions Used in This Document 111 2.1. Abbreviations 113 ECMP: Equal Cost Multi-Path. 115 SID: Segment ID. 117 SL: Segment Left. 119 SR: Segment Routing. 121 SRH: Segment Routing Header. 123 SRv6: Segment Routing with IPv6 Data plane. 125 TC: Traffic Class. 127 UCMP: Unequal Cost Multi-Path. 129 ICMPv6: multi-part ICMPv6 messages [RFC4884]. 131 2.2. Terminology and Reference Topology 133 This document uses the terminology defined in [I-D.draft-filsfils- 134 spring-srv6-network-programming]. The readers are expected to be 135 familiar with the same. 137 Throughout the document, the following simple topology is used for 138 illustration. 140 +--------------------------| N100 |------------------------+ 141 | | 142 ====== link1====== link3------ link5====== link9------ 143 ||N1||======||N2||======| N3 |======||N4||======| N5 | 144 || ||------|| ||------| |------|| ||------| | 145 ====== link2====== link4------ link6======link10------ 146 | | 147 | ------ | 148 +-------| N6 |---------+ 149 link7 | | link8 150 ------ 152 Figure 1 Reference Topology 154 In the reference topology: 156 Nodes N1, N2, and N4 are SRv6 capable nodes. 158 Nodes N3, N5 and N6 are classic IPv6 nodes. 160 Node N100 is a controller. 162 Node k has a classic IPv6 loopback address A:k::/128. 164 A SID at node k with locator block B and function F is represented 165 by B:k:F:: 167 The IPv6 address of the nth Link between node X and Y at the X side 168 is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address of link6 169 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 170 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 171 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 173 B:k:1:: is explicitly allocated as the END function at Node k. 175 B:k::Cij is explicitly allocated as the END.X function at node k 176 towards neighbor node i via jth Link between node i and node j. 177 e.g., B:2:C31 represents END.X at N2 towards N3 via link3 (the 1st 178 link between N2 and N3). Similarly, B:4:C52 represents the END.X at 179 N4 towards N5 via link10. 181 represents a SID list where S1 is the first SID and S3 182 is the last SID. (S3, S2, S1; SL) represents the same SID list but 183 encoded in the SRH format where the rightmost SID (S1) in the SRH is 184 the first SID and the leftmost SID (S3) in the SRH is the last SID. 186 (SA, DA) (S3, S2, S1; SL) represents an IPv6 packet, SA is the IPv6 187 Source Address, DA the IPv6 Destination Address, (S3, S2, S1; SL) is 188 the SRH header that includes the SID list . 190 3. OAM Building Blocks 192 This section defines the various building blocks for 193 implementing OAM mechanisms in SRv6 networks. 195 3.1. O-flag in Segment Routing Header 197 [I-D. draft-ietf-6man-segment-routing-header] describes the Segment 198 Routing Header (SRH) and how SR capable nodes use it. The SRH 199 contains an 8-bit "Flags" field [I-D. draft-ietf-6man-segment- 200 routing-header]. This document defines the following bit in the 201 SRH.Flags to carry the O-flag: 203 0 1 2 3 4 5 6 7 204 +-+-+-+-+-+-+-+-+ 205 | |O| | 206 +-+-+-+-+-+-+-+-+ 208 Where: 210 - O-flag: OAM flag. When set, it indicates that this packet is an 211 operations and management (OAM) packet. This document defines 212 the usage of the O-flag in the SRH.Flags. 213 - The document does not define any other flag in the SRH.Flags 214 and meaning and processing of any other bit in SRH.Flags is 215 outside of the scope of this document. 217 3.1.1. O-flag Processing 219 Implementation of the O-flag is OPTIONAL. A node MAY ignore 220 SRH.Flags.O-flag. It is also possible that a node is capable of 221 supporting the O-bit but based on a local decision it MAY ignore it 222 during processing on some local SIDs. If a node does not support the 223 O-flag, then upon reception it simply ignores it. If a node supports 224 the O-flag, it can optionally advertise its potential via node 225 capability advertisement in IGP [I-D.bashandy-isis-srv6- 226 extensions] and BGP-LS [I-D.dawra-idr-bgpls-srv6-ext]. 228 The SRH.Flags.O-flag implements the "punt a timestamped copy and 229 forward" behavior. 231 When N receives a packet whose IPv6 DA is S and S is a local SID, N 232 executes the following the pseudo-code, before the execution of the 233 local SID S. 234 1. IF SRH.Flags.O-flag is True and SRH.Flags.O-flag is locally 235 supported for S THEN 236 a. Timestamp a local copy of the packet. ;; Ref1 237 b. Punt the time-stamped copy of the packet to CPU for processing 238 in software (slow-path). ;; Ref2 239 Ref1: Timestamping is done in hardware, as soon as possible during 240 the packet processing. As timestamping is done on a copy of the 241 packet which is locally punted, timestamp value can be carried in 242 the local packet (punt) header. 243 Ref1: Hardware (microcode) just punts the packet. Software (slow path) 244 implements the required OAM 245 mechanism. Timestamp is not carried in the packet forwarded to the 246 next hop. 248 3.2. OAM Segments 250 OAM Segment IDs (SIDs) is another component of the SRv6 OAM building 251 Blocks. This document defines a 252 couple of OAM SIDs. Additional SIDs will be added in the later 253 version of the document. 255 3.2.1. End.OP: OAM Endpoint with Punt 257 Many scenarios require punting of SRv6 OAM packets at the desired 258 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 259 for short) represents a particular OAM function to implement the 260 punt behavior for an OAM packet. It is described using the 261 pseudocode as follows: 263 When N receives a packet destined to S and S is a local End.OP SID, 264 N does: 266 1. Punt the packet to CPU for SW processing (slow-path) ;; Ref1 268 Ref1: Hardware (microcode) punts the packet. Software (slow path) 269 implements the required OAM mechanisms. 271 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 272 to set the SRH.Flags.O-flag = 0. 274 3.2.2. End.OTP: OAM Endpoint with Timestamp and Punt 276 Scenarios demanding performance management of an SR policy/ path 277 requires hardware timestamping before hardware punts the packet to 278 the software for OAM processing. The "OAM Endpoint with Timestamp 279 and Punt" function (End.OTP for short) represents an OAM SID 280 function to implement the timestamp and punt behavior for an OAM 281 packet. It is described using the pseudocode as follows: 283 When N receives a packet destined to S and S is a local End.OTP SID, 284 N does: 286 1. Timestamp the packet ;; Ref1 288 2. Punt the packet to CPU for SW processing (slow-path) ;; Ref2 290 Ref1: Timestamping is done in hardware, as soon as possible 291 during the packet processing. 293 Ref2: Hardware (microcode) timestamps and punts the packet. 294 Software (slow path) implements the required OAM mechanisms. 296 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 297 to set the SRH.Flags.O-flag = 0. 299 3.3 SRH TLV 301 SRH TLV plays an important role in carrying OAM and Performance 302 Management (PM) metadata. For example, when SRH TLV piggybacks OAM 303 information onto the data traffic (i.e., for In-situ OAM (IOAM) in SRv6 304 networks). 306 4. OAM Mechanisms 308 This section describes how OAM mechanisms can be implemented using 309 the OAM building blocks described in the previous section. 310 Additional OAM mechanisms will be added in a future revision of the 311 document. 313 [RFC4443] describes Internet Control Message Protocol for IPv6 314 (ICMPv6) that is used by IPv6 devices for network diagnostic and 315 error reporting purposes. As Segment Routing with IPv6 data plane 316 (SRv6) simply adds a new type of Routing Extension Header, existing 317 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 318 describes the applicability of ICMPv6 in the SRv6 network and how 319 the existing ICMPv6 mechanisms can be used for providing OAM 320 functionality. 322 The document does not propose any changes to the standard ICMPv6 323 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 325 4.1. Ping 327 There is no hardware or software change required for ping operation 328 at the classic IPv6 nodes in an SRv6 network. That includes the 329 classic IPv6 node with ingress, egress or transit roles. 330 Furthermore, no protocol changes are required to the standard ICMPv6 331 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 332 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 334 The following subsections outline some use cases of the ICMP ping in 335 the SRv6 networks. 337 4.1.1. Classic Ping 339 The existing mechanism to ping a remote IP prefix, along the 340 shortest path, continues to work without any modification. The 341 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 342 egress or transit may be an SRv6 capable node or a classic IPv6 343 node. 345 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 346 arbitrary segment list , it needs to initiate ICMPv6 347 ping with an SR header containing the SID list . This is 348 illustrated using the topology in Figure 1. Assume all the links 349 have IGP metric 10 except both links between node2 and node3, which 350 have IGP metric set to 100. User issues a ping from node N1 to a 351 loopback of node 5, via segment list . 353 Figure 2 contains sample output for a ping request initiated at node 354 N1 to the loopback address of node N5 via a segment list . 357 > ping A:5:: via segment-list B:2:C31, B:4:C52 359 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 360 !!!!! 361 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 362 /0.749/0.931 ms 363 Figure 2 A sample ping output at an SRv6 capable node 365 All transit nodes process the echo request message like any other 366 data packet carrying SR header and hence do not require any change. 367 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 368 require any change to process the ICMPv6 echo request. For example, 369 in the ping example of Figure 2: 371 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 372 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 373 ICMPv6)(ICMPv6 Echo Request). 374 - Node N2, which is an SRv6 capable node, performs the standard 375 SRH processing. Specifically, it executes the END.X function 376 (B:2:C31) and forwards the packet on link3 to N3. 377 - Node N3, which is a classic IPv6 node, performs the standard 378 IPv6 processing. Specifically, it forwards the echo request 379 based on DA B:4:C52 in the IPv6 header. 380 - Node N4, which is an SRv6 capable node, performs the standard 381 SRH processing. Specifically, it observes the END.X function 382 (B:4:C52) with PSP (Penultimate Segment POP) on the echo 383 request packet and removes the SRH and forwards the packet 384 across link10 to N5. 385 - The echo request packet at N5 arrives as an IPv6 packet without 386 an SRH. Node N5, which is a classic IPv6 node, performs the 387 standard IPv6/ ICMPv6 processing on the echo request and 388 responds, accordingly. 390 4.1.2. Pinging a SID Function 392 The classic ping described in the previous section cannot be used to 393 ping a remote SID function, as explained using an example in the 394 following. 396 Consider the case where the user wants to ping the remote SID 397 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 398 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 399 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 400 receives the ICMPv6 echo request with DA set to B:4:C52 but the next 401 header is ICMPv6, instead of SRH. To solve this problem, the 402 initiator needs to mark the ICMPv6 echo request as an OAM packet. 404 The OAM packets are identified either by setting the O-flag in SRH 405 or by inserting the END.OP/ END.OTP SIDs at an appropriate place in 406 the SRH. The following illustration uses END.OTP SID but the 407 procedures are equally applicable to the END.OP SID. 409 In an SRv6 network, the user can exercise two flavors of the ping: 410 end-to-end ping or segment-by-segment ping, as outlined in the 411 following. 413 4.1.2.1. End-to-end ping using END.OP/ END.OTP 415 The end-to-end ping illustration uses the END.OTP SID but the 416 procedures are equally applicable to the END.OP SID. 418 Consider the same example where the user wants to ping a remote 419 SID function B:4:C52, via B:2:C31, from node N1. To force a 420 punt of the ICMPv6 echo request at the node N4, node N1 inserts 421 the END.OTP SID just before the target SID B:4:C52 in the SRH. 422 The ICMPv6 echo request is processed at the individual nodes 423 along the path as follows: 425 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 426 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 427 NH=ICMPv6)(ICMPv6 Echo Request). 428 - Node N2, which is an SRv6 capable node, performs the standard 429 SRH processing. Specifically, it executes the END.X function 430 (B:2:C31) on the echo request packet. 431 - Node N3 receives the packet as follows (A:1::, 432 B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 433 Echo Request). Node N3, which is a classic IPv6 node, performs 434 the standard IPv6 processing. Specifically, it forwards the 435 echo request based on DA B:4:OTP in the IPv6 header. 436 - When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 437 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 438 processes the END.OTP SID, as described in the pseudocode in 439 Section 3. The packet gets punted to the ICMPv6 process for 440 processing. The ICMPv6 process checks if the next SID in SRH 441 (the target SID B:4:C52) is locally programmed. 443 - If the target SID is not locally programmed, N4 responses with 444 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 445 locally implemented (TBA)"); otherwise a success is returned. 447 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 449 Consider the same example where the user wants to ping a remote SID 450 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 451 the node N1 wants to get a response from each segment node in the 452 SRH as a "proof of transit". In other words, in the segment-by-segment 453 ping case, the node N1 expects a response from node N2 and node N4 for 454 their respective local SID function. When a response to O-bit is desired 455 from the last SID in a SID-list, it is the responsibility of the ingress 456 node to use USP as the last SID. E.g., in this example, the target SID 457 B:4:C52 is a USP SID. 459 To force a punt of the ICMPv6 echo request at node N2 and node N4, 460 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 461 at the individual nodes along the path as follows: and 463 - Node N1 initiates an ICMPv6 ping packet with SRH as follows 464 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 465 NH=ICMPv6)(ICMPv6 Echo Request). 466 - When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 467 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) 468 packet, it processes the O-flag in SRH, as described in the 469 pseudocode in Section 3. A time-stamped copy of the packet gets 470 punted to the ICMPv6 process for processing. Node N2 continues 471 to apply the B:2:C31 SID function on the original packet and 472 forwards it, accordingly. As B:4:C52 is a USP SID, N2 does not 473 remove the SRH. 474 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 475 locally programmed or not and responds to the ICMPv6 Echo 476 Request. 477 - If the target SID is not locally programmed, N4 responses with 478 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 479 locally implemented (TBA)"); otherwise a success is returned. 480 Please note that, as mentioned in Section 3, if node N2 does 481 not support the O-flag, it simply ignores it and process the 482 local SID, B:2:C31. 483 - Node N3, which is a classic IPv6 node, performs the standard 484 IPv6 processing. Specifically, it forwards the echo request 485 based on DA B:4:C52 in the IPv6 header. 487 - When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 488 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 489 processes the O-flag in SRH, as described in the pseudocode in 490 Section 3. A time-stamped copy of the packet gets punted to the 491 ICMPv6 process for processing. The ICMPv6 process at node N4 492 checks if its local SID (B:2:C31) is locally programmed or not 493 and responds to the ICMPv6 Echo Request. If the target SID is 494 not locally programmed, N4 responses with the ICMPv6 message 495 (Type: "SRv6 OAM (TBA)", Code: "SID not locally implemented 496 (TBA)"); otherwise a success is returned. 498 Support for O-flag is part of node capability advertisement. That 499 enables node N1 to know which segment nodes are capable of 500 responding to the ICMPv6 echo request. Node N1 processes the echo 501 responses and presents data to the user, accordingly. 503 Please note that segment-by-segment ping can be used to address 504 proof of transit use-case. 506 4.2. Error Reporting 508 Any IPv6 node can use ICMPv6 control messages to report packet 509 processing errors to the host that originated the datagram packet. 510 To name a few such scenarios: 512 - If the router receives an undeliverable IP datagram, or 513 - If the router receives a packet with a Hop Limit of zero, or 514 - If the router receives a packet such that if the router 515 decrements the packet's Hop Limit it becomes zero, or 516 - If the router receives a packet with problem with a field in 517 the IPv6 header or the extension headers such that it cannot 518 complete processing the packet, or 519 - If the router cannot forward a packet because the packet is 520 larger than the MTU of the outgoing link. 522 In the scenarios listed above, the ICMPv6 response also contains the 523 IP header, IP extension headers and leading payload octets of the 524 "original datagram" to which the ICMPv6 message is a response. 525 Specifically, the "Destination Unreachable Message", "Time Exceeded 526 Message", "Packet Too Big Message" and "Parameter Problem Message" 527 ICMPV6 messages can contain as much of the invoking packet as 528 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 529 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 530 packet contains the SR header. The packet originator can use this 531 information for diagnostic purposes. For example, traceroute can use 532 this information as detailed in the following. 534 4.3. Traceroute 535 There is no hardware or software change required for traceroute 536 operation at the classic IPv6 nodes in an SRv6 network. That 537 includes the classic IPv6 node with ingress, egress or transit 538 roles. Furthermore, no protocol changes are required to the standard 539 traceroute operations. In other words, existing traceroute 540 mechanisms work seamlessly in the SRv6 networks. 542 The following subsections outline some use cases of the traceroute 543 in the SRv6 networks. 545 4.3.1. Classic Traceroute 547 The existing mechanism to traceroute a remote IP prefix, along the 548 shortest path, continues to work without any modification. The 549 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 550 egress or transit may be an SRv6 node or a classic IPv6 node. 552 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 553 via an arbitrary segment list , it needs to initiate 554 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 556 the links have IGP metric 10 except both links between node2 and 557 node3, which have IGP metric set to 100. User issues a traceroute 558 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 560 request. 562 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 564 Tracing the route to B5:: 566 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 567 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 569 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 570 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 572 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 573 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 575 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 577 Figure 3 A sample traceroute output at an SRv6 capable node 579 Please note that information for hop2 is returned by N3, which is a 580 classic IPv6 node. Nonetheless, the ingress node is able to display 581 SR header contents as the packet travels through the IPv6 classic 582 node. This is because the "Time Exceeded Message" ICMPv6 message can 583 contain as much of the invoking packet as possible without the 584 ICMPv6 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR 585 header is also included in these ICMPv6 messages initiated by the 586 classic IPv6 transit nodes that are not running SRv6 software. 587 Specifically, a node generating ICMPv6 message containing a copy of 588 the invoking packet does not need to understand the extension 589 header(s) in the invoking packet. 591 The segment list information returned for hop1 is returned by N2, 592 which is an SRv6 capable node. Just like for hop2, the ingress node 593 is able to display SR header contents for hop1. 595 There is no difference in processing of the traceroute probe at an 596 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 597 classic and SRv6 capable nodes may use the address of the interface on 598 which probe was received as the source address in the ICMPv6 599 response. ICMP extensions defined in [RFC5837] can be used to also 600 display information about the IP interface through which the 601 datagram would have been forwarded had it been forwardable, and the 602 IP next hop to which the datagram would have been forwarded, the IP 603 interface upon which a datagram arrived, the sub-IP component of an 604 IP interface upon which a datagram arrived. 606 The information about the IP address of the incoming interface on 607 which the traceroute probe was received by the reporting node is 608 very useful. This information can also be used to verify if SID 609 functions B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 610 respectively. Specifically, the information displayed for hop2 611 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 612 This matches with the expected interface bound to END.X function 613 B:2:C31 (link3). Similarly, the information displayed for hop5 614 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 615 This matches with the expected interface bound to the END.X function 616 B:4:C52 (link10). 618 4.3.2. Traceroute to a SID Function 620 The classic traceroute described in the previous section cannot be 621 used to traceroute a remote SID function, as explained using an 622 example in the following. 624 Consider the case where the user wants to traceroute the remote SID 625 function B:4:C52, via B:2:C31, from node N1. The trace route fails at N4. 626 This is because the node N4 trace route probe where next header is 627 UDP or ICMPv6, instead of SRH (even though the hop limit is set to 1). 628 To solve this problem, the 629 initiator needs to mark the ICMPv6 echo request as an OAM packet. 631 The OAM packets are identified either by setting the O-flag in SRH 632 or by inserting the END.OP or END.OTP SID at an appropriate place in the 633 SRH. 635 In an SRv6 network, the user can exercise two flavors of the 636 traceroute: hop-by-hop traceroute or overlay traceroute. 638 - In hop-by-hop traceroute, user gets responses from all nodes 639 including classic IPv6 transit nodes, SRv6 capable transit 640 nodes as well as SRv6 capable segment endpoints. E.g., consider 641 the example where the user wants to traceroute to a remote SID 642 function B:4:C52, via B:2:C31, from node N1. The traceroute 643 output will also display information about node3, which is a 644 transit (underlay) node. 645 - The overlay traceroute, on the other hand, does not trace the 646 underlay nodes. In other words, the overlay traceroute only 647 displays the nodes that acts as SRv6 segments along the route. 648 I.e., in the example where the user wants to traceroute to a 649 remote SID function B:4:C52, via B:2:C31, from node N1, the 650 overlay traceroute would only display the traceroute 651 information from node N2 and node N4; it will not display 652 information from node 3. 654 4.3.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 656 In this section, hop-by-hop traceroute to a SID function is 657 exemplified using UDP probes. However, the procedure is equally 658 applicable to other implementation of traceroute mechanism. 659 Furthermore, the illustration uses the END.OTP SID but the 660 procedures are equally applicable to the END.OP SID 662 Consider the same example where the user wants to traceroute to a 663 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 664 punt of the traceroute probe only at the node N4, node N1 inserts 665 the END.OTP SID just before the target SID B:4:C52 in the SRH. The 666 traceroute probe is processed at the individual nodes along the path 667 as follows. 669 - Node N1 initiates a traceroute probe packet with a 670 monotonically increasing value of hop count and SRH as follows 671 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 672 NH=UDP)(Traceroute probe). 673 - When node N2 receives the packet with hop-count = 1, it 674 processes the hop count expiry. Specifically, the node N2 675 responses with the ICMPv6 message (Type: "Time Exceeded", Code: 676 "Time to Live exceeded in Transit"). 677 - When Node N2 receives the packet with hop-count > 1, it 678 performs the standard SRH processing. Specifically, it executes 679 the END.X function (B:2:C31) on the traceroute probe. 681 - When node N3, which is a classic IPv6 node, receives the packet 682 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 683 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the 684 hop count expiry. Specifically, the node N3 responses with the 685 ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 686 exceeded in Transit"). 687 - When node N3, which is a classic IPv6 node, receives the packet 688 with hop-count > 1, it performs the standard IPv6 processing. 689 Specifically, it forwards the traceroute probe based on DA 690 B:4:OTP in the IPv6 header. 691 - When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 692 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 693 processes the END.OTP SID, as described in the pseudocode in 694 Section 3. The packet gets punted to the traceroute process for 695 processing. The traceroute process checks if the next SID in 696 SRH (the target SID B:4:C52) is locally programmed. If the 697 target SID B:4:C52 is locally programmed, node N4 responses 698 with the ICMPv6 message (Type: Destination unreachable, Code: 699 Port Unreachable). If the target SID B:4:C52 is not a local 700 SID, node N4 silently drops the traceroute probe. 702 Figure 4 displays a sample traceroute output for this example. 704 > traceroute srv6 B:4:C52 via segment-list B:2:C31 706 Tracing the route to SID function B:4:C52 708 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 709 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 711 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 712 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 714 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 715 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 717 Figure 4 A sample output for hop-by-hop traceroute to a SID 718 function 720 4.3.2.2. Tracing SRv6 Overlay 722 The overlay traceroute does not trace the underlay nodes, i.e., only 723 displays the nodes that acts as SRv6 segments along the path. This 724 is achieved by setting the SRH.Flags.O bit. 726 In this section, overlay traceroute to a SID function is exemplified 727 using UDP probes. However, the procedure is equally applicable to 728 other implementation of traceroute mechanism. 730 Consider the same example where the user wants to traceroute to a 731 remote SID function B:4:C52, via B:2:C31, from node N1. 733 - Node N1 initiates a traceroute probe with SRH as follows 734 (A:1::, B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 735 NH=UDP)(Traceroute Probe). Please note that the hop-count is 736 set to 64 to skip the underlay nodes from tracing. The O-flag 737 in SRH is set to make the overlay nodes (nodes processing the 738 SRH) respond. 739 - When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 740 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 741 processes the O-flag in SRH, as described in the pseudocode in 742 Section 3. A time-stamped copy of the packet gets punted to the 743 traceroute process for processing. Node N2 continues to apply 744 the B:2:C31 SID function on the original packet and forwards 745 it, accordingly. The traceroute 746 process at node N2 checks if its local SID (B:2:C31) is locally 747 programmed. If the SID is not locally programmed, it silently 748 drops the packet. Otherwise, it performs the egress check by 749 looking at the SL value in SRH. 750 - As SL is not equal to zero (i.e., it's not egress node), node 751 N2 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", 752 Code: "O-flag punt at Transit (TBA)"). Please note that, as 753 mentioned in Section 3, if node N2 does not support the O-flag, 754 it simply ignores it and processes the local SID, B:2:C31. 755 - When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 756 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 757 performs the standard IPv6 processing. Specifically, it 758 forwards the traceroute probe based on DA B:4:C52 in the IPv6 759 header. Please note that there is no hop-count expiration at 760 the transit nodes. 761 - When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 762 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 763 processes the O-flag in SRH, as described in the pseudocode in 764 Section 3. A time-stamped copy of the packet gets punted to the 765 traceroute process for processing. The traceroute process at 766 node N4 checks if its local SID (B:2:C31) is locally 767 programmed. If the SID is not locally programmed, it silently 768 drops the packet. Otherwise, it performs the egress check by 769 looking at the SL value in SRH. As SL is equal to zero (i.e., 770 N4 is the egress node), node N4 tries to consume the UDP probe. 771 As UDP probe is set to access an invalid port, the node N4 772 responses with the ICMPv6 message (Type: Destination 773 unreachable, Code: Port Unreachable). 775 Figure 5 displays a sample overlay traceroute output for this 776 example. Please note that the underlay node N3 does not appear in 777 the output. 779 > traceroute srv6 B:4:C52 via segment-list B:2:C31 781 Tracing the route to SID function B:4:C52 783 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 784 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 786 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 787 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 789 Figure 5 A sample output for overlay traceroute to a SID function 791 4.4 OAM Data Piggybacked in Data traffic 793 OAM data can be piggybacked in the data packet while the 794 packet traverses a path between two points in the network 795 (also known as In-situ OAM (iOAM) data). 796 This section defines how iOAM data fields are transported as part of the 797 Segment Routing with IPv6 data plane (SRv6) header. 799 4.4.1 IOAM Data Field Encapsulation in SRH 801 The SRv6 encapsulation header (SRH) is defined in 802 [I-D.6man-segment-routing-header]. IOAM data fields are carried in 803 the SRH, using a single SRH TLV. The different IOAM data fields 804 defined in [I-D.ietf-ippm-ioam-data] are added as sub-TLVs. 806 0 1 2 3 807 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | SRH-TLV-Type | LEN | RESERVED | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 811 | IOAM-Type | IOAM HDR LEN | RESERVED | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 813 ! | O 814 ! | A 815 ~ IOAM Option and Data Space ~ M 816 | | | 817 | | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 819 | | 820 | | 821 | Payload + Padding (L2/L3/...) | 822 | | 824 | | 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 1: IOAM data encapsulation in SRH 830 SRH-TLV-Type: IOAM TLV Type for SRH is defined as TBA1. 832 The fields related to the encapsulation of IOAM data fields in the 833 SRH are defined as follows: 835 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 836 Section 7.2 of [I-D.ietf-ippm-ioam-data]. 838 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 839 4-octet units. 841 RESERVED: 8-bit reserved field MUST be set to zero upon transmission 842 and ignored upon receipt. 844 IOAM Option and Data Space: IOAM option header and data is present 845 as defined by the IOAM-Type field, and is defined in Section 4 of 846 [I-D.ietf-ippm-ioam-data]. 848 The IOAM TLVs MAY change en route [I-D.ietf-ippm-ioam-data]. For the 849 IOAM TLVs carried in SRH that can change en route, the most 850 significant bit of the SRH-TLV-Type is set 851 [I-D.6man-segment-routing-header]. Furthermore, such IOAM TLV in SRH 852 is considered mutable for ICV computation, the Type Length, and 853 Variable Length Data is ignored for ICV Computation as defined in 854 [RFC4302]. 856 4.4.2. Procedure 858 This section summarizes the procedure for IOAM data encapsulation in 859 SRv6 SRH. The SR nodes implementing the IOAM functionality follows 860 the MTU and other considerations outlined in 861 [I-D.6man-extension-header-insertion]. 863 4.4.2.1 Ingress Node 865 The ingress node of an SR domain or an SR Policy 866 [I-D.spring-segment-routing-policy] may insert the IOAM TLV in the 867 SRH of the data packet. The ingress node may also insert the IOAM 868 data about the local information in the IOAM TLV in the SRH. When 869 IOAM data from the last node in the segment-list (Egress node) is 870 desired, the ingress uses an Ultimate Segment Pop (USP) SID at the 871 Egress node. 873 4.4.2.2 SR Segment Endpoint Node 875 The SR segment endpoint node is any node receiving an IPv6 packet 876 where the destination address of that packet is a local SID or a 877 local interface address. As part of the SR Header processing as 878 described in [I-D.6man-segment-routing-header] and 879 [I-D.spring-srv6-network-programming], the SR Segment Endpoint node 880 performs the following IOAM operations. The description borrows the 881 terminology used in [I-D.6man-segment-routing-header]. Specifically, 882 n refers to the number of segments encoded in the SRH, "Hdr Ext Len" 883 refers to the length of the SRH. The "SRH Header Len" is the length 884 of the SRH header, which is 8 octets 885 [I-D.6man-segment-routing-header]. 887 The SR Segment Endpoint node compares the "Hdr Ext Len" of the SRH 888 with the length of the "segment-list" in the SRH. Specifically, if 889 the SRH.Hdr_Ext_Len > n*16 + 8, the node looks for the presence of 890 the IOAM TLV in the SRH. If an IOAM TLV is present in the SRH and is 891 supported by the Segment Endpoint Node, the SR segment endpoint node 892 MAY modify the IOAM TLV in SRH with local IOAM data as per IOAM draft 893 [I-D.ietf-ippm-ioam-data]. 895 4.4.2.3 Egress Node 897 The Egress node is the last node in the segment-list of the SRH. When 898 IOAM data from the Egress node is desired, a USP SID advertised by 899 the Egress node is used. 901 The processing of IOAM TLV at the Egress node is similar to the 902 processing of IOAM TLV at the SR Segment Endpoint Node. The only 903 difference is that the Egress node also performs the functionality 904 required by the Egress node in an IOAM domain. E.g., the Egress node 905 may telemeter the IOAM data to a controller. 907 4.6. Monitoring of SRv6 Paths 909 In the recent past, network operators are interested in performing 910 network OAM functions in a centralized manner. Various data models 911 like YANG are available to collect data from the network and manage 912 it from a centralized entity. 914 SR technology enables a centralized OAM entity to perform path 915 monitoring from centralized OAM entity without control plane 916 intervention on monitored nodes. [I.D-draft-ietf-spring-oam-usecase] 917 describes such a centralized OAM mechanism. Specifically, the draft 918 describes a procedure that can be used to perform path continuity 919 check between any nodes within an SR domain from a centralized 920 monitoring system, with minimal or no control plane intervene on the 921 nodes. However, the draft focuses on SR networks with MPLS data 922 plane. The same concept applies to the SRv6 networks. This document 923 describes how the concept can be used to perform path monitoring in 924 an SRv6 network. This document describes how the concept can be used 925 to perform path monitoring in an SRv6 network as follows. 927 In the above reference topology, N100 is the centralized monitoring 928 system implementing an END function B:100:1::. In order to verify a 929 segment list , N100 generates a probe packet with 930 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller routes 931 the probe packet towards the first segment, which is B:2:C31. N2 932 performs the standard SRH processing and forward it over link3 with 933 the DA of IPv6 packet set to B:4:C52. N4 also performs the normal 934 SRH processing and forward it over link10 with the DA of IPv6 packet 935 set to B:100:1::. This makes the probe loops back to the centralized 936 monitoring system. 938 In the reference topology in Figure 1, N100 uses an IGP protocol 939 like OSPF or ISIS to get the topology view within the IGP domain. 940 N100 can also use BGP-LS to get the complete view of an inter-domain 941 topology. In other words, the controller leverages the visibility of 942 the topology to monitor the paths between the various endpoints 943 without control plane intervention required at the monitored nodes. 945 5. Security Considerations 947 This document does not define any new protocol extensions and relies 948 on existing procedures defined for ICMP. This document does not 949 impose any additional security challenges to be considered beyond 950 security considerations described in [RFC4884], [RFC4443], [RFC792] 951 and RFCs that updates these RFCs. 953 6. IANA Considerations 955 6.1. ICMPv6 type Numbers Registry 957 This document defines one ICMPv6 Message, a type that has been 958 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 959 Specifically, it requests to add the following to the "ICMPv6 Type 960 Numbers" registry: 962 TBA (suggested value: 162) SRv6 OAM Message. 964 The document also requests the creation of a new IANA registry to 965 the 967 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 968 OAM Message" with the following codes: 970 Code Name Reference 971 ------------------------------------------------------- 972 0 No Error This document 973 1 SID is not locally implemented This document 974 2 O-flag punt at Transit This document 976 6.2. SRv6 OAM Endpoint Types 978 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 979 Behaviors Registry" sub-registry belonging to the top-level 980 "Segment-routing with 981 IPv6 dataplane (SRv6) Parameters" registry [I-D.filsfils-spring- 982 srv6-network-programming], the following allocations: 984 +-------------+-----+-------------------+-----------+ 985 | Value (Suggested | Endpoint Behavior | Reference | 986 | Value) | | | 987 +------------------+-------------------+-----------+ 988 | TBA (40) | End.OP | [This.ID] | 989 | TBA (41) | End.OTP | [This.ID] | 990 +------------------+-------------------+-----------+ 992 6.3. SRv6 IOAM TLV 994 IANA is requested to allocate SRH TLV Type for IOAM TLV data fields 995 under registry name "Segment Routing Header TLVs" requested by [I- 996 D.6man-segment-routing-header]. 998 +--------------+--------------------------+---------------+ 1000 | SRH TLV Type | Description | Reference | 1001 +--------------+--------------------------+---------------+ 1002 | TBA1 | TLV for IOAM Data Fields | This document | 1003 +--------------+--------------------------+---------------+ 1005 7. References 1007 7.1. Normative References 1009 [RFC792] J. Postel, "Internet Control Message Protocol", RFC 792, 1010 September 1981. 1012 [RFC4443] A. Conta, S. Deering, M. Gupta, Ed., "Internet Control 1013 Message Protocol (ICMPv6) for the Internet Protocol 1014 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1016 [RFC4884] R. Bonica, D. Gan, D. Tappan, C. Pignataro, "Extended ICMP 1017 to Support Multi-Part Messages", RFC 4884, April 2007. 1019 [RFC5837] A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, 1020 JR. Rivers, "Extending ICMP for Interface and Next-Hop 1021 Identification", RFC 5837, April 2010. 1023 [I-D.filsfils-spring-srv6-network-programming] C. Filsfils, et al., 1024 "SRv6 Network Programming", 1025 draft-filsfils-spring-srv6-network-programming, work in 1026 progress. 1028 [I-D.6man-segment-routing-header] Previdi, S., Filsfils, et al, 1029 "IPv6 Segment Routing Header (SRH)", 1030 draft-ietf-6man-segment-routing-header, work in progress. 1032 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, 1033 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 1034 Mozes, D., Lapukhov, P., Chang, R., and Bernier, D., "Data 1035 Fields for In-situ OAM", draft-ietf-ippm-ioam-data, work 1036 in progress. 1038 7.2. Informative References 1040 [I-D.bashandy-isis-srv6-extensions] IS-IS Extensions to Support Routing 1041 over IPv6 Dataplane. L. Ginsberg, P. Psenak, C. Filsfils, 1042 A. Bashandy, B. Decraene, Z. Hu, 1043 draft-bashandy-isis-srv6-extensions, work in progress. 1045 [I-D.dawra-idr-bgpls-srv6-ext] G. Dawra, C. Filsfils, K. Talaulikar, 1046 et al., BGP Link State extensions for IPv6 Segment Routing 1047 (SRv6), draft-dawra-idr-bgpls-srv6-ext, work in progress. 1049 [I-D.ietf-spring-oam-usecase] A Scalable and Topology-Aware MPLS 1050 Dataplane Monitoring System. R. Geib, C. Filsfils, C. 1051 Pignataro, N. Kumar, draft-ietf-spring-oam-usecase, work 1052 in progress. 1054 [I-D.brockners-inband-oam-data] F. Brockners, et al., "Data Formats 1055 for In-situ OAM", draft-brockners-inband-oam-data, work in 1056 progress. 1058 [I-D.brockners-inband-oam-transport] F.Brockners, at al., 1059 "Encapsulations for In-situ OAM Data", 1060 draft-brockners-inband-oam-transport, work in progress. 1062 [I-D.brockners-inband-oam-requirements] F.Brockners, et al., 1063 "Requirements for In-situ OAM", 1064 draft-brockners-inband-oam-requirements, work in progress. 1066 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 1067 Routing Policy for Traffic Engineering", 1068 draft-filsfils-spring-segment-routing-policy, work in 1069 progress. 1071 8. Acknowledgments 1073 To be added. 1075 Authors' Addresses 1077 Clarence Filsfils 1078 Cisco Systems, Inc. 1079 Email: cfilsfil@cisco.com 1081 Zafar Ali 1082 Cisco Systems, Inc. 1083 Email: zali@cisco.com 1085 Nagendra Kumar 1086 Cisco Systems, Inc. 1087 Email: naikumar@cisco.com 1088 Carlos Pignataro 1089 Cisco Systems, Inc. 1090 Email: cpignata@cisco.com 1092 Rakesh Gandhi 1093 Cisco Systems, Inc. 1094 Canada 1095 Email: rgandhi@cisco.com 1097 Frank Brockners 1098 Cisco Systems, Inc. 1099 Germany 1100 Email: fbrockne@cisco.com 1102 John Leddy 1103 Comcast 1104 Email: John_Leddy@cable.comcast.com 1106 Robert Raszuk 1107 Bloomberg LP 1108 731 Lexington Ave 1109 New York City, NY10022, USA 1110 Email: robert@raszuk.net 1112 Satoru Matsushima 1113 SoftBank 1114 Japan 1115 Email: satoru.matsushima@g.softbank.co.jp 1117 Daniel Voyer 1118 Bell Canada 1119 Email: daniel.voyer@bell.ca 1121 Gaurav Dawra 1122 LinkedIn 1123 Email: gdawra.ietf@gmail.com 1125 Bart Peirens 1126 Proximus 1127 Email: bart.peirens@proximus.com 1128 Mach Chen 1129 Huawei 1130 Email: mach.chen@huawei.com 1132 Cheng Li 1133 Huawei 1134 Email: chengli13@huawei.com 1136 Faisal Iqbal 1137 Individual 1138 Email: faisal.ietf@gmail.com 1140 Gaurav Naik 1141 Drexel University 1142 United States of America 1143 Email: gn@drexel.edu