idnits 2.17.1 draft-ietf-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 (June 14, 2021) is 1040 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: 'RFC4875' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC6338' is defined on line 608, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 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: December 16, 2021 Cisco Systems, Inc. 6 S. Boutros 7 Ciena 8 G. Mirsky 9 ZTE Corporation. 10 June 14, 2021 12 LSP-Ping Mechanisms for EVPN and PBB-EVPN 13 draft-ietf-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 https://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 December 16, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 13 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 Customer MAC (C-MAC) learning in 96 data plane and only advertises Provider Backbone MAC (B-MAC) 97 addresses in control 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 document defines 4 new Sub-TLVs for Target FEC Stack 104 TLV 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 G-ACh: Generic Associated Channel 133 GAL: G-ACh Label 135 OAM: Operations, Administration, and Maintenance 137 P2MP: Point-to-Multipoint 139 PBB: Provider Backbone Bridge 141 PE: Provider Edge Device 143 4. Proposed Target FEC Stack Sub-TLVs 145 This document introduces four new Target FEC Stack sub-TLVs that are 146 included in the LSP-Ping Echo Request packet. The Echo Request 147 packets are used for connectivity check in data-plane in EVPN and 148 PBB-EVPN networks. The target FEC stack sub-TLVs MAY be used to 149 validate that an indentifier for a given EVPN is programmed at the 150 target node. These Target FEC Stack sub-TLVs are described next. 152 4.1. EVPN MAC Sub-TLV 154 The EVPN MAC sub-TLV is used to identify the MAC for an EVI under 155 test at a peer PE. 157 The EVPN MAC sub-TLV fields are derived from the MAC/IP advertisement 158 route defined in [RFC7432] Section 7.2 and have the format as shown 159 in Figure 1. This TLV is included in the Echo Request sent to the 160 Peer PE by the PE that is the originator of the request. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Route Distinguisher | 166 | (8 octets) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Ethernet Tag ID | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Ethernet Segment Identifier | 171 | (10 octets) | 172 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | must be zero | MAC Addr Len | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | MAC Address | 176 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | Must be zero | IP Addr Len | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | IP Address (0, 4 or 16 Octets) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: EVPN MAC sub-TLV format 184 The LSP Ping echo request is sent using the EVPN MPLS label(s) 185 associated with the MAC route announced by a remote PE and the MPLS 186 transport label(s) to reach the remote PE. 188 4.2. EVPN Inclusive Multicast Sub-TLV 190 The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN 191 Inclusive Multicast route defined in [RFC7432] Section 7.3. 193 The EVPN Inclusive Multicast sub-TLV has the format as shown in 194 Figure 2. This TLV is included in the echo request sent to the EVPN 195 peer PE by the originator of request to verify the multicast 196 connectivity state on the peer PE(s) in EVPN and PBB-EVPN. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Route Distinguisher | 202 | (8 octets) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Ethernet Tag ID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | IP Addr Len | | 207 +-+-+-+-+-+-+-+ | 208 ~ Originating Router's IP Addr ~ 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: EVPN Inclusive Multicast sub-TLV format 214 Broadcast, multicast, and unknown unicast traffic can be sent using 215 ingress replication or P2MP P-tree in EVPN and PBB-EVPN network. In 216 case of ingress replication, the Echo Request is sent using a label 217 stack of [Transport label, Inclusive Multicast label] to each remote 218 PE participating in EVPN or PBB-EVPN. The inclusive multicast label 219 is the downstream assigned label announced by the remote PE to which 220 the Echo Request is being sent. The Inclusive Multicast label is the 221 inner label in the MPLS label stack. 223 When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent 224 using P2MP P-tree transport label for inclusive P-tree arrangement or 225 using a label stack of [P2MP P-tree transport label, upstream 226 assigned EVPN Inclusive Multicast label] for the aggregate inclusive 227 P2MP P-tree arrangement as described in Section 6. 229 In case of EVPN, an additional, EVPN Auto-Discovery sub-TLV and ESI 230 MPLS label as the bottom label, may also be included in the Echo 231 Request as is described in Section 6. 233 4.3. EVPN Auto-Discovery Sub-TLV 235 The EVPN Auto-Discovery (AD) sub-TLV fields are based on the Ethernet 236 AD route advertisement defined in [RFC7432] Section 7.1. EVPN AD 237 sub-TLV applies to only EVPN. 239 The EVPN AD sub-TLV has the format shown in Figure 3. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Route Distinguisher | 245 | (8 octets) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Ethernet Tag ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Ethernet Segment Identifier | 250 | (10 octets) | 251 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | must be zero | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: EVPN Auto-Discovery sub-TLV format 257 4.4. EVPN IP Prefix Sub-TLV 259 The EVPN IP Prefix sub-TLV is used to identify the IP Prefix for an 260 EVI under test at a peer PE. 262 The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix 263 Route (RT-5) advertisement defined in 264 [I-D.ietf-bess-evpn-prefix-advertisement] and has the format as shown 265 in Figure 4. This TLV is included in the Echo Request sent to the 266 Peer PE by the PE that is the originator of the request. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Route Distinguisher | 272 | (8 octets) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Ethernet Tag ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Ethernet Segment Identifier | 277 | (10 octets) | 278 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | must be zero | IP Prefix Len | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 ~ IP Prefix (4 or 16 Octets) ~ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ~ GW IP Address (4 or 16 Octets) ~ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 4: EVPN IP Prefix sub-TLV format 288 The LSP Ping echo request is sent using the EVPN MPLS label(s) 289 associated with the IP Prefix route announced by a remote PE and the 290 MPLS transport label(s) to reach the remote PE. 292 5. Encapsulation of OAM Ping Packets 294 The LSP Ping Echo request IPv4/UDP packets MUST be encapsulated with 295 the Transport and EVPN Label(s) followed by the Generic Associated 296 Channel Label (GAL) [RFC5586] which is the bottom most label. The 297 GAL is followed by a Generic Associated Channel Header (G-ACH) 298 carrying IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points 299 for ipv4 and ipv6 channels are defiend in Generic Associated Channel 300 (G-ACh) Parameters by IANA. 302 6. Operations 304 6.1. Unicast Data-plane connectivity checks 306 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 307 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 308 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 309 Similarly, PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 310 00aa.00bb.00cc and with MPLS label 16002. 312 On PE3, when an operator performs a connectivity check for the B-MAC 313 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 314 request with the target FEC stack TLV containing EVPN MAC sub-TLV in 315 the Echo Request packet. The Echo Request packet is sent with the 316 {Transport Label(s) to reach PE1 + EVPN Label = 16001 + GAL} MPLS 317 label stack and IP ACH Channel header. Once the echo request packet 318 reaches PE1, PE1 will use the GAL and the IP ACH Channel header to 319 determine that the packet is IPv4 OAM Packet. The PE1 will process 320 the packet and perform checks for the EVPN MAC sub-TLV present in the 321 Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and 322 respond according to [RFC8029] processing rules. 324 BEB +-----------------+ BEB 325 || | | || 326 \/ | | \/ 327 +----+ AC1 +-----+ +-----+ +----+ 328 | CE1|------| | | PE 3|-----| CE2| 329 +----+\ | PE1 | IP/MPLS | | +----+ 330 \ +-----+ Network +-----+ 331 \ | | 332 AC2\ +-----+ | 333 \ | | | 334 \| PE2 | | 335 +-----+ | 336 /\ | | 337 || +-----------------+ 338 BEB 340 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 342 Figure 5: PBB EVPN network 344 Similarly, on PE3, when an operator performs a connectivity check for 345 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 346 LSP Ping request with the target FEC stack TLV containing EVPN MAC 347 sub-TLV in the echo request packet. The echo request packet is sent 348 with the {MPLS transport Label(s) to reach PE2 + EVPN Label = 16002 + 349 GAL} MPLS label stack and IP ACH Channel header. 351 LSP Ping operation for unicast data-plane connectivity checks in E- 352 VPN, are similar to those described above for PBB-EVPN except that 353 the checks are for C-MAC addresses instead of B-MAC addresses. 355 6.2. Inclusive Multicast Data-plane Connectivity Checks 357 6.2.1. Ingress Replication 359 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 360 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 361 set to ingress replication and downstream assigned inclusive 362 multicast MPLS label 17001. Similarly, PE2 announced an Inclusive 363 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 364 10), PMSI tunnel attribute Tunnel type set to ingress replication and 365 downstream assigned inclusive multicast MPLS label 17002. 367 Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for 368 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 369 44dd.5500. 371 When an operator at PE3 initiates a connectivity check for the 372 inclusive multicast on PE1, the operator initiates an LSP Ping 373 request with the target FEC stack TLV containing EVPN Inclusive 374 Multicast sub-TLV in the Echo Request packet. The Echo Request 375 packet is sent with the {Transport Label(s) to reach PE1 + EVPN Incl. 376 Multicast Label = 17001 + GAL} MPLS label stack and IP ACH Channel 377 header. Once the echo request packet reaches PE1, PE1 will use the 378 GAL and the IP ACH Channel header to determine that the packet is 379 IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 380 label. PE1 will process the packet and perform checks for the EVPN 381 Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as 382 described in Section 4.4 in [RFC8029] and respond according to 383 [RFC8029] processing rules. 385 An operator at PE3, may similarly also initiate an LSP Ping to PE2 386 with the target FEC stack TLV containing EVPN Inclusive Multicast 387 sub- TLV in the echo request packet. The echo request packet is sent 388 with the {transport Label(s) to reach PE2 + EVPN Incl. Multicast 389 Label = 17002 + GAL} MPLS label stack and IP ACH Channel header. 390 Once the echo request packet reaches PE2, PE2 will use the GAL and 391 the IP ACH Channel header to determine that the packet is IPv4 OAM 392 Packet. Since PE2 is not the DF for ISID 10 for the port 393 corresponding to the ESI value in the Inclusive Multicast sub-TLV in 394 the Echo Request, PE2 will reply with the a code indicating that "The 395 FEC exists on the router and the behavior is to drop the packet 396 because not DF" as described in Section 8. 398 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 399 and the associated MPLS Split Horizon Label above the GAL in the MPLS 400 label stack, may be added to emulate traffic coming from a MH site, 401 this label is used by leaf PE(s) attached to the same MH site not to 402 forward packets back to the MH site. If the behavior on a leaf PE is 403 to drop the packet because of Split Horizon filtering, the PE2 will 404 reply with the a code indicating that "The FEC exists on the router 405 and the behavior is to drop the packet because of Split Horizon 406 Filtering" as described in Section 8. 408 6.2.2. Using P2MP P-tree 410 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 411 EVPN or PBB-EVPN networks. 413 When using an inclusive P-tree arrangement, p2mp p-tree transport 414 label itself is used to identify the L2 service associated with the 415 Inclusive Multicast Route, this L2 service could be a customer 416 Bridge, or a Provider Backbone Bridge. 418 For an Inclusive P-tree arrangement, when an operator performs a 419 connectivity check for the multicast L2 service, the operator 420 initiates an LSP Ping request with the target FEC stack TLV 421 containing EVPN Inclusive Multicast sub-TLV in the echo request 422 packet. The echo request packet is sent over P2MP LSP with the {P2MP 423 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 425 When using Aggregate Inclusive P-tree, a PE announces an upstream 426 assigned MPLS label along with the P-tree ID, so both the p2mp p-tree 427 MPLS transport label and the upstream MPLS label can be used to 428 identify the L2 service. 430 For an Aggregate Inclusive P-tree arrangement, when an operator 431 performs a connectivity check for the multicast L2 service, the 432 operator initiates an LSP Ping request with the target FEC stack TLV 433 containing EVPN Inclusive Multicast sub-TLV in the echo request 434 packet. The echo request packet is sent over P2MP LSP using the IP- 435 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 436 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 437 header. 439 The Leaf PE(s) of the p2mp tree will process the packet and perform 440 checks for the EVPN Inclusive Multicast sub-TLV present in the Target 441 FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond 442 according to [RFC8029] processing rules. A PE that is not the DF for 443 the EVI on the ESI in the Inclusive Multicast sub-TLV, will reply 444 with a code indicating that "The FEC exists on the router and the 445 behavior is to drop the packet because not DF" as described in 446 Section 8. 448 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 449 and the associated MPLS Split Horizon Label above the GAL in MPLS 450 label stack, may be added to emulate traffic coming from a MH site, 451 this label is used by leaf PE(s) attached to the same MH site not to 452 forward packets back to the MH site. If the behavior on a leaf PE is 453 to drop the packet because of Split Horizon filtering, the PE2 will 454 reply with a code indicating that "FEC exists on the router and the 455 behavior is to drop the packet because of Split Horizon Filtering" as 456 described in Section 8. 458 6.2.3. Controlling Echo Responses when using P2MP P-tree 460 The procedures described in [RFC6425] for preventing congestion of 461 Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 462 single egress node (Node Address P2MP Responder Identifier TLV) can 463 be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees 464 for broadcast, multicast, and unknown unicast traffic. 466 6.3. EVPN Aliasing Data-plane connectivity check 468 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 469 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 470 discovery Route with the ESI set to CE1 system ID and MPLS label 471 19002. 473 When an operator performs at PE3 a connectivity check for the 474 aliasing aspect of the Ethernet AD route to PE1, the operator 475 initiates an LSP Ping request with the target FEC stack TLV 476 containing EVPN Ethernet AD sub-TLV in the echo request packet. The 477 echo request packet is sent with the {Transport label(s) to reach PE1 478 + EVPN Ethernet AD Label 19001 + GAL} MPLS label stack and IP ACH 479 Channel header. 481 When PE1 receives the packet it will process the packet and perform 482 checks for the EVPN Ethernet AD sub-TLV present in the Target FEC 483 Stack TLV as described in Section 4.4 in [RFC8029] and respond 484 according to [RFC8029] processing rules. 486 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 488 Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an 489 IP prefix reachable behind CE1 and MPLS label 20001. When an 490 operator on PE3 performs a connectivity check for the IP prefix on 491 PE1, the operator initiates an LSP Ping request with the target FEC 492 stack TLV containing EVPN IP Prefix sub-TLV in the echo request 493 packet. The echo request packet is sent with the {Transport label(s) 494 to reach PE1 + EVPN IP Prefix Label 20001 } MPLS label stack. 496 When PE1 receives the packet it will process the packet and perform 497 checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack 498 TLV as described in Section 4.4 in [RFC8029] and respond according to 499 [RFC8029] processing rules. 501 7. Security Considerations 503 The proposal introduced in this document does not introduce any new 504 security considerations beyond that already apply to [RFC7432], 505 [RFC7623] and [RFC6425]. 507 8. IANA Considerations 509 8.1. Sub-TLV Type 511 This document defines 4 new sub-TLV type to be included in Target FEC 512 Stack TLV (TLV Type 1, 16 and 21) [RFC8029] in Echo Request and Echo 513 Reply messages in EVPN and PBB-EVPN network. 515 IANA is requested to assign lowest 4 free values for the four sub- 516 TLVs listed below from the Standards Track" (0-16383) range, in the 517 "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry, in the "TLVs" 518 registry in the "Multiprotocol Label Switching (MPLS) Label Switched 519 Paths (LSPs) Ping Parameters" name space: 521 o EVPN MAC route sub-TLV 523 o EVPN Inclusive Multicast route sub-TLV 525 o EVPN Auto-Discovery Route sub-TLV 527 o EVPN IP Prefix Route sub-TLV 529 8.2. Proposed new Return Codes 531 [RFC8029] defines values for the Return Code field of Echo Reply. 532 This document proposes two new Return Codes, which SHOULD be included 533 in the Echo Reply message by a PE in response to Echo Request message 534 in EVPN and PBB-EVPN network. 536 IANA is requested to assign 2 lowest free values for the 2 Retuen 537 Codes listed below from the Return Codes" registry in the 538 "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 539 Ping Parameters" name space: 541 o The FEC exists on the PE and the behavior is to drop the packet 542 because of not DF. 544 o The FEC exists on the PE and the behavior is to drop the packet 545 because of Split Horizon Filtering. 547 9. Acknowledgments 549 The authors would like to thank Loa Andersson, Patrice Brissette and 550 Weiguo Hao for their valuable comments. 552 10. References 554 10.1. Normative References 556 [I-D.ietf-bess-evpn-prefix-advertisement] 557 Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. 558 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 559 bess-evpn-prefix-advertisement-11 (work in progress), May 560 2018. 562 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 563 "MPLS Generic Associated Channel", RFC 5586, 564 DOI 10.17487/RFC5586, June 2009, 565 . 567 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 568 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 569 Failures in Point-to-Multipoint MPLS - Extensions to LSP 570 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 571 . 573 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 574 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 575 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 576 2015, . 578 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 579 Henderickx, "Provider Backbone Bridging Combined with 580 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 581 September 2015, . 583 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 584 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 585 Switched (MPLS) Data-Plane Failures", RFC 8029, 586 DOI 10.17487/RFC8029, March 2017, 587 . 589 10.2. Informative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 597 Yasukawa, Ed., "Extensions to Resource Reservation 598 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 599 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 600 DOI 10.17487/RFC4875, May 2007, 601 . 603 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 604 Circuit Connectivity Verification (VCCV): A Control 605 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 606 December 2007, . 608 [RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform 609 Resource Name (URN) Namespace for the Schema for Academia 610 (SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011, 611 . 613 Authors' Addresses 615 Parag Jain (editor) 616 Cisco Systems, Inc. 617 2000 Innovation Drive 618 Kanata, ON K2K 3E8 619 Canada 621 Email: paragj@cisco.com 623 Samer Salam 624 Cisco Systems, Inc. 625 595 Burrard Street, Suite 2123 626 Vancouver, BC V7X 1J1 627 Canada 629 Email: ssalam@cisco.com 631 Ali Sajassi 632 Cisco Systems, Inc. 633 USA 635 Email: sajassi@cisco.com 636 Sami Boutros 637 Ciena 638 USA 640 Email: sboutros@ciena.com 642 Greg Mirsky 643 ZTE Corporation. 644 USA 646 Email: gregmirsky@gmail.com