idnits 2.17.1 draft-ietf-6man-spring-srv6-oam-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2022) is 824 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) == Unused Reference: 'I-D.ietf-ippm-ioam-data' is defined on line 460, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems 5 Expires: July 27, 2022 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 January 23, 2022 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ietf-6man-spring-srv6-oam-13 17 Abstract 19 This document describes how the existing IPv6 mechanisms for ping and 20 traceroute can be used in an SRv6 network. The document also 21 specifies the OAM flag in the Segment Routing Header (SRH) for 22 performing controllable and predictable flow sampling from segment 23 endpoints. In addition, the document describes how a centralized 24 monitoring system performs a path continuity check between any nodes 25 within an SRv6 domain. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 27, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Terminology and Reference Topology . . . . . . . . . . . 4 65 2. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 67 2.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 68 2.2. OAM Operations . . . . . . . . . . . . . . . . . . . . . 8 69 3. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . 12 77 A.1. Ping in SRv6 Networks . . . . . . . . . . . . . . . . . . 12 78 A.1.1. Pinging an IPv6 Address via a Segment-list . . . . . 13 79 A.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 14 80 A.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 15 81 A.2.1. Traceroute to an IPv6 Address via a Segment-list . . 15 82 A.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 17 83 A.3. A Hybrid OAM Using O-flag . . . . . . . . . . . . . . . . 18 84 A.4. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 21 85 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 86 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 As Segment Routing with IPv6 data plane (SRv6) [RFC8402] simply adds 92 a new type of Routing Extension Header, existing IPv6 OAM mechanisms 93 can be used in an SRv6 network. This document describes how the 94 existing IPv6 mechanisms for ping and traceroute can be used in an 95 SRv6 network. This includes illustrations of pinging an SRv6 SID to 96 verify that the SID is reachable and is locally programmed at the 97 target node. This also includes illustrations for tracerouting to an 98 SRv6 SID for hop-by-hop fault localization as well as path tracing to 99 a SID. 101 The document also introduces enhancements for the OAM mechanism for 102 SRv6 networks for performing controllable and predictable flow 103 sampling from segment endpoints using, e.g., IP Flow Information 104 Export (IPFIX) protocol [RFC7011]. Specifically, the document 105 specifies the O-flag in SRH as a marking-bit in the user packets to 106 trigger the telemetry data collection and export at the segment 107 endpoints. 109 The document also outlines how the centralized OAM technique in 110 [RFC8403] can be extended for SRv6 to perform a path continuity check 111 between any nodes within an SRv6 domain. Specifically, the document 112 illustrates how a centralized monitoring system can monitor arbitrary 113 SRv6 paths by creating the loopback probes that originate and 114 terminate at the centralized monitoring system. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 1.2. Abbreviations 126 The following abbreviations are used in this document: 128 SID: Segment ID. 130 SL: Segments Left. 132 SR: Segment Routing. 134 SRH: Segment Routing Header [RFC8754]. 136 SRv6: Segment Routing with IPv6 Data plane. 138 PSP: Penultimate Segment Pop of the SRH [RFC8986]. 140 USP: Ultimate Segment Pop of the SRH [RFC8986]. 142 ICMPv6: ICMPv6 Specification [RFC4443]. 144 IS-IS: Intermediate System to Intermediate System 145 OSPF: Open Shortest Path First protocol [RFC2328] 147 IGP: Interior Gateway Protocols (e.g., OSPF, IS-IS). 149 BGP-LS: Border Gateway Protocol - Link State Extensions [RFC8571] 151 1.3. Terminology and Reference Topology 153 Throughout the document, the following terminology and simple 154 topology is used for illustration. 156 +--------------------------| N100 |---------------------------------+ 157 | | 158 | ====== link1====== link3------ link5====== link9------ ====== | 159 ||N1||------||N2||------| N3 |------||N4||------| N5 |---||N7|| 160 || ||------|| ||------| |------|| ||------| |---|| || 161 ====== link2====== link4------ link6======link10------ ====== 162 | | | | 163 ---+-- | ------ | --+--- 164 |CE 1| +-------| N6 |---------+ |CE 2| 165 ------ link7 | | link8 ------ 166 ------ 168 Figure 1 Reference Topology 170 In the reference topology: 172 Node j has a IPv6 loopback address 2001:db8:L:j::/128. 174 Nodes N1, N2, N4 and N7 are SRv6-capable nodes. 176 Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6-capable. 177 Such nodes are referred as non-SRv6 capable nodes. 179 CE1 and CE2 are Customer Edge devices of any data plane capability 180 (e.g., IPv4, IPv6, L2, etc.). 182 A SID at node j with locator block 2001:db8:K::/48 and function U 183 is represented by 2001:db8:K:j:U::. 185 Node N100 is a controller. 187 The IPv6 address of the nth Link between node i and j at the i 188 side is represented as 2001:db8:i:j:in::, e.g., the IPv6 address 189 of link6 (the 2nd link between N3 and N4) at N3 in Figure 1 is 190 2001:db8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 191 link between N3 and N4) at node N3 is 2001:db8:3:4:31::. 193 2001:db8:K:j:Xin:: is explicitly allocated as the End.X SID at 194 node j towards neighbor node i via nth Link between node i and 195 node j. e.g., 2001:db8:K:2:X31:: represents End.X at N2 towards 196 N3 via link3 (the 1st link between N2 and N3). Similarly, 197 2001:db8:K:4:X52:: represents the End.X at N4 towards N5 via 198 link10 (the 2nd link between N4 and N5). Please refer to 199 [RFC8986] for description of End.X SID. 201 A SID list is represented as where S1 is the first 202 SID to visit, S2 is the second SID to visit and S3 is the last SID 203 to visit along the SR path. 205 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 207 * IPv6 header with source address SA, destination addresses DA 208 and SRH as next-header 210 * SRH with SID list with SegmentsLeft = SL 212 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 214 the last SID to traverse. (S3, S2, S1; SL) represents the same 215 SID list but encoded in the SRH format where the rightmost SID 216 in the SRH is the first SID and the leftmost SID in the SRH is 217 the last SID. When referring to an SR policy in a high-level 218 use-case, it is simpler to use the notation. When 219 referring to an illustration of the detailed packet behavior, 220 the (S3, S2, S1; SL) notation is more convenient. 222 * (payload) represents the the payload of the packet. 224 2. OAM Mechanisms 226 This section defines OAM enhancement for the SRv6 networks. 228 2.1. O-flag in Segment Routing Header 230 [RFC8754] describes the Segment Routing Header (SRH) and how SR 231 capable nodes use it. The SRH contains an 8-bit "Flags" field. 233 This document defines the following bit in the SRH Flags field to 234 carry the O-flag: 236 0 1 2 3 4 5 6 7 237 +-+-+-+-+-+-+-+-+ 238 | |O| | 239 +-+-+-+-+-+-+-+-+ 241 Where: 243 O-flag: OAM flag in the SRH Flags field defined in [RFC8754]. 245 2.1.1. O-flag Processing 247 The O-flag in SRH is used as a marking-bit in the user packets to 248 trigger the telemetry data collection and export at the segment 249 endpoints. 251 An SR domain ingress edge node encapsulates packets traversing the SR 252 domain as defined in [RFC8754]. The SR domain ingress edge node MAY 253 use the O-flag in SRH for marking the packet to trigger the telemetry 254 data collection and export at the segment endpoints. Based on a 255 local configuration, the SR domain ingress edge node may implement a 256 classification and sampling mechanism to mark a packet with the 257 O-flag in SRH. Specification of the classification and sampling 258 method is outside the scope of this document. 260 This document does not specify the data elements that need to be 261 exported and the associated configurations. Similarly, this document 262 does not define any formats for exporting the data elements. 263 Nonetheless, without the loss of generality, this document assumes IP 264 Flow Information Export (IPFIX) protocol [RFC7011] is used for 265 exporting the traffic flow information from the network devices to a 266 controller for monitoring and analytics. Similarly, without the loss 267 of generality, this document assumes requested information elements 268 are configured by the management plane through data set templates 269 (e.g., as in IPFIX [RFC7012]). 271 Implementation of the O-flag is OPTIONAL. If a node does not support 272 the O-flag, then upon reception it simply ignores it. If a node 273 supports the O-flag, it can optionally advertise its potential via 274 control plane protocol(s). 276 When N receives a packet destined to S and S is a local SID, the line 277 S01 of the pseudo-code associated with the SID S, as defined in 278 section 4.3.1.1 of [RFC8754], is appended to as follows for the 279 O-flag processing. 281 S01.1. IF O-flag is set and local configuration permits 282 O-flag processing { 283 a. Make a copy of the packet. 284 b. Send the copied packet, along with a timestamp 285 to the OAM process for telemetry data collection 286 and export. ;; Ref1 287 } 288 Ref1: To provide an accurate timestamp, an implementation should copy 289 and record the timestamp as soon as possible during packet processing. 290 Timestamp and any other metadata is not carried in the packet forwarded to the next hop. 292 Please note that the O-flag processing happens before execution of 293 regular processing of the local SID S. Specifically, the line S01.1 294 of the pseudo-code specified in this document is inserted between 295 line S01 and S02 of the pseudo-code defined in section 4.3.1.1 of 296 [RFC8754]. 298 Based on the requested information elements configured by the 299 management plane through data set templates [RFC7012], the OAM 300 process exports the requested information elements. The information 301 elements include parts of the packet header and/or parts of the 302 packet payload for flow identification. The OAM process uses 303 information elements defined in IPFIX [RFC7011] and PSAMP [RFC5476] 304 for exporting the requested sections of the mirrored packets. 306 If the penultimate segment of a segment-list is a Penultimate Segment 307 Pop (PSP) SID, telemetry data from the ultimate segment cannot be 308 requested. This is because, when the penultimate segment is a PSP 309 SID, the SRH is removed at the penultimate segment and the O-flag is 310 not processed at the ultimate segment. 312 The processing node MUST rate-limit the number of packets punted to 313 the OAM process to a configurable rate. This is to avoid hitting any 314 performance impact on the OAM and the telemetry collection processes. 315 Failure in implementing the rate limit can lead to a denial-of- 316 service attack, as detailed in section 4. 318 The OAM process MUST NOT process the copy of the packet or respond to 319 any upper-layer header (like ICMP, UDP, etc.) payload to prevent 320 multiple evaluations of the datagram. 322 The OAM process is expected to be located on the routing node 323 processing the packet. Although the specification of the OAM process 324 or the external controller operations are beyond the scope of this 325 document, the OAM process SHOULD NOT be topologically distant from 326 the routing node, as this is likely to create significant security 327 and congestion issues. How to correlate the data collected from 328 different nodes at an external controller is also outside the scope 329 of the document. Appendix A illustrates use of the O-flag for 330 implementing a hybrid OAM mechanism, where the "hybrid" 331 classification is based on RFC7799 [RFC7799]. 333 2.2. OAM Operations 335 IPv6 OAM operations can be performed for any SRv6 SID whose behavior 336 allows Upper Layer Header processing for an applicable OAM payload 337 (e.g., ICMP, UDP). 339 Ping to an SRv6 SID is used to verify that the SID is reachable and 340 is locally programmed at the target node. Traceroute to a SID is 341 used for hop-by-hop fault localization as well as path tracing to a 342 SID. Appendix A illustrates the ICMPv6 based ping and the UDP based 343 traceroute mechanisms for ping and traceroute to an SRv6 SID. 344 Although this document only illustrates ICMPv6 ping and UDP based 345 traceroute to an SRv6 SID, the procedures are equally applicable to 346 other IPv6 OAM probing to an SRv6 SID (e.g., Bidirectional Forwarding 347 Detection (BFD) [RFC5880], Seamless BFD (SBFD) [RFC7880], STAMP probe 348 message processing [I-D.gandhi-spring-stamp-srpm], etc.). 349 Specifically, as long as local configuration allows the Upper-layer 350 Header processing of the applicable OAM payload for SRv6 SIDs, the 351 existing IPv6 OAM techniques can be used to target a probe to a 352 (remote) SID. 354 IPv6 OAM operations can be performed with the target SID in the IPv6 355 destination address without SRH or with SRH where the target SID is 356 the last segment. In general, OAM operations to a target SID may not 357 exercise all of its processing depending on its behavior definition. 358 For example, ping to an End.X SID [RFC8986] only validates the SID is 359 locally programmed at the target node and does not validate switching 360 to the correct outgoing interface. To exercise the behavior of a 361 target SID, the OAM operation should construct the probe in a manner 362 similar to a data packet that exercises the SID behavior, i.e. to 363 include that SID as a transit SID in either an SRH or IPv6 DA of an 364 outer IPv6 header or as appropriate based on the definition of the 365 SID behavior. 367 3. Implementation Status 369 This section is to be removed prior to publishing as an RFC. 371 See [I-D.matsushima-spring-srv6-deployment-status] for updated 372 deployment and interoperability reports. 374 4. Security Considerations 376 [RFC8754] defines the notion of an SR domain and use of SRH within 377 the SR domain. The use of OAM procedures described in this document 378 is restricted to an SR domain. For example, similar to the SID 379 manipulation, O-flag manipulation is not considered as a threat 380 within the SR domain. Procedures for securing an SR domain are 381 defined the section 5.1 and section 7 of [RFC8754]. 383 As noted in section 7.1 of [RFC8754], compromised nodes within the SR 384 domain may mount attacks. The O-flag may be set by an attacking node 385 attempting a denial-of-service attack on the OAM process at the 386 segment endpoint node. An implementation correctly implementing the 387 rate limiting in section 2.1.1 is not susceptible to that denial-of- 388 service attack. Additionally, SRH Flags are protected by the HMAC 389 TLV, as described in section 2.1.2.1 of [RFC8754]. Once an HMAC is 390 generated for a segment list with the O-flag set, it can be used for 391 an arbitrary amount of traffic using that segment list with O-flag 392 set. 394 The security properties of the channel used to send exported packets 395 marked by the O-flag will depend on the specific OAM processes used. 396 An on-path attacker able to observe this OAM channel could conduct 397 traffic analysis, or potentially eavesdropping (depending on the OAM 398 configuration), of this telemetry for the entire SR domain from such 399 a vantage point. 401 This document does not impose any additional security challenges to 402 be considered beyond security threats described in [RFC4884], 403 [RFC4443], [RFC0792], [RFC8754] and [RFC8986]. 405 5. Privacy Considerations 407 The per-packet marking capabilities of the O-flag provides a granular 408 mechanism to collect telemetry. When this collection is deployed by 409 an operator with knowledge and consent of the users, it will enable a 410 variety of diagnostics and monitoring to support the OAM and security 411 operations use cases needed for resilient network operations. 412 However, this collection mechanism will also provide an explicit 413 protocol mechanism to operators for surveillance and pervasive 414 monitoring use cases done contrary to the user's consent. 416 6. IANA Considerations 418 This document requests that IANA allocate the following registration 419 in the "Segment Routing Header Flags" sub-registry for the "Internet 420 Protocol Version 6 (IPv6) Parameters" registry maintained by IANA: 422 +-------+------------------------------+---------------+ 423 | Bit | Description | Reference | 424 +=======+==============================+===============+ 425 | 2 | O-flag | This document | 426 +-------+------------------------------+---------------+ 428 7. References 430 7.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 438 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 439 May 2017, . 441 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 442 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 443 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 444 . 446 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 447 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 448 (SRv6) Network Programming", RFC 8986, 449 DOI 10.17487/RFC8986, February 2021, 450 . 452 7.2. Informative References 454 [I-D.gandhi-spring-stamp-srpm] 455 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 456 B., and R. Foote, "Performance Measurement Using Simple 457 TWAMP (STAMP) for Segment Routing Networks", draft-gandhi- 458 spring-stamp-srpm-07 (work in progress), July 2021. 460 [I-D.ietf-ippm-ioam-data] 461 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 462 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 463 progress), November 2020. 465 [I-D.matsushima-spring-srv6-deployment-status] 466 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 467 Rajaraman, "SRv6 Implementation and Deployment Status", 468 draft-matsushima-spring-srv6-deployment-status-11 (work in 469 progress), February 2021. 471 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 472 RFC 792, DOI 10.17487/RFC0792, September 1981, 473 . 475 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 476 DOI 10.17487/RFC2328, April 1998, 477 . 479 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 480 Control Message Protocol (ICMPv6) for the Internet 481 Protocol Version 6 (IPv6) Specification", STD 89, 482 RFC 4443, DOI 10.17487/RFC4443, March 2006, 483 . 485 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 486 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 487 DOI 10.17487/RFC4884, April 2007, 488 . 490 [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet 491 Sampling (PSAMP) Protocol Specifications", RFC 5476, 492 DOI 10.17487/RFC5476, March 2009, 493 . 495 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 496 N., and JR. Rivers, "Extending ICMP for Interface and 497 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 498 April 2010, . 500 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 501 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 502 . 504 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 505 "Specification of the IP Flow Information Export (IPFIX) 506 Protocol for the Exchange of Flow Information", STD 77, 507 RFC 7011, DOI 10.17487/RFC7011, September 2013, 508 . 510 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 511 for IP Flow Information Export (IPFIX)", RFC 7012, 512 DOI 10.17487/RFC7012, September 2013, 513 . 515 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 516 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 517 May 2016, . 519 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 520 Pallagatti, "Seamless Bidirectional Forwarding Detection 521 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 522 . 524 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 525 Decraene, B., Litkowski, S., and R. Shakir, "Segment 526 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 527 July 2018, . 529 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 530 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 531 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 532 2018, . 534 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 535 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 536 IGP Traffic Engineering Performance Metric Extensions", 537 RFC 8571, DOI 10.17487/RFC8571, March 2019, 538 . 540 Appendix A. Illustrations 542 This appendix shows how some of the existing IPv6 OAM mechanisms can 543 be used in an SRv6 network. It also illustrates an OAM mechanism for 544 performing controllable and predictable flow sampling from segment 545 endpoints. How centralized OAM technique in [RFC8403] can be 546 extended for SRv6 is also described in this appendix. 548 A.1. Ping in SRv6 Networks 550 The existing mechanism to perform the reachability checks, along the 551 shortest path, continues to work without any modification. Any IPv6 552 node (SRv6 capable or a non-SRv6 capable) can initiate, transit, and 553 egress a ping packet. 555 The following subsections outline some additional use cases of the 556 ICMPv6 ping in the SRv6 networks. 558 A.1.1. Pinging an IPv6 Address via a Segment-list 560 If an SRv6-capable ingress node wants to ping an IPv6 address via an 561 arbitrary segment list , it needs to initiate an ICMPv6 562 ping with an SR header containing the SID list . This is 563 illustrated using the topology in Figure 1. User issues a ping from 564 node N1 to a loopback of node N5, via segment list 565 <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID behavior used in 566 the example is End.X SID, as described in [RFC8986], but the 567 procedure is equally applicable to any other (transit) SID type. 569 Figure 2 contains sample output for a ping request initiated at node 570 N1 to a loopback address of node N5 via a segment list 571 <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. 573 > ping 2001:db8:L:5:: via segment-list 2001:db8:K:2:X31::, 574 2001:db8:K:4:X52:: 576 Sending 5, 100-byte ICMPv6 Echos to B5::, timeout is 2 seconds: 577 !!!!! 578 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 579 /0.749/0.931 ms 581 Figure 2 A sample ping output at an SRv6-capable node 583 All transit nodes process the echo request message like any other 584 data packet carrying SR header and hence do not require any change. 585 Similarly, the egress node does not require any change to process the 586 ICMPv6 echo request. For example, in the ping example of Figure 2: 588 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 589 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:L:5::, 590 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2, NH = ICMPv6)(ICMPv6 591 Echo Request). 593 o Node N2, which is an SRv6-capable node, performs the standard SRH 594 processing. Specifically, it executes the End.X behavior 595 indicated by the 2001:db8:K:2:X31:: SID and forwards the packet on 596 link3 to N3. 598 o Node N3, which is a non-SRv6 capable node, performs the standard 599 IPv6 processing. Specifically, it forwards the echo request based 600 on the DA 2001:db8:K:4:X52:: in the IPv6 header. 602 o Node N4, which is an SRv6-capable node, performs the standard SRH 603 processing. Specifically, it observes the End.X behavior 604 (2001:db8:K:4:X52::) and forwards the packet on link10 towards N5. 605 If 2001:db8:K:4:X52:: is a PSP SID, the penultimate node (Node N4) 606 does not, should not and cannot differentiate between the data 607 packets and OAM probes. Specifically, if 2001:db8:K:4:X52:: is a 608 PSP SID, node N4 executes the SID like any other data packet with 609 DA = 2001:db8:K:4:X52:: and removes the SRH. 611 o The echo request packet at N5 arrives as an IPv6 packet with or 612 without an SRH. If N5 receives the packet with SRH, it skips SRH 613 processing (SL=0). In either case, Node N5 performs the standard 614 ICMPv6 processing on the echo request and responds with the echo 615 reply message to N1. The echo reply message is IP routed. 617 A.1.2. Pinging a SID 619 The ping mechanism described above applies equally to perform SID 620 reachability check and to validate the SID is locally programmed at 621 the target node. This is explained using an example in the 622 following. The example uses ping to an END SID, as described in 623 [RFC8986], but the procedure is equally applicable to ping any other 624 SID behaviors. 626 Consider the example where the user wants to ping a remote SID 627 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The ICMPv6 628 echo request is processed at the individual nodes along the path as 629 follows: 631 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 632 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 633 2001:db8:K:2:X31::; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). 635 o Node N2, which is an SRv6-capable node, performs the standard SRH 636 processing. Specifically, it executes the End.X behavior 637 indicated by the 2001:db8:K:2:X31:: SID on the echo request 638 packet. If 2001:db8:K:2:X31:: is a PSP SID, node N4 executes the 639 SID like any other data packet with DA = 2001:db8:K:2:X31:: and 640 removes the SRH. 642 o Node N3, which is a non-SRv6 capable node, performs the standard 643 IPv6 processing. Specifically, it forwards the echo request based 644 on DA = 2001:db8:K:4:: in the IPv6 header. 646 o When node N4 receives the packet, it processes the target SID 647 (2001:db8:K:4::). 649 o If the target SID (2001:db8:K:4::) is not locally instantiated and 650 does not represent a local interface, the packet is discarded 652 o If the target SID (2001:db8:K:4::) is locally instantiated or 653 represents a local interface, the node processes the upper layer 654 header. As part of the upper layer header processing node N4 655 respond to the ICMPv6 echo request message and responds with the 656 echo reply message. The echo reply message is IP routed. 658 A.2. Traceroute 660 The existing traceroute mechanisms, along the shortest path, 661 continues to work without any modification. Any IPv6 node (SRv6 662 capable or a non-SRv6 capable) can initiate, transit, and egress a 663 traceroute probe. 665 The following subsections outline some additional use cases of the 666 traceroute in the SRv6 networks. 668 A.2.1. Traceroute to an IPv6 Address via a Segment-list 670 If an SRv6-capable ingress node wants to traceroute to IPv6 address 671 via an arbitrary segment list , it needs to initiate a 672 traceroute probe with an SR header containing the SID list . User issues a traceroute from node N1 to a loopback of node N5, 674 via segment list <2001:db8:K:2:X31::, 2001:db8:K:4:X52::>. The SID 675 behavior used in the example is End.X SID, as described in [RFC8986], 676 but the procedure is equally applicable to any other (transit) SID 677 type. Figure 3 contains sample output for the traceroute request. 679 > traceroute 2001:db8:L:5:: via segment-list 2001:db8:K:2:X31::, 680 2001:db8:K:4:X52:: 682 Tracing the route to 2001:db8:L:5:: 683 1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec 684 DA: 2001:db8:K:2:X31::, 685 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=2) 686 2 2001:db8:3:2:31:: 0.721 msec 0.810 msec 0.795 msec 687 DA: 2001:db8:K:4:X52::, 688 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 689 3 2001:db8:4:3::41:: 0.921 msec 0.816 msec 0.759 msec 690 DA: 2001:db8:K:4:X52::, 691 SRH:(2001:db8:L:5::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::, SL=1) 692 4 2001:db8:5:4::52:: 0.879 msec 0.916 msec 1.024 msec 693 DA: 2001:db8:L:5:: 695 Figure 3 A sample traceroute output at an SRv6-capable node 697 In the sample traceroute output, the information displayed at each 698 hop is obtained using the contents of the "Time Exceeded" or 699 "Destination Unreachable" ICMPv6 responses. These ICMPv6 responses 700 are IP routed. 702 In the sample traceroute output, the information for link3 is 703 returned by N3, which is a non-SRv6 capable node. Nonetheless, the 704 ingress node is able to display SR header contents as the packet 705 travels through the non-SRv6 capable node. This is because the "Time 706 Exceeded Message" ICMPv6 message can contain as much of the invoking 707 packet as possible without the ICMPv6 packet exceeding the minimum 708 IPv6 MTU [RFC4443]. The SR header is included in these ICMPv6 709 messages initiated by the non-SRv6 capable transit nodes that are not 710 running SRv6 software. Specifically, a node generating ICMPv6 711 message containing a copy of the invoking packet does not need to 712 understand the extension header(s) in the invoking packet. 714 The segment list information returned for the first hop is returned 715 by N2, which is an SRv6-capable node. Just like for the second hop, 716 the ingress node is able to display SR header contents for the first 717 hop. 719 There is no difference in processing of the traceroute probe at an 720 SRv6-capable and a non-SRv6 capable node. Similarly, both 721 SRv6-capable and non-SRv6 capable nodes may use the address of the 722 interface on which probe was received as the source address in the 723 ICMPv6 response. ICMPv6 extensions defined in [RFC5837] can be used 724 to display information about the IP interface through which the 725 datagram would have been forwarded had it been forwardable, and the 726 IP next hop to which the datagram would have been forwarded, the IP 727 interface upon which a datagram arrived, the sub-IP component of an 728 IP interface upon which a datagram arrived. 730 The IP address of the interface on which the traceroute probe was 731 received is useful. This information can also be used to verify if 732 SIDs 2001:db8:K:2:X31:: and 2001:db8:K:4:X52:: are executed correctly 733 by N2 and N4, respectively. Specifically, the information displayed 734 for the second hop contains the incoming interface address 735 2001:db8:2:3:31:: at N3. This matches with the expected interface 736 bound to End.X behavior 2001:db8:K:2:X31:: (link3). Similarly, the 737 information displayed for the fourth hop contains the incoming 738 interface address 2001:db8:4:5::52:: at N5. This matches with the 739 expected interface bound to the End.X behavior 2001:db8:K:4:X52:: 740 (link10). 742 A.2.2. Traceroute to a SID 744 The mechanism to traceroute an IPv6 Address via a Segment-list 745 described in the previous section applies equally to traceroute a 746 remote SID behavior, as explained using an example in the following. 747 The example uses traceroute to an END SID, as described in [RFC8986], 748 but the procedure is equally applicable to tracerouting any other SID 749 behaviors. 751 Please note that traceroute to a SID is exemplified using UDP probes. 752 However, the procedure is equally applicable to other implementations 753 of traceroute mechanism. The UDP encoded message to traceroute a SID 754 would use the UDP ports assigned by IANA for "traceroute use". 756 Consider the example where the user wants to traceroute a remote SID 757 2001:db8:K:4::, via 2001:db8:K:2:X31::, from node N1. The traceroute 758 probe is processed at the individual nodes along the path as follows: 760 o Node N1 initiates a traceroute probe packet as follows 761 (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:4::, 762 2001:db8:K:2:X31::; SL=1; NH=UDP)(Traceroute probe). The first 763 traceroute probe is sent with hop-count value set to 1. The hop- 764 count value is incremented by 1 for each following traceroute 765 probes. 767 o When node N2 receives the packet with hop-count = 1, it processes 768 the hop-count expiry. Specifically, the node N2 responds with the 769 ICMPv6 message (Type: "Time Exceeded", Code: "Hop limit exceeded 770 in transit"). The ICMPv6 response is IP routed. 772 o When Node N2 receives the packet with hop-count > 1, it performs 773 the standard SRH processing. Specifically, it executes the End.X 774 behavior indicated by the 2001:db8:K:2:X31:: SID on the traceroute 775 probe. If 2001:db8:K:2:X31:: is a PSP SID, node N2 executes the 776 SID like any other data packet with DA = 2001:db8:K:2:X31:: and 777 removes the SRH. 779 o When node N3, which is a non-SRv6 capable node, receives the 780 packet with hop-count = 1, it processes the hop-count expiry. 781 Specifically, the node N3 responds with the ICMPv6 message (Type: 782 "Time Exceeded", Code: "Hop limit exceeded in Transit"). The 783 ICMPv6 response is IP routed. 785 o When node N3, which is a non-SRv6 capable node, receives the 786 packet with hop-count > 1, it performs the standard IPv6 787 processing. Specifically, it forwards the traceroute probe based 788 on DA 2001:db8:K:4:: in the IPv6 header. 790 o When node N4 receives the packet with DA set to the local SID 791 2001:db8:K:4::, it processes the END SID. 793 o If the target SID (2001:db8:K:4::) is not locally instantiated and 794 does not represent a local interface, the packet is discarded. 796 o If the target SID (2001:db8:K:4::) is locally instantiated or 797 represents a local interface, the node processes the upper layer 798 header. As part of the upper layer header processing node N4 799 responds with the ICMPv6 message (Type: Destination unreachable, 800 Code: Port Unreachable). The ICMPv6 response is IP routed. 802 Figure 4 displays a sample traceroute output for this example. 804 > traceroute 2001:db8:K:4:X52:: via segment-list 2001:db8:K:2:X31:: 806 Tracing the route to SID 2001:db8:K:4:X52:: 807 1 2001:db8:2:1:21:: 0.512 msec 0.425 msec 0.374 msec 808 DA: 2001:db8:K:2:X31::, 809 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=1) 810 2 2001:db8:3:2:21:: 0.721 msec 0.810 msec 0.795 msec 811 DA: 2001:db8:K:4:X52::, 812 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0) 813 3 2001:db8:4:3:41:: 0.921 msec 0.816 msec 0.759 msec 814 DA: 2001:db8:K:4:X52::, 815 SRH:(2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=0) 817 Figure 4 A sample output for hop-by-hop traceroute to a SID 819 A.3. A Hybrid OAM Using O-flag 821 This section illustrates a hybrid OAM mechanism using the the O-flag. 822 Without loss of the generality, the illustration assumes N100 is a 823 centralized controller. 825 The illustration is different than the In-situ OAM defined in [I.D- 826 draft-ietf-ippm-ioam-data]. This is because In-situ OAM records 827 operational and telemetry information in the packet as the packet 828 traverses a path between two points in the network [I.D-draft-ietf- 829 ippm-ioam-data]. The illustration in this subsection does not 830 require the recording of OAM data in the packet. 832 The illustration does not assume any formats for exporting the data 833 elements or the data elements that need to be exported. The 834 illustration assumes system clocks among all nodes in the SR domain 835 are synchronized. 837 Consider the example where the user wants to monitor sampled IPv4 VPN 838 999 traffic going from CE1 to CE2 via a low latency SR policy P 839 installed at Node N1. To exercise a low latency path, the SR Policy 840 P forces the packet via segments 2001:db8:K:2:X31:: and 841 2001:db8:K:4:X52::. The VPN SID at N7 associated with VPN 999 is 842 2001:db8:K:7:DT999::. 2001:db8:K:7:DT999:: is a USP SID. N1, N4, 843 and N7 are capable of processing O-flag but N2 is not capable of 844 processing O-flag. N100 is the centralized controller capable of 845 processing and correlating the copy of the packets sent from nodes 846 N1, N4, and N7. N100 is aware of O-flag processing capabilities. 847 Controller N100 with the help from nodes N1, N4, N7 and implements a 848 hybrid OAM mechanism using the O-flag as follows: 850 o A packet P1:(IPv4 header)(payload) is sent from CE1 to Node N1. 852 o Node N1 steers the packet P1 through the Policy P. Based on a 853 local configuration, Node N1 also implements logic to sample 854 traffic steered through policy P for hybrid OAM purposes. 855 Specification for the sampling logic is beyond the scope of this 856 document. Consider the case where packet P1 is classified as a 857 packet to be monitored via the hybrid OAM. Node N1 sets O-flag 858 during the encapsulation required by policy P. As part of setting 859 the O-flag, node N1 also sends a timestamped copy of the packet 860 P1: (2001:db8:L:1::, 2001:db8:K:2:X31::) (2001:db8:K:7:DT999::, 861 2001:db8:K:4:X52::, 2001:db8:K:2:X31::; SL=2; O-flag=1; 862 NH=IPv4)(IPv4 header)(payload) to a local OAM process. The local 863 OAM process sends a full or partial copy of the packet P1 to the 864 controller N100. The OAM process includes the recorded timestamp, 865 additional OAM information like incoming and outgoing interface, 866 etc. along with any applicable metadata. Node N1 forwards the 867 original packet towards the next segment 2001:db8:K:2:X31::. 869 o When node N2 receives the packet with O-flag set, it ignores the 870 O-flag. This is because node N2 is not capable of processing the 871 O-flag. Node N2 performs the standard SRv6 SID and SRH 872 processing. Specifically, it executes the End.X behavior 873 indicated by the 2001:db8:K:2:X31:: SID as described in [RFC8986] 874 and forwards the packet P1 (2001:db8:L:1::, 2001:db8:K:4:X52::) 875 (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 2001:db8:K:2:X31::; 876 SL=1; O-flag=1; NH=IPv4)(IPv4 header)(payload) over link 3 towards 877 Node N3. 879 o When node N3, which is a non-SRv6 capable node, receives the 880 packet P1 , it performs the standard IPv6 processing. 882 Specifically, it forwards the packet P1 based on DA 883 2001:db8:K:4:X52:: in the IPv6 header. 885 o When node N4 receives the packet P1 (2001:db8:L:1::, 886 2001:db8:K:4:X52::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 887 2001:db8:K:2:X31::; SL=1; O-flag=1; NH=IPv4)(IPv4 888 header)(payload), it processes the O-flag. As part of processing 889 the O-flag, it sends a timestamped copy of the packet to a local 890 OAM process. Based on a local configuration, the local OAM 891 process sends a full or partial copy of the packet P1 to the 892 controller N100. The OAM process includes the recorded timestamp, 893 additional OAM information like incoming and outgoing interface, 894 etc. along with any applicable metadata. Node N4 performs the 895 standard SRv6 SID and SRH processing on the original packet P1. 896 Specifically, it executes the End.X behavior indicated by the 897 2001:db8:K:4:X52:: SID and forwards the packet P1 (2001:db8:L:1::, 898 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 899 2001:db8:K:2:X31::; SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload) 900 over link 10 towards Node N5. 902 o When node N5, which is a non-SRv6 capable node, receives the 903 packet P1, it performs the standard IPv6 processing. 904 Specifically, it forwards the packet based on DA 905 2001:db8:K:7:DT999:: in the IPv6 header. 907 o When node N7 receives the packet P1 (2001:db8:L:1::, 908 2001:db8:K:7:DT999::) (2001:db8:K:7:DT999::, 2001:db8:K:4:X52::, 909 2001:db8:K:2:X31::; SL=0; O-flag=1; NH=IPv4)(IPv4 910 header)(payload), it processes the O-flag. As part of processing 911 the O-flag, it sends a timestamped copy of the packet to a local 912 OAM process. The local OAM process sends a full or partial copy 913 of the packet P1 to the controller N100. The OAM process includes 914 the recorded timestamp, additional OAM information like incoming 915 and outgoing interface, etc. along with any applicable metadata. 916 Node N7 performs the standard SRv6 SID and SRH processing on the 917 original packet P1. Specifically, it executes the VPN SID 918 indicated by the 2001:db8:K:7:DT999:: SID and based on lookup in 919 table 100 forwards the packet P1 (IPv4 header)(payload) towards CE 920 2. 922 o The controller N100 processes and correlates the copy of the 923 packets sent from nodes N1, N4 and N7 to find segment-by-segment 924 delays and provide other hybrid OAM information related to packet 925 P1. For segment-by-segment delay computation, it is assumed that 926 clock are synchronized time across the SR domain. 928 o The process continues for any other sampled packets. 930 A.4. Monitoring of SRv6 Paths 932 In the recent past, network operators demonstrated interest in 933 performing network OAM functions in a centralized manner. [RFC8403] 934 describes such a centralized OAM mechanism. Specifically, the 935 document describes a procedure that can be used to perform path 936 continuity check between any nodes within an SR domain from a 937 centralized monitoring system. However, the document focuses on SR 938 networks with MPLS data plane. This document describes how the 939 concept can be used to perform path monitoring in an SRv6 network 940 from a centralized controller. 942 In the reference topology in Figure 1, N100 uses an IGP protocol like 943 OSPF or IS-IS to get the topology view within the IGP domain. N100 944 can also use BGP-LS to get the complete view of an inter-domain 945 topology. The controller leverages the visibility of the topology to 946 monitor the paths between the various endpoints. 948 The controller N100 advertises an END SID [RFC8986] 949 2001:db8:K:100:1::. To monitor any arbitrary SRv6 paths, the 950 controller can create a loopback probe that originates and terminates 951 on Node N100. To distinguish between a failure in the monitored path 952 and loss of connectivity between the controller and the network, Node 953 N100 runs a suitable mechanism to monitor its connectivity to the 954 monitored network. 956 The loopback probes are exemplified using an example where controller 957 N100 needs to verify a segment list <2001:db8:K:2:X31::, 958 2001:db8:K:4:X52::>: 960 o N100 generates an OAM packet (2001:db8:L:100::, 961 2001:db8:K:2:X31::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 962 2001:db8:K:2:X31::, SL=2)(OAM Payload). The controller routes the 963 probe packet towards the first segment, which is 964 2001:db8:K:2:X31::. 966 o Node N2 executes the End.X behavior indicated by the 967 2001:db8:K:2:X31:: SID and forwards the packet (2001:db8:L:100::, 968 2001:db8:K:4:X52::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 969 2001:db8:K:2:X31::, SL=1)(OAM Payload) on link3 to N3. 971 o Node N3, which is a non-SRv6 capable node, performs the standard 972 IPv6 processing. Specifically, it forwards the packet based on 973 the DA 2001:db8:K:4:X52:: in the IPv6 header. 975 o Node N4 executes the End.X behavior indicated by the 976 2001:db8:K:4:X52:: SID and forwards the packet (2001:db8:L:100::, 977 2001:db8:K:100:1::)(2001:db8:K:100:1::, 2001:db8:K:4:X52::, 978 2001:db8:K:2:X31::, SL=0)(OAM Payload) on link10 to N5. 980 o Node N5, which is a non-SRv6 capable node, performs the standard 981 IPv6 processing. Specifically, it forwards the packet based on 982 the DA 2001:db8:K:100:1:: in the IPv6 header. 984 o Node N100 executes the standard SRv6 END behavior. It 985 decapsulates the header and consume the probe for OAM processing. 986 The information in the OAM payload is used to detect any missing 987 probes, round trip delay, etc. 989 The OAM payload type or the information carried in the OAM probe is a 990 local implementation decision at the controller and is outside the 991 scope of this document. 993 Appendix B. Acknowledgements 995 The authors would like to thank Joel M. Halpern, Greg Mirsky, Bob 996 Hinden, Loa Andersson, Gaurav Naik, Ketan Talaulikar and Haoyu Song 997 for their review comments. 999 Appendix C. Contributors 1001 The following people have contributed to this document: 1003 Robert Raszuk 1004 Bloomberg LP 1005 Email: robert@raszuk.net 1007 John Leddy 1008 Individual 1009 Email: john@leddy.net 1011 Gaurav Dawra 1012 LinkedIn 1013 Email: gdawra.ietf@gmail.com 1015 Bart Peirens 1016 Proximus 1017 Email: bart.peirens@proximus.com 1018 Nagendra Kumar 1019 Cisco Systems, Inc. 1020 Email: naikumar@cisco.com 1022 Carlos Pignataro 1023 Cisco Systems, Inc. 1024 Email: cpignata@cisco.com 1026 Rakesh Gandhi 1027 Cisco Systems, Inc. 1028 Canada 1029 Email: rgandhi@cisco.com 1031 Frank Brockners 1032 Cisco Systems, Inc. 1033 Germany 1034 Email: fbrockne@cisco.com 1036 Darren Dukes 1037 Cisco Systems, Inc. 1038 Email: ddukes@cisco.com 1040 Cheng Li 1041 Huawei 1042 Email: chengli13@huawei.com 1044 Faisal Iqbal 1045 Individual 1046 Email: faisal.ietf@gmail.com 1048 Authors' Addresses 1050 Zafar Ali 1051 Cisco Systems 1053 Email: zali@cisco.com 1054 Clarence Filsfils 1055 Cisco Systems 1057 Email: cfilsfil@cisco.com 1059 Satoru Matsushima 1060 Softbank 1062 Email: satoru.matsushima@g.softbank.co.jp 1064 Daniel Voyer 1065 Bell Canada 1067 Email: daniel.voyer@bell.ca 1069 Mach Chen 1070 Huawei 1072 Email: mach.chen@huawei.com