idnits 2.17.1 draft-jain-bess-evpn-lsp-ping-04.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 (November 21, 2016) is 2684 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 594, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC6338' is defined on line 606, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-03 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup P. Jain 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Boutros 5 Expires: May 25, 2017 VmWare, Inc. 6 S. Salam 7 Cisco Systems, Inc. 8 November 21, 2016 10 LSP-Ping Mechanisms for EVPN and PBB-EVPN 11 draft-jain-bess-evpn-lsp-ping-04 13 Abstract 15 LSP-Ping is a widely deployed Operation, Administration, and 16 Maintenance (OAM) mechanism in MPLS networks. This document 17 describes mechanisms for detecting data-plane failures using LSP Ping 18 in MPLS based EVPN and PBB-EVPN networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 25, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Proposed Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 3 58 4.1. EVPN MAC Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 59 4.2. EVPN Inclusive Multicast Sub-TLV . . . . . . . . . . . . 4 60 4.3. EVPN Auto-Discovery Sub-TLV . . . . . . . . . . . . . . . 6 61 4.4. EVPN IP Prefix Sub-TLV . . . . . . . . . . . . . . . . . 6 62 5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 7 63 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Unicast Data-plane connectivity checks . . . . . . . . . 7 65 6.2. Inclusive Multicast Data-plane Connectivity Checks . . . 9 66 6.2.1. Ingress Replication . . . . . . . . . . . . . . . . . 9 67 6.2.2. Using P2MP P-tree . . . . . . . . . . . . . . . . . . 10 68 6.2.3. Controlling Echo Responses when using P2MP P-tree . . 11 69 6.3. EVPN Aliasing Data-plane connectivity check . . . . . . . 11 70 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 10.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 [RFC7432] describes MPLS based Ethernet VPN (EVPN) technology. An 82 EVPN comprises CE(s) connected to PE(s). The PEs provide layer 2 83 EVPN among the CE(s) over the MPLS core infrastructure. In EVPN 84 networks, PEs advertise the MAC addresses learned from the locally 85 connected CE(s), along with MPLS Label, to remote PE(s) in the 86 control plane using multi-protocol BGP. EVPN enables multi-homing of 87 CE(s) connected to multiple PEs and load balancing of traffic to and 88 from multi-homed CE(s). 90 [RFC7623] describes the use of Provider Backbone Bridging [802.1ah] 91 with EVPN. PBB-EVPN maintains the C-MAC learning in data plane and 92 only advertises Provider Backbone MAC (B-MAC) addresses in control 93 plane using BGP. 95 Procedures for simple and efficient mechanisms to detect data-plane 96 failures using LSP Ping in MPLS network are well defined in 98 [RFC4379][RFC6425]. This document defines procedures to detect data- 99 plane failures using LSP Ping in MPLS networks deploying EVPN and 100 PBB-EVPN. This draft defines 3 new Sub-TLVs for Target FEC Stack TLV 101 with the purpose of identifying the FEC on the Peer PE. 103 2. Specification of Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Terminology 111 B-MAC: Backbone MAC Address 113 CE: Customer Edge Device 115 C-MAC: Customer MAC Address 117 DF: Designated Forwarder 119 ESI: Ethernet Segment Identifier 121 EVI: EVPN Instance Identifier that globally identifies the EVPN 122 Instance 124 EVPN: Ethernet Virtual Private Network 126 MPLS-OAM: MPLS Operations, Administration and Maintenance 128 P2MP: Point-to-Multipoint 130 PBB: Provider Backbone Bridge 132 PE: Provider Edge Device 134 4. Proposed Target FEC Stack Sub-TLVs 136 This document introduces four new Target FEC Stack sub-TLVs that are 137 included in the LSP-Ping Echo Request packet sent for detecting 138 faults in data-plane connectivity in EVPN and PBB-EVPN networks. 139 These Target FEC Stack sub-TLVs are described next. 141 All these TLVs contain 8 bytes EVI value which identifies the EVPN 142 instance globally. 144 4.1. EVPN MAC Sub-TLV 146 The EVPN MAC sub-TLV is used to identify the MAC for an EVI under 147 test at a peer PE. 149 The EVPN MAC sub-TLV fields are derived from the MAC advertisement 150 route defined in [RFC4379] and has the format as shown in Figure 1. 151 This TLV is included in the Echo Request sent to the Peer PE by the 152 PE that is the originator of the request. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Route Distinguisher | 158 | (8 octets) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Ethernet Segment Identifier | 161 | (10 octets) | 162 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | must be zero | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Ethernet Tag ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | MAC Address | 168 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | MAC Addr Len | IP Addr Len | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | IP Address (0, 4 or 16 Octets) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 + EVI + 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: EVPN MAC sub-TLV format 180 The LSP Ping echo request is sent using the EVPN MPLS label(s) 181 associated with the MAC route announced by a remote PE and the MPLS 182 transport label(s) to reach the remote PE. 184 4.2. EVPN Inclusive Multicast Sub-TLV 186 The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN 187 Inclusive Multicast route defined in [RFC7432]. 189 The EVPN Inclusive Multicast sub-TLV has the format as shown in 190 Figure 2. This TLV is included in the echo request sent to the EVPN 191 peer PE by the originator of request to verify the multicast 192 connectivity state on the peer PE(s) in EVPN and PBB-EVPN. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Route Distinguisher | 198 | (8 octets) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Ethernet Tag ID | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | IP Addr Len | | 203 +-+-+-+-+-+-+-+ | 204 ~ Originating Router's IP Addr ~ 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 + EVI + 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 aggregate inclusive P2MP 227 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]. EVPN AD sub-TLV applies 237 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 Segment Identifier | 248 | (10 octets) | 249 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | must be zero | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Ethernet Tag ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 + EVI + 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 3: EVPN Auto-Discovery sub-TLV format 261 4.4. EVPN IP Prefix Sub-TLV 263 The EVPN IP Prefix sub-TLV is used to identify the IP Prefix for an 264 EVI under test at a peer PE. 266 The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix 267 Route (RT-5) advertisement defined in 268 [I-D.ietf-bess-evpn-prefix-advertisement] and has the format as shown 269 in Figure 4. This TLV is included in the Echo Request sent to the 270 Peer PE by the PE that is the originator of the request. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Route Distinguisher | 276 | (8 octets) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Ethernet Segment Identifier | 279 | (10 octets) | 280 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | must be zero | IP Prefix Len | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Ethernet Tag ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 ~ IP Prefix (4 or 16 Octets) ~ 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ~ GW IP Address (4 or 16 Octets) ~ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 + EVI + 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 4: EVPN IP Prefix sub-TLV format 296 The LSP Ping echo request is sent using the EVPN MPLS label(s) 297 associated with the IP Prefix route announced by a remote PE and the 298 MPLS transport label(s) to reach the remote PE. 300 5. Encapsulation of OAM Ping Packets 302 The LSP Ping Echo request IPv4/UDP packets will be encapsulated with 303 the Transport and EVPN Label(s) followed by the Generic Associated 304 Channel Label (GAL) [RFC6426]. The GAL label will be followed by the 305 Associated Channel Header (ACH) with the Pseudowire Associated 306 Channel Type 16 bit value in the ACH set to IPv4 indicating that the 307 carried packet is an IPv4 packet respectively. 309 6. Operations 311 6.1. Unicast Data-plane connectivity checks 313 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 314 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 315 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 316 Similarly PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 317 00aa.00bb.00cc and with MPLS label 16002. 319 On PE3, when a operator performs a connectivity check for the B-MAC 320 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 321 request with the target FEC stack TLV containing EVPN MAC sub-TLV in 322 the Echo Request packet. The Echo Request packet is sent with the 323 {Transport Label(s) to reach PE1 + EVPN Label = 16001 + GAL} MPLS 324 label stack and IP ACH Channel header. Once the echo request packet 325 reaches PE1, PE1 will use the GAL label and the IP ACH Channel header 326 to determine that the packet is IPv4 OAM Packet. The PE1 will 327 process the packet and perform checks for the EVPN MAC sub-TLV 328 present in the Target FEC Stack TLV as described in Section 4.4 in 329 [RFC4379] and respond according to [RFC4379] processing rules. 331 BEB +-----------------+ BEB 332 || | | || 333 \/ | | \/ 334 +----+ AC1 +-----+ +-----+ +----+ 335 | CE1|------| | | PE 3|-----| CE2| 336 +----+\ | PE1 | IP/MPLS | | +----+ 337 \ +-----+ Network +-----+ 338 \ | | 339 AC2\ +-----+ | 340 \ | | | 341 \| PE2 | | 342 +-----+ | 343 /\ | | 344 || +-----------------+ 345 BEB 347 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 349 Figure 5: PBB EVPN network 351 Similarly, on PE3, when an operator performs a connectivity check for 352 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 353 LSP Ping request with the target FEC stack TLV containing EVPN MAC 354 sub-TLV in the echo request packet. The echo request packet is sent 355 with the {MPLS transport Label(s) to reach PE2 + EVPN Label = 16002 + 356 GAL} MPLS label stack and IP ACH Channel header. 358 LSP Ping operation for unicast data-plane connectivity checks in E- 359 VPN, are similar to those described above for PBB-EVPN except that 360 the checks are for C-MAC addresses instead of B-MAC addresses. 362 6.2. Inclusive Multicast Data-plane Connectivity Checks 364 6.2.1. Ingress Replication 366 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 367 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 368 set to ingress replication and downstream assigned inclusive 369 multicast MPLS label 17001. Similarly PE2 announced an Inclusive 370 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 371 10), PMSI tunnel attribute Tunnel type set to ingress replication and 372 downstream assigned inclusive multicast MPLS label 17002. 374 Given CE1 is dual homed to PE1 and PE2, assume that PE1 is the DF for 375 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 376 44dd.5500. 378 When an operator at PE3 initiates a connectivity check for the 379 inclusive multicast on PE1, the operator initiates an LSP Ping 380 request with the target FEC stack TLV containing EVPN Inclusive 381 Multicast sub-TLV in the Echo Request packet. The Echo Request 382 packet is sent with the {Transport Label(s) to reach PE1 + EVPN Incl. 383 Multicast Label = 17001 + GAL} MPLS label stack and IP ACH Channel 384 header. Once the echo request packet reaches PE1, PE1 will use the 385 GAL label and the IP ACH Channel header to determine that the packet 386 is IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 387 label. PE1 will process the packet and perform checks for the EVPN 388 Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as 389 described in Section 4.4 in [RFC4379] and respond according to 390 [RFC4379] processing rules. 392 Operator at PE3, may similarly also initiate an LSP Ping to PE2 with 393 the target FEC stack TLV containing EVPN Inclusive Multicast sub- TLV 394 in the echo request packet. The echo request packet is sent with the 395 {transport Label(s) to reach PE2 + EVPN Incl. Multicast Label = 396 17002 + GAL} MPLS label stack and IP ACH Channel header. Once the 397 echo request packet reaches PE2, PE2 will use the GAL label and the 398 IP ACH Channel header to determine that the packet is IPv4 OAM 399 Packet. Since PE2 is not the DF for ISID 10 for the port 400 corresponding to the ESI value in the Inclusive Multicast sub- TLV in 401 the Echo Request, PE2 will reply with special code indicating that 402 FEC exists on the router and the behavior is to drop the packet 403 because of not DF as described in Section 8. 405 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 406 and the associated MPLS Split Horizon Label above the GAL label in 407 the MPLS label stack, may be added to emulate traffic coming from a 408 MH site, this label is used by leaf PE(s) attached to the same MH 409 site not to forward packets back to the MH site. If the behavior on 410 a leaf PE is to drop the packet because of Split Horizon filtering, 411 the PE2 will reply with special code indicating that FEC exists on 412 the router and the behavior is to drop the packet because of Split 413 Horizon Filtering as described in Section 8. 415 6.2.2. Using P2MP P-tree 417 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 418 EVPN or PBB-EVPN networks. 420 When using an inclusive P-tree arrangement, p2mp p-tree transport 421 label itself is used to identify the L2 service associated with the 422 Inclusive Multicast Route, this L2 service could be a customer 423 Bridge, or a Provider Backbone Bridge. 425 For an Inclusive P-tree arrangement, when an operator performs a 426 connectivity check for the multicast L2 service, the operator 427 initiates an LSP Ping request with the target FEC stack TLV 428 containing EVPN Inclusive Multicast sub-TLV in the echo request 429 packet. The echo request packet is sent over P2MP LSP with the {P2MP 430 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 432 When using Aggregate Inclusive P-tree, a PE announces an upstream 433 assigned MPLS label along with the P-tree ID, in that case both the 434 p2mp p-tree MPLS transport label and the upstream MPLS label can be 435 used to identify the L2 service. 437 For an Aggregate Inclusive P-tree arrangement, when an operator 438 performs a connectivity check for the multicast L2 service, the 439 operator initiates an LSP Ping request with the target FEC stack TLV 440 containing EVPN Inclusive Multicast sub-TLV in the echo request 441 packet. The echo request packet is sent over P2MP LSP using the IP- 442 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 443 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 444 header. 446 The Leaf PE(s) of the p2mp tree will process the packet and perform 447 checks for the EVPN Inclusive Multicast sub-TLV present in the Target 448 FEC Stack TLV as described in Section 4.4 in [RFC4379] and respond 449 according to [RFC4379] processing rules. A PE that is not the DF for 450 the EVI on the ESI in the Inclusive Multicast sub-TLV, will reply 451 with a special code indicating that FEC exists on the router and the 452 behavior is to drop the packet because of not DF as described in 453 Section 8. 455 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 456 and the associated MPLS Split Horizon Label above the GAL Label in 457 MPLS label stack, may be added to emulate traffic coming from a MH 458 site, this label is used by leaf PE(s) attached to the same MH site 459 not to forward packets back to the MH site. If the behavior on a 460 leaf PE is to drop the packet because of Split Horizon filtering, the 461 PE2 will reply with special code indicating that FEC exists on the 462 router and the behavior is to drop the packet because of Split 463 Horizon Filtering as described in Section 8. 465 6.2.3. Controlling Echo Responses when using P2MP P-tree 467 The procedures described in [RFC6425] for preventing congestion of 468 Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 469 single egress node (Node Address P2MP Responder Identifier TLV) can 470 be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees 471 for broadcast, multicast and unknown unicast traffic. 473 6.3. EVPN Aliasing Data-plane connectivity check 475 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 476 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 477 discovery Route with the ESI set to CE1 system ID and MPLS label 478 19002. 480 When an operator performs at PE3 a connectivity check for the 481 aliasing aspect of the Ethernet AD route to PE1, the operator 482 initiates an LSP Ping request with the target FEC stack TLV 483 containing EVPN Ethernet AD sub-TLV in the echo request packet. The 484 echo request packet is sent with the {Transport label(s) to reach PE1 485 + EVPN Ethernet AD Label 19001 + GAL} MPLS label stack and IP ACH 486 Channel header. 488 When PE1 receives the packet it will process the packet and perform 489 checks for the EVPN Ethernet AD sub-TLV present in the Target FEC 490 Stack TLV as described in Section 4.4 in [RFC4379] and respond 491 according to [RFC4379] processing rules. 493 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 495 Assume PE1 announced an IP Prefix Route (RT-5) with an IP prefix 496 reachable behind CE1 and MPLS label 19001. When an operator on PE3 497 performs a connectivity check for the IP prefix on PE1, the operator 498 initiates an LSP Ping request with the target FEC stack TLV 499 containing EVPN IP Prefix sub-TLV in the echo request packet. The 500 echo request packet is sent with the {Transport label(s) to reach PE1 501 + EVPN IP Prefix Label 19001 + GAL} MPLS label stack and IP ACH 502 Channel header. 504 When PE1 receives the packet it will process the packet and perform 505 checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack 506 TLV as described in Section 4.4 in [RFC4379] and respond according to 507 [RFC4379] processing rules. 509 7. Security Considerations 511 The proposal introduced in this document does not introduce any new 512 security considerations beyond that already apply to [RFC7432], 513 [RFC7623] and [RFC6425]. 515 8. IANA Considerations 517 This document defines 3 new sub-TLV type to be included in Target FEC 518 Stack TLV (TLV Type 1) [RFC4379] in LSP Ping. 520 IANA is requested to assign a sub-TLV type value to the following 521 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label Switched 522 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- TLVs" sub- 523 registry: 525 o EVPN MAC route sub-TLV 527 o EVPN Inclusive Multicast route sub-TLV 529 o EVPN Auto-Discovery Route sub-TLV 531 o EVPN IP Prefix Route sub-TLV 533 Proposed new Return Codes 535 [RFC4379] defines values for the Return Code field of Echo Reply. 536 This document proposes two new Return Codes, which SHOULD be included 537 in the Echo Reply message by a PE in response to LSP Ping Echo 538 Request message: 540 1. The FEC exists on the PE and the behavior is to drop the packet 541 because of not DF. 543 2. The FEC exists on the PE and the behavior is to drop the packet 544 because of Split Horizon Filtering. 546 9. Acknowledgments 548 The authors would like to thank Patrice Brissette and Weiguo Hao for 549 their comments. 551 10. References 553 10.1. Normative References 555 [I-D.ietf-bess-evpn-prefix-advertisement] 556 Rabadan, J., Henderickx, W., Palislamovic, S., Isaac, A., 557 Drake, J., Lin, W., and A. Sajassi, "IP Prefix 558 Advertisement in EVPN", draft-ietf-bess-evpn-prefix- 559 advertisement-03 (work in progress), September 2016. 561 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 562 Label Switched (MPLS) Data Plane Failures", RFC 4379, 563 DOI 10.17487/RFC4379, February 2006, 564 . 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 10.2. Informative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 595 Yasukawa, Ed., "Extensions to Resource Reservation 596 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 597 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 598 DOI 10.17487/RFC4875, May 2007, 599 . 601 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 602 Circuit Connectivity Verification (VCCV): A Control 603 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 604 December 2007, . 606 [RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform 607 Resource Name (URN) Namespace for the Schema for Academia 608 (SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011, 609 . 611 Authors' Addresses 613 Parag Jain 614 Cisco Systems, Inc. 615 2000 Innovation Drive 616 Kanata, ON K2K-3E8 617 Canada 619 Email: paragj@cisco.com 621 Sami Boutros 622 VmWare, Inc. 623 USA 625 Email: sboutros@vmware.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