idnits 2.17.1 draft-vji-evpn-ping-vxlan-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 13 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 209 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 140 has weird spacing: '...Gateway an en...' -- The document date (May 7, 2018) is 2181 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6426' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 490, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Ji 3 Internet Draft J. Rajamanickam 4 Intended status: Informational H. Ouahid 5 Expires: November 7, 2018 C. Wang 6 X. Du 7 Cisco Systems, Inc. 8 May 7, 2018 10 E-VPN Ping Mechanism for Virtual eXtensible Local Area Network 11 (VXLAN) 12 draft-vji-evpn-ping-vxlan-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on November 7, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 Ping is a widely deployed Operation, Administration, and Maintenance 55 (OAM) mechanism in networks. This document describes a mechanism 56 for detecting data-plane failures using Ping in RFC7348 VXLAN based 57 EVPN networks. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Conventions used in this document..............................3 63 3. Acronyms and Definitions.......................................3 64 4. IP ping and trace route extension for VXLAN....................4 65 5. VXLAN OAM header format........................................4 66 5.1. VXLAN EVPN OAM Header:....................................5 67 5.2. EVPN MAC/IP TLV...........................................7 68 5.3. EVPN Inclusive Multicast TLV..............................8 69 5.4. EVPN Auto-Discovery TLV...................................9 70 5.5. EVPN IP Prefix TLV.......................................10 71 6. E-VPN Context Validation procedure............................10 72 7. Security Considerations.......................................11 73 8. IANA Considerations...........................................11 74 9. References....................................................11 75 9.1. Normative References.....................................11 76 9.2. Informative References...................................13 77 10. Acknowledgments..............................................13 79 1. Introduction 81 RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework 82 for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks 83 defines means to support data center layer 2 E-VPN over an IP core 84 network. 86 draft-jain-bess-evpn-lsp-ping defines procedures to detect data- 87 plane failures using LSP Ping in MPLS networks deploying EVPN and 88 PBB-EVPN, which is an extension of RFC6426. 90 This document outlines how OAM data fields are encapsulated and how 91 connectivity check and fault isolation is performed from edge to 92 edge for VXLAN networks using RFC792 ICMP based ping and traceroute 93 solution. 95 2. Conventions used in this document 97 In examples, "C:" and "S:" indicate lines sent by the client and 98 server respectively. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 In this document, these words will appear with that interpretation 105 only when in ALL CAPS. Lower case uses of these words are not to be 106 interpreted as carrying significance described in RFC 2119. 108 In this document, the characters ">>" preceding an indented line(s) 109 indicates a statement using the key words listed above. This 110 convention aids reviewers in quickly identifying or finding the 111 portions of this RFC covered by these keywords. 113 3. Acronyms and Definitions 115 AD Auto Discovery 117 CE Customer Edge Device 119 ECMP Equal-Cost Multipath 121 ESI Ethernet Segment Identifier 123 EVPN Ethernet Virtual Private Network 125 OAM Operations, Administration and Maintenance 127 PE Provider Edge Device 129 VLAN Virtual Local Area Network 131 VNI VXLAN Network Identifier (or VXLAN Segment ID) 133 VTEP VXLAN Tunnel End Point. An entity that originates 134 and/or terminates VXLAN tunnels 136 VXLAN Virtual eXtensible Local Area Network 137 VXLAN Segment VXLAN Layer 2 overlay network over which VMs 138 communicate 140 VXLAN Gateway an entity that forwards traffic between VXLANs 142 4. IP ping and trace route extension for VXLAN 144 In IP network ICMP, UDP or HTTP based ping and traceroute provide 145 ways to perform reachability check and fault isolation, this can be 146 used for OAM purpose for the IP underlay network. E-VPN extension 147 for the existing ping and traceroute operations make it control- 148 plane aware and add additional capability to validate the E-VPN 149 forwarding context, detect data-plane errors and measure PE to PE 150 performance. 152 5. VXLAN OAM header format 154 IPv4 underlay OAM information is encoded in the VXLAN header as 155 below. 157 VXLAN Header 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |R|R|R|O|I|R|R|R| Reserved | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | VXLAN Network Identifier (VNI) | Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1 RFC7348 VXLAN header OAM extension 168 New O bit is selected for OAM purpose, value 1 for OAM packets, 0 169 for regular VXLAN traffic. This bit is temporarily declared as 170 bit3, subject to be changed 172 5.1. VXLAN EVPN OAM Header: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Option Class = OAM_ECHO | Type |R|R|R| Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Return Code | Return Subcode| Must Be Zero | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Sender's Handle | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | TimeStamp Sent (seconds) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | TimeStamp Sent (seconds fraction) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | TimeStamp Received (seconds) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TimeStamp Received (seconds fraction) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 . . 195 . TLVs . 196 . . 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2 VXLAN EVPN OAM header 201 Type: 0 for echo request; 1 for echo reply. 203 Return Code and Return sub-code must be zero for the ping or 204 traceroute request. For ping or traceroute reply, the value is 205 defined as: 207 Return Code # Value Field 208 ------------- ----------- 209 0 Success 210 1 Context Not Found 211 2 Context Found but IP address Mis-Match 213 Return sub-code is reserved for future use. 215 The Sender's Handle is filled in by the sender and returned 216 unchanged by the receiver in the echo reply (if any). There are no 217 semantics associated with this handle, although a sender may find 218 this useful for matching up requests with replies. 220 The Sequence Number is assigned by the sender of the echo request 221 and can be (for example) used to detect missed replies. 223 The TimeStamp Sent is the time of day (according to the sender's 224 clock) in 64-bit NTP timestamp format [RFC5905] when the echo 225 request is sent. The TimeStamp Received in an echo reply is the 226 time of day (according to the receiver's clock) in 64-bit NTP 227 timestamp format in which the corresponding echo request was 228 received. TimeStamp Received must be zero for the request. Value 0 229 means the time is not measured or available, shall be ignored. 231 TLVs (Type-Length-Value tuples) have the following format: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type | Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Value | 239 . . 240 . . 241 . . 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 3 TLV format 246 TLV type values use the same value of corresponding BGP route type 247 when advertised the route, defined in [RFC7432], [draft-ietf-bess- 248 evpn-prefix-advertisement] and [draft-ietf-bess-evpn-igmp-mld- 249 proxy]. 251 Type # Value Field 252 -------- ----------- 253 1 Ethernet Auto-Discovery (A-D) TLV 254 2 MAC/IP TLV 255 3 Inclusive Multicast TLV 256 4 Ethernet Segment TLV (format to be defined) 257 5 IP Prefix TLV 258 6 Selective Multicast Ethernet Tag TLV (format to be 259 defined) 261 5.2. EVPN MAC/IP TLV 263 The EVPN MAC/IP TLV is used to identify the MAC for an EVI under 264 test at a peer PE. 266 The EVPN MAC TLV fields are derived from the MAC/IP advertisement 267 route defined in [RFC7432] Section 7.2 and has the format as shown 268 in Figure 4. This TLV is included in the Echo Request sent to the 269 Peer PE by the PE that is the originator of the request. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Route Distinguisher | 275 | (8 octets) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Ethernet Tag ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Ethernet Segment Identifier | 280 | (10 octets) | 281 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | must be zero | MAC Addr Len | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | MAC Address | 285 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | Must be zero | IP Addr Len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | IP Address (0, 4 or 16 Octets) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | L2VNI (3 Octets) | Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | L3VNI (3 Octets) | Reserved | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 4 EVPN MAC TLV format 296 The ping echo request is sent using the EVPN VNI(s) associated with 297 the MAC route announced by a remote PE to reach the remote PE. 299 5.3. EVPN Inclusive Multicast TLV 301 The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN 302 Inclusive Multicast route defined in [RFC7432] Section 7.3. The EVPN 303 Inclusive Multicast TLV has the format as shown in Figure 5. This 304 TLV is included in the echo request sent to the EVPN peer PE by the 305 originator of request to verify the multicast connectivity state on 306 the peer PE(s) in EVPN and PBB-EVPN. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Route Distinguisher | 312 | (8 octets) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Ethernet Tag ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | IP Addr Len | | 317 +-+-+-+-+-+-+-+ | 318 ~ Originating Router's IP Addr ~ 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | VNI (3 Octets) | Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5 EVPN Inclusive Multicast TLV format 325 Broadcast, multicast and unknown unicast traffic can be sent using 326 ingress replication or P2MP P-tree in EVPN network. 328 5.4. EVPN Auto-Discovery TLV 330 The EVPN Auto-Discovery (AD) TLV fields are based on the Ethernet AD 331 route advertisement defined in [RFC7432] Section 7.1. EVPN AD TLV 332 applies to only EVPN. The EVPN AD sub-TLV has the format shown in 333 Figure 6. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Route Distinguisher | 339 | (8 octets) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Ethernet Tag ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Ethernet Segment Identifier | 344 | (10 octets) | 345 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | must be zero | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | VNI (3 Octets) | Reserved | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 6 EVPN Auto-Discovery TLV format 352 5.5. EVPN IP Prefix TLV 354 The EVPN IP Prefix TLV is used to identify the IP Prefix for an EVI 355 under test at a peer PE. The EVPN IP Prefix sub-TLV fields are 356 derived from the IP Prefix Route (RT-5) advertisement defined in [I- 357 D.ietf-bess-evpn-prefix-advertisement] and has the format as shown 358 in Figure 7. This TLV is included in the Echo Request sent to the 359 Peer PE by the PE that is the originator of the request. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Route Distinguisher | 365 | (8 octets) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Ethernet Tag ID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Ethernet Segment Identifier | 370 | (10 octets) | 371 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | must be zero | IP Prefix Len | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 ~ IP Prefix (4 or 16 Octets) ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ~ GW IP Address (4 or 16 Octets) ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | L3VNI (3 Octets) | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 7 EVPN IP Prefix TLV format 382 6. E-VPN Context Validation procedure 384 The TLVs in the EVPN OAM header is collect from the control-plane of 385 the ping or traceroute initiator PE, and to be validated by control- 386 plane of the peer PE, mid-node transmit routers may ignore it. For 387 traceroute, when the packet is punted to OAM for each TTL expiry 388 event, transmitter router may update the TimeStamp field in the 389 header to provide performance measurement. 391 This procedure do not have preference of protocol selection of ping 392 or trace route. Typically, ICMP echo request and ICMP echo reply is 393 used for ping; while ICMP echo request, UDP, HTTP or other protocols 394 may be used for traceroute. There is no change to these upper level 395 protocols. 397 7. Security Considerations 399 The proposal introduced in this document does not introduce any new 400 security considerations beyond that already apply to [RFC7432], 401 [RFC7348], [RFC7623] and [RFC6425] and draft-jain-bess-evpn-lsp- 402 ping. 404 8. IANA Considerations 406 8.1. Sub-TLV Type 408 This document defines 6 new TLV types, which is intend to use the 409 same value as RT types defined in [RFC7432], [draft-ietf-bess- 411 evpn-prefix-advertisement] and [draft-ietf-bess-evpn-igmp-mld- 413 proxy]. 415 IANA is requested to assign a sub-TLV type value to the following 417 8.2. Proposed new Return Codes 419 [RFC8029] defines values for the Return Code field of Echo Reply. 420 This document proposes two new Return Codes, which SHOULD be 421 included in the Echo Reply message by a PE in response to LSP Ping 422 Echo Request message: 424 1. The FEC exists on the PE and the behavior is to drop the packet 425 because of not DF. 427 2. The FEC exists on the PE and the behavior is to drop the packet 428 because of Split Horizon Filtering. 430 9. References 432 9.1. Normative References 434 [RFC7348] M. Mahalingam, Storvisor, D. Dutt, K. Duda, P. Agarwal, L. 435 Kreeger, T. Sridhar, M. Bursell, C. Wright, "Virtual 436 eXtensible Local Area Network (VXLAN): A Framework for 437 Overlaying Virtualized Layer 2 Networks over Layer 3 438 Networks", RFC 7348, August 2014, . 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, DOI 443 10.17487/RFC2119, March 1997, . 446 [draft-ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, 447 W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix 448 Advertisement in EVPN", draft-ietf-bess-evpn-prefix- 449 advertisement-10 (work in progress), February 27, 2018. 451 [draft-ietf-bess-evpn-igmp-mld-proxy] Ali Sajassi, Samir Thoria, 452 Keyur Patel, Derek Yeung, John Drake and Wen Lin "IGMP and 453 MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-mld-proxy- 454 00 (work in progress), March 2017. 456 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 457 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 458 Failures in Point-to-Multipoint MPLS - Extensions to LSP 459 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 460 . 462 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 463 On-Demand Connectivity Verification and Route Tracing", 464 RFC 6426, DOI 10.17487/RFC6426, November 2011, 465 . 467 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 468 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 469 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 470 2015, . 472 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 473 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 474 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 475 10.17487/RFC8029, March 2017, . 478 [draft-jain-bess-evpn-lsp-ping] P. Jain, Ed., S. Salam, A. Sajassi, 479 S. Boutros and G. Mirsky, "LSP-Ping Mechanisms for EVPN 480 and PBB-EVPN", draft-jain-bess-evpn-lsp-ping-06 (work in 481 progress), January, 2018 483 [RFC5905] D. Mills, J. Martin, Ed., J. Burbank, W. Kasch, "Network 484 Time Protocol Version 4: Protocol and Algorithms 485 Specification", June 2010, . 488 9.2. Informative References 490 [RFC792] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL", RFC792, 491 September 1981, . 493 [RFC7623] A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. 494 Henderickx, "Provider Backbone Bridging Combined with 495 Ethernet VPN (PBB-EVPN)", September 2015, 496 . 498 10. Acknowledgments 500 This document was prepared using 2-Word-v2.0.template.dot. 502 Authors' Addresses 504 Victor Ji 505 Cisco Systems, Inc. 506 Email: vji@cisco.com 508 Jaganbabu Rajamanickam 509 Cisco Systems, Inc. 510 Email: jrajaman@cisco.com 512 Hicham Ouahid 513 Cisco Systems, Inc. 514 Email: houahid@cisco.com 516 Chuanfa Wang 517 Cisco Systems, Inc. 518 Email: chuanwan@cisco.com 520 Xianlei Du 521 Cisco Systems, Inc. 522 Email: xiandu@cisco.com