idnits 2.17.1 draft-jain-bess-evpn-lsp-ping-05.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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2486 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: 'RFC4385' is mentioned on line 311, but not defined == Unused Reference: 'RFC4875' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC6338' is defined on line 612, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup P. Jain, Ed. 3 Internet-Draft S. Salam 4 Intended status: Standards Track A. Sajassi 5 Expires: January 4, 2018 Cisco Systems, Inc. 6 S. Boutros 7 VmWare, Inc. 8 G. Mirsky 9 ZTE Corporation. 10 July 3, 2017 12 LSP-Ping Mechanisms for EVPN and PBB-EVPN 13 draft-jain-bess-evpn-lsp-ping-05 15 Abstract 17 LSP-Ping is a widely deployed Operation, Administration, and 18 Maintenance (OAM) mechanism in MPLS networks. This document 19 describes mechanisms for detecting data-plane failures using LSP Ping 20 in MPLS based EVPN and PBB-EVPN networks. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Proposed Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 3 60 4.1. EVPN MAC Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 61 4.2. EVPN Inclusive Multicast Sub-TLV . . . . . . . . . . . . 5 62 4.3. EVPN Auto-Discovery Sub-TLV . . . . . . . . . . . . . . . 6 63 4.4. EVPN IP Prefix Sub-TLV . . . . . . . . . . . . . . . . . 6 64 5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 7 65 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Unicast Data-plane connectivity checks . . . . . . . . . 7 67 6.2. Inclusive Multicast Data-plane Connectivity Checks . . . 9 68 6.2.1. Ingress Replication . . . . . . . . . . . . . . . . . 9 69 6.2.2. Using P2MP P-tree . . . . . . . . . . . . . . . . . . 10 70 6.2.3. Controlling Echo Responses when using P2MP P-tree . . 11 71 6.3. EVPN Aliasing Data-plane connectivity check . . . . . . . 11 72 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8.1. Sub-TLV Type . . . . . . . . . . . . . . . . . . . . . . 12 76 8.2. Proposed new Return Codes . . . . . . . . . . . . . . . . 12 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 [RFC7432] describes MPLS based Ethernet VPN (EVPN) technology. An 86 EVPN comprises CE(s) connected to PE(s). The PEs provide layer 2 87 EVPN among the CE(s) over the MPLS core infrastructure. In EVPN 88 networks, PEs advertise the MAC addresses learned from the locally 89 connected CE(s), along with MPLS Label, to remote PE(s) in the 90 control plane using multi-protocol BGP. EVPN enables multi-homing of 91 CE(s) connected to multiple PEs and load balancing of traffic to and 92 from multi-homed CE(s). 94 [RFC7623] describes the use of Provider Backbone Bridging [802.1ah] 95 with EVPN. PBB-EVPN maintains the C-MAC learning in data plane and 96 only advertises Provider Backbone MAC (B-MAC) addresses in control 97 plane using BGP. 99 Procedures for simple and efficient mechanisms to detect data-plane 100 failures using LSP Ping in MPLS network are well defined in 101 [RFC8029][RFC6425]. This document defines procedures to detect data- 102 plane failures using LSP Ping in MPLS networks deploying EVPN and 103 PBB-EVPN. This draft defines 4 new Sub-TLVs for Target FEC Stack TLV 104 with the purpose of identifying the FEC on the Peer PE. 106 2. Specification of Requirements 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Terminology 114 AD: Auto Discovery 116 B-MAC: Backbone MAC Address 118 CE: Customer Edge Device 120 C-MAC: Customer MAC Address 122 DF: Designated Forwarder 124 ESI: Ethernet Segment Identifier 126 EVI: EVPN Instance Identifier that globally identifies the EVPN 127 Instance 129 EVPN: Ethernet Virtual Private Network 131 MPLS-OAM: MPLS Operations, Administration and Maintenance 133 P2MP: Point-to-Multipoint 135 PBB: Provider Backbone Bridge 137 PE: Provider Edge Device 139 4. Proposed Target FEC Stack Sub-TLVs 141 This document introduces four new Target FEC Stack sub-TLVs that are 142 included in the LSP-Ping Echo Request packet sent for detecting 143 faults in data-plane connectivity in EVPN and PBB-EVPN networks. 144 These Target FEC Stack sub-TLVs are described next. 146 All these TLVs contain 8 bytes EVI value which identifies the EVPN 147 instance globally. 149 4.1. EVPN MAC Sub-TLV 151 The EVPN MAC sub-TLV is used to identify the MAC for an EVI under 152 test at a peer PE. 154 The EVPN MAC sub-TLV fields are derived from the MAC/IP advertisement 155 route defined in [RFC7432] Section 7.2 and has the format as shown in 156 Figure 1. This TLV is included in the Echo Request sent to the Peer 157 PE by the PE that is the originator of the request. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Route Distinguisher | 163 | (8 octets) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Ethernet Tag ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 + EVI + 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Ethernet Segment Identifier | 172 | (10 octets) | 173 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | must be zero | MAC Addr Len | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | MAC Address | 177 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | Must be zero | IP Addr Len | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | IP Address (0, 4 or 16 Octets) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 1: EVPN MAC sub-TLV format 185 The LSP Ping echo request is sent using the EVPN MPLS label(s) 186 associated with the MAC route announced by a remote PE and the MPLS 187 transport label(s) to reach the remote PE. 189 4.2. EVPN Inclusive Multicast Sub-TLV 191 The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN 192 Inclusive Multicast route defined in [RFC7432] Section 7.3. 194 The EVPN Inclusive Multicast sub-TLV has the format as shown in 195 Figure 2. This TLV is included in the echo request sent to the EVPN 196 peer PE by the originator of request to verify the multicast 197 connectivity state on the peer PE(s) in EVPN and PBB-EVPN. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Route Distinguisher | 203 | (8 octets) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Ethernet Tag ID | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 + EVI + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | IP Addr Len | | 212 +-+-+-+-+-+-+-+ | 213 ~ Originating Router's IP Addr ~ 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2: EVPN Inclusive Multicast sub-TLV format 219 Broadcast, multicast and unknown unicast traffic can be sent using 220 ingress replication or P2MP P-tree in EVPN and PBB-EVPN network. In 221 case of ingress replication, the Echo Request is sent using a label 222 stack of [Transport label, Inclusive Multicast label] to each remote 223 PE participating in EVPN or PBB-EVPN. The inclusive multicast label 224 is the downstream assigned label announced by the remote PE to which 225 the Echo Request is being sent. The Inclusive Multicast label is the 226 inner label in the MPLS label stack. 228 When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent 229 using P2MP P-tree transport label for inclusive P-tree arrangement or 230 using a label stack of [P2MP P-tree transport label, upstream 231 assigned EVPN Inclusive Multicast label] for aggregate inclusive P2MP 232 P-tree arrangement as described in Section 6. 234 In case of EVPN, an additional, EVPN Auto-Discovery sub-TLV and ESI 235 MPLS label as the bottom label, may also be included in the Echo 236 Request as is described in Section 6. 238 4.3. EVPN Auto-Discovery Sub-TLV 240 The EVPN Auto-Discovery (AD) sub-TLV fields are based on the Ethernet 241 AD route advertisement defined in [RFC7432] Section 7.1. EVPN AD 242 sub-TLV applies to only EVPN. 244 The EVPN AD sub-TLV has the format shown in Figure 3. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Route Distinguisher | 250 | (8 octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Ethernet Tag ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 + EVI + 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Ethernet Segment Identifier | 259 | (10 octets) | 260 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | must be zero | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 3: EVPN Auto-Discovery sub-TLV format 266 4.4. EVPN IP Prefix Sub-TLV 268 The EVPN IP Prefix sub-TLV is used to identify the IP Prefix for an 269 EVI under test at a peer PE. 271 The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix 272 Route (RT-5) advertisement defined in 273 [I-D.ietf-bess-evpn-prefix-advertisement] and has the format as shown 274 in Figure 4. This TLV is included in the Echo Request sent to the 275 Peer PE by the PE that is the originator of the request. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Route Distinguisher | 281 | (8 octets) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Ethernet Tag ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 + EVI + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Ethernet Segment Identifier | 290 | (10 octets) | 291 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | must be zero | IP Prefix Len | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 ~ IP Prefix (4 or 16 Octets) ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ~ GW IP Address (4 or 16 Octets) ~ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 4: EVPN IP Prefix sub-TLV format 301 The LSP Ping echo request is sent using the EVPN MPLS label(s) 302 associated with the IP Prefix route announced by a remote PE and the 303 MPLS transport label(s) to reach the remote PE. 305 5. Encapsulation of OAM Ping Packets 307 The LSP Ping Echo request IPv4/UDP packets are encapsulated with the 308 Transport and EVPN Label(s) followed by the Generic Associated 309 Channel Label (GAL) [RFC6426] which is bottom most label. The GAL 310 label is followed by IPv4(0x0021) or IPv6(0x0057) Associated Channel 311 Header (ACH) [RFC4385]. 313 6. Operations 315 6.1. Unicast Data-plane connectivity checks 317 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 318 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 319 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 320 Similarly PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 321 00aa.00bb.00cc and with MPLS label 16002. 323 On PE3, when a operator performs a connectivity check for the B-MAC 324 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 325 request with the target FEC stack TLV containing EVPN MAC sub-TLV in 326 the Echo Request packet. The Echo Request packet is sent with the 327 {Transport Label(s) to reach PE1 + EVPN Label = 16001 + GAL} MPLS 328 label stack and IP ACH Channel header. Once the echo request packet 329 reaches PE1, PE1 will use the GAL label and the IP ACH Channel header 330 to determine that the packet is IPv4 OAM Packet. The PE1 will 331 process the packet and perform checks for the EVPN MAC sub-TLV 332 present in the Target FEC Stack TLV as described in Section 4.4 in 333 [RFC8029] and respond according to [RFC8029] processing rules. 335 BEB +-----------------+ BEB 336 || | | || 337 \/ | | \/ 338 +----+ AC1 +-----+ +-----+ +----+ 339 | CE1|------| | | PE 3|-----| CE2| 340 +----+\ | PE1 | IP/MPLS | | +----+ 341 \ +-----+ Network +-----+ 342 \ | | 343 AC2\ +-----+ | 344 \ | | | 345 \| PE2 | | 346 +-----+ | 347 /\ | | 348 || +-----------------+ 349 BEB 351 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 353 Figure 5: PBB EVPN network 355 Similarly, on PE3, when an operator performs a connectivity check for 356 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 357 LSP Ping request with the target FEC stack TLV containing EVPN MAC 358 sub-TLV in the echo request packet. The echo request packet is sent 359 with the {MPLS transport Label(s) to reach PE2 + EVPN Label = 16002 + 360 GAL} MPLS label stack and IP ACH Channel header. 362 LSP Ping operation for unicast data-plane connectivity checks in E- 363 VPN, are similar to those described above for PBB-EVPN except that 364 the checks are for C-MAC addresses instead of B-MAC addresses. 366 6.2. Inclusive Multicast Data-plane Connectivity Checks 368 6.2.1. Ingress Replication 370 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 371 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 372 set to ingress replication and downstream assigned inclusive 373 multicast MPLS label 17001. Similarly PE2 announced an Inclusive 374 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 375 10), PMSI tunnel attribute Tunnel type set to ingress replication and 376 downstream assigned inclusive multicast MPLS label 17002. 378 Given CE1 is dual homed to PE1 and PE2, assume that PE1 is the DF for 379 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 380 44dd.5500. 382 When an operator at PE3 initiates a connectivity check for the 383 inclusive multicast on PE1, the operator initiates an LSP Ping 384 request with the target FEC stack TLV containing EVPN Inclusive 385 Multicast sub-TLV in the Echo Request packet. The Echo Request 386 packet is sent with the {Transport Label(s) to reach PE1 + EVPN Incl. 387 Multicast Label = 17001 + GAL} MPLS label stack and IP ACH Channel 388 header. Once the echo request packet reaches PE1, PE1 will use the 389 GAL label and the IP ACH Channel header to determine that the packet 390 is IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 391 label. PE1 will process the packet and perform checks for the EVPN 392 Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as 393 described in Section 4.4 in [RFC8029] and respond according to 394 [RFC8029] processing rules. 396 Operator at PE3, may similarly also initiate an LSP Ping to PE2 with 397 the target FEC stack TLV containing EVPN Inclusive Multicast sub- TLV 398 in the echo request packet. The echo request packet is sent with the 399 {transport Label(s) to reach PE2 + EVPN Incl. Multicast Label = 400 17002 + GAL} MPLS label stack and IP ACH Channel header. Once the 401 echo request packet reaches PE2, PE2 will use the GAL label and the 402 IP ACH Channel header to determine that the packet is IPv4 OAM 403 Packet. Since PE2 is not the DF for ISID 10 for the port 404 corresponding to the ESI value in the Inclusive Multicast sub- TLV in 405 the Echo Request, PE2 will reply with special code indicating that 406 FEC exists on the router and the behavior is to drop the packet 407 because of not DF as described in Section 8. 409 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 410 and the associated MPLS Split Horizon Label above the GAL label in 411 the MPLS label stack, may be added to emulate traffic coming from a 412 MH site, this label is used by leaf PE(s) attached to the same MH 413 site not to forward packets back to the MH site. If the behavior on 414 a leaf PE is to drop the packet because of Split Horizon filtering, 415 the PE2 will reply with special code indicating that FEC exists on 416 the router and the behavior is to drop the packet because of Split 417 Horizon Filtering as described in Section 8. 419 6.2.2. Using P2MP P-tree 421 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 422 EVPN or PBB-EVPN networks. 424 When using an inclusive P-tree arrangement, p2mp p-tree transport 425 label itself is used to identify the L2 service associated with the 426 Inclusive Multicast Route, this L2 service could be a customer 427 Bridge, or a Provider Backbone Bridge. 429 For an Inclusive P-tree arrangement, when an operator performs a 430 connectivity check for the multicast L2 service, the operator 431 initiates an LSP Ping request with the target FEC stack TLV 432 containing EVPN Inclusive Multicast sub-TLV in the echo request 433 packet. The echo request packet is sent over P2MP LSP with the {P2MP 434 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 436 When using Aggregate Inclusive P-tree, a PE announces an upstream 437 assigned MPLS label along with the P-tree ID, in that case both the 438 p2mp p-tree MPLS transport label and the upstream MPLS label can be 439 used to identify the L2 service. 441 For an Aggregate Inclusive P-tree arrangement, when an operator 442 performs a connectivity check for the multicast L2 service, the 443 operator initiates an LSP Ping request with the target FEC stack TLV 444 containing EVPN Inclusive Multicast sub-TLV in the echo request 445 packet. The echo request packet is sent over P2MP LSP using the IP- 446 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 447 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 448 header. 450 The Leaf PE(s) of the p2mp tree will process the packet and perform 451 checks for the EVPN Inclusive Multicast sub-TLV present in the Target 452 FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond 453 according to [RFC8029] processing rules. A PE that is not the DF for 454 the EVI on the ESI in the Inclusive Multicast sub-TLV, will reply 455 with a special code indicating that FEC exists on the router and the 456 behavior is to drop the packet because of not DF as described in 457 Section 8. 459 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 460 and the associated MPLS Split Horizon Label above the GAL Label in 461 MPLS label stack, may be added to emulate traffic coming from a MH 462 site, this label is used by leaf PE(s) attached to the same MH site 463 not to forward packets back to the MH site. If the behavior on a 464 leaf PE is to drop the packet because of Split Horizon filtering, the 465 PE2 will reply with special code indicating that FEC exists on the 466 router and the behavior is to drop the packet because of Split 467 Horizon Filtering as described in Section 8. 469 6.2.3. Controlling Echo Responses when using P2MP P-tree 471 The procedures described in [RFC6425] for preventing congestion of 472 Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 473 single egress node (Node Address P2MP Responder Identifier TLV) can 474 be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees 475 for broadcast, multicast and unknown unicast traffic. 477 6.3. EVPN Aliasing Data-plane connectivity check 479 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 480 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 481 discovery Route with the ESI set to CE1 system ID and MPLS label 482 19002. 484 When an operator performs at PE3 a connectivity check for the 485 aliasing aspect of the Ethernet AD route to PE1, the operator 486 initiates an LSP Ping request with the target FEC stack TLV 487 containing EVPN Ethernet AD sub-TLV in the echo request packet. The 488 echo request packet is sent with the {Transport label(s) to reach PE1 489 + EVPN Ethernet AD Label 19001 + GAL} MPLS label stack and IP ACH 490 Channel header. 492 When PE1 receives the packet it will process the packet and perform 493 checks for the EVPN Ethernet AD sub-TLV present in the Target FEC 494 Stack TLV as described in Section 4.4 in [RFC8029] and respond 495 according to [RFC8029] processing rules. 497 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 499 Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an 500 IP prefix reachable behind CE1 and MPLS label 20001. When an 501 operator on PE3 performs a connectivity check for the IP prefix on 502 PE1, the operator initiates an LSP Ping request with the target FEC 503 stack TLV containing EVPN IP Prefix sub-TLV in the echo request 504 packet. The echo request packet is sent with the {Transport label(s) 505 to reach PE1 + EVPN IP Prefix Label 20001 } MPLS label stack. 507 When PE1 receives the packet it will process the packet and perform 508 checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack 509 TLV as described in Section 4.4 in [RFC8029] and respond according to 510 [RFC8029] processing rules. 512 7. Security Considerations 514 The proposal introduced in this document does not introduce any new 515 security considerations beyond that already apply to [RFC7432], 516 [RFC7623] and [RFC6425]. 518 8. IANA Considerations 520 8.1. Sub-TLV Type 522 This document defines 4 new sub-TLV type to be included in Target FEC 523 Stack TLV (TLV Type 1) [RFC8029] in LSP Ping. 525 IANA is requested to assign a sub-TLV type value to the following 526 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label Switched 527 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- TLVs" sub- 528 registry: 530 o EVPN MAC route sub-TLV 532 o EVPN Inclusive Multicast route sub-TLV 534 o EVPN Auto-Discovery Route sub-TLV 536 o EVPN IP Prefix Route sub-TLV 538 8.2. Proposed new Return Codes 540 [RFC8029] defines values for the Return Code field of Echo Reply. 541 This document proposes two new Return Codes, which SHOULD be included 542 in the Echo Reply message by a PE in response to LSP Ping Echo 543 Request message: 545 1. The FEC exists on the PE and the behavior is to drop the packet 546 because of not DF. 548 2. The FEC exists on the PE and the behavior is to drop the packet 549 because of Split Horizon Filtering. 551 9. Acknowledgments 553 The authors would like to thank Patrice Brissette and Weiguo Hao for 554 their comments. 556 10. References 558 10.1. Normative References 560 [I-D.ietf-bess-evpn-prefix-advertisement] 561 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 562 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 563 bess-evpn-prefix-advertisement-04 (work in progress), 564 February 2017. 566 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 567 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 568 Failures in Point-to-Multipoint MPLS - Extensions to LSP 569 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 570 . 572 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 573 On-Demand Connectivity Verification and Route Tracing", 574 RFC 6426, DOI 10.17487/RFC6426, November 2011, 575 . 577 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 578 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 579 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 580 2015, . 582 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 583 Henderickx, "Provider Backbone Bridging Combined with 584 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 585 September 2015, . 587 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 588 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 589 Switched (MPLS) Data-Plane Failures", RFC 8029, 590 DOI 10.17487/RFC8029, March 2017, 591 . 593 10.2. Informative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, 597 DOI 10.17487/RFC2119, March 1997, 598 . 600 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 601 Yasukawa, Ed., "Extensions to Resource Reservation 602 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 603 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 604 DOI 10.17487/RFC4875, May 2007, 605 . 607 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 608 Circuit Connectivity Verification (VCCV): A Control 609 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 610 December 2007, . 612 [RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform 613 Resource Name (URN) Namespace for the Schema for Academia 614 (SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011, 615 . 617 Authors' Addresses 619 Parag Jain (editor) 620 Cisco Systems, Inc. 621 2000 Innovation Drive 622 Kanata, ON K2K 3E8 623 Canada 625 Email: paragj@cisco.com 627 Samer Salam 628 Cisco Systems, Inc. 629 595 Burrard Street, Suite 2123 630 Vancouver, BC V7X 1J1 631 Canada 633 Email: ssalam@cisco.com 635 Ali Sajassi 636 Cisco Systems, Inc. 637 USA 639 Email: sajassi@cisco.com 640 Sami Boutros 641 VmWare, Inc. 642 USA 644 Email: sboutros@vmware.com 646 Greg Mirsky 647 ZTE Corporation. 648 USA 650 Email: gregmirsky@gmail.com>