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