idnits 2.17.1 draft-ietf-bess-evpn-lsp-ping-00.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 (May 22, 2019) is 1772 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 292, but not defined == Unused Reference: 'RFC4875' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC6338' is defined on line 592, but no explicit reference was found in the text Summary: 0 errors (**), 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, Ed. 3 Internet-Draft S. Salam 4 Intended status: Standards Track A. Sajassi 5 Expires: November 23, 2019 Cisco Systems, Inc. 6 S. Boutros 7 VmWare, Inc. 8 G. Mirsky 9 ZTE Corporation. 10 May 22, 2019 12 LSP-Ping Mechanisms for EVPN and PBB-EVPN 13 draft-ietf-bess-evpn-lsp-ping-00 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 November 23, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . 3 60 4.1. EVPN MAC Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 61 4.2. EVPN Inclusive Multicast Sub-TLV . . . . . . . . . . . . 4 62 4.3. EVPN Auto-Discovery Sub-TLV . . . . . . . . . . . . . . . 5 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 . . . 8 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 4.1. EVPN MAC Sub-TLV 148 The EVPN MAC sub-TLV is used to identify the MAC for an EVI under 149 test at a peer PE. 151 The EVPN MAC sub-TLV fields are derived from the MAC/IP advertisement 152 route defined in [RFC7432] Section 7.2 and have the format as shown 153 in Figure 1. This TLV is included in the Echo Request sent to the 154 Peer PE by the PE that is the originator of the request. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Route Distinguisher | 160 | (8 octets) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Ethernet Tag ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Ethernet Segment Identifier | 165 | (10 octets) | 166 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | must be zero | MAC Addr Len | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | MAC Address | 170 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | Must be zero | IP Addr Len | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | IP Address (0, 4 or 16 Octets) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1: EVPN MAC sub-TLV format 178 The LSP Ping echo request is sent using the EVPN MPLS label(s) 179 associated with the MAC route announced by a remote PE and the MPLS 180 transport label(s) to reach the remote PE. 182 4.2. EVPN Inclusive Multicast Sub-TLV 184 The EVPN Inclusive Multicast sub-TLV fields are based on the EVPN 185 Inclusive Multicast route defined in [RFC7432] Section 7.3. 187 The EVPN Inclusive Multicast sub-TLV has the format as shown in 188 Figure 2. This TLV is included in the echo request sent to the EVPN 189 peer PE by the originator of request to verify the multicast 190 connectivity state on the peer PE(s) in EVPN and PBB-EVPN. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Route Distinguisher | 196 | (8 octets) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Ethernet Tag ID | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | IP Addr Len | | 201 +-+-+-+-+-+-+-+ | 202 ~ Originating Router's IP Addr ~ 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: EVPN Inclusive Multicast sub-TLV format 208 Broadcast, multicast, and unknown unicast traffic can be sent using 209 ingress replication or P2MP P-tree in EVPN and PBB-EVPN network. In 210 case of ingress replication, the Echo Request is sent using a label 211 stack of [Transport label, Inclusive Multicast label] to each remote 212 PE participating in EVPN or PBB-EVPN. The inclusive multicast label 213 is the downstream assigned label announced by the remote PE to which 214 the Echo Request is being sent. The Inclusive Multicast label is the 215 inner label in the MPLS label stack. 217 When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent 218 using P2MP P-tree transport label for inclusive P-tree arrangement or 219 using a label stack of [P2MP P-tree transport label, upstream 220 assigned EVPN Inclusive Multicast label] for the aggregate inclusive 221 P2MP P-tree arrangement as described in Section 6. 223 In case of EVPN, an additional, EVPN Auto-Discovery sub-TLV and ESI 224 MPLS label as the bottom label, may also be included in the Echo 225 Request as is described in Section 6. 227 4.3. EVPN Auto-Discovery Sub-TLV 229 The EVPN Auto-Discovery (AD) sub-TLV fields are based on the Ethernet 230 AD route advertisement defined in [RFC7432] Section 7.1. EVPN AD 231 sub-TLV applies to only EVPN. 233 The EVPN AD sub-TLV has the format shown in Figure 3. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Route Distinguisher | 239 | (8 octets) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Ethernet Tag ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Ethernet Segment Identifier | 244 | (10 octets) | 245 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | must be zero | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 3: EVPN Auto-Discovery sub-TLV format 251 4.4. EVPN IP Prefix Sub-TLV 253 The EVPN IP Prefix sub-TLV is used to identify the IP Prefix for an 254 EVI under test at a peer PE. 256 The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix 257 Route (RT-5) advertisement defined in 258 [I-D.ietf-bess-evpn-prefix-advertisement] and has the format as shown 259 in Figure 4. This TLV is included in the Echo Request sent to the 260 Peer PE by the PE that is the originator of the request. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Route Distinguisher | 266 | (8 octets) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Ethernet Tag ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Ethernet Segment Identifier | 271 | (10 octets) | 272 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | must be zero | IP Prefix Len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ IP Prefix (4 or 16 Octets) ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 ~ GW IP Address (4 or 16 Octets) ~ 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 4: EVPN IP Prefix sub-TLV format 282 The LSP Ping echo request is sent using the EVPN MPLS label(s) 283 associated with the IP Prefix route announced by a remote PE and the 284 MPLS transport label(s) to reach the remote PE. 286 5. Encapsulation of OAM Ping Packets 288 The LSP Ping Echo request IPv4/UDP packets are encapsulated with the 289 Transport and EVPN Label(s) followed by the Generic Associated 290 Channel Label (GAL) [RFC6426] which is the bottom most label. The 291 GAL label is followed by IPv4(0x0021) or IPv6(0x0057) Associated 292 Channel Header (ACH) [RFC4385]. 294 6. Operations 296 6.1. Unicast Data-plane connectivity checks 298 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 299 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 300 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 301 Similarly, PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 302 00aa.00bb.00cc and with MPLS label 16002. 304 On PE3, when an operator performs a connectivity check for the B-MAC 305 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 306 request with the target FEC stack TLV containing EVPN MAC sub-TLV in 307 the Echo Request packet. The Echo Request packet is sent with the 308 {Transport Label(s) to reach PE1 + EVPN Label = 16001 + GAL} MPLS 309 label stack and IP ACH Channel header. Once the echo request packet 310 reaches PE1, PE1 will use the GAL label and the IP ACH Channel header 311 to determine that the packet is IPv4 OAM Packet. The PE1 will 312 process the packet and perform checks for the EVPN MAC sub-TLV 313 present in the Target FEC Stack TLV as described in Section 4.4 in 314 [RFC8029] and respond according to [RFC8029] processing rules. 316 BEB +-----------------+ BEB 317 || | | || 318 \/ | | \/ 319 +----+ AC1 +-----+ +-----+ +----+ 320 | CE1|------| | | PE 3|-----| CE2| 321 +----+\ | PE1 | IP/MPLS | | +----+ 322 \ +-----+ Network +-----+ 323 \ | | 324 AC2\ +-----+ | 325 \ | | | 326 \| PE2 | | 327 +-----+ | 328 /\ | | 329 || +-----------------+ 330 BEB 332 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 334 Figure 5: PBB EVPN network 336 Similarly, on PE3, when an operator performs a connectivity check for 337 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 338 LSP Ping request with the target FEC stack TLV containing EVPN MAC 339 sub-TLV in the echo request packet. The echo request packet is sent 340 with the {MPLS transport Label(s) to reach PE2 + EVPN Label = 16002 + 341 GAL} MPLS label stack and IP ACH Channel header. 343 LSP Ping operation for unicast data-plane connectivity checks in E- 344 VPN, are similar to those described above for PBB-EVPN except that 345 the checks are for C-MAC addresses instead of B-MAC addresses. 347 6.2. Inclusive Multicast Data-plane Connectivity Checks 348 6.2.1. Ingress Replication 350 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 351 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 352 set to ingress replication and downstream assigned inclusive 353 multicast MPLS label 17001. Similarly, PE2 announced an Inclusive 354 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 355 10), PMSI tunnel attribute Tunnel type set to ingress replication and 356 downstream assigned inclusive multicast MPLS label 17002. 358 Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for 359 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 360 44dd.5500. 362 When an operator at PE3 initiates a connectivity check for the 363 inclusive multicast on PE1, the operator initiates an LSP Ping 364 request with the target FEC stack TLV containing EVPN Inclusive 365 Multicast sub-TLV in the Echo Request packet. The Echo Request 366 packet is sent with the {Transport Label(s) to reach PE1 + EVPN Incl. 367 Multicast Label = 17001 + GAL} MPLS label stack and IP ACH Channel 368 header. Once the echo request packet reaches PE1, PE1 will use the 369 GAL label and the IP ACH Channel header to determine that the packet 370 is IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 371 label. PE1 will process the packet and perform checks for the EVPN 372 Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as 373 described in Section 4.4 in [RFC8029] and respond according to 374 [RFC8029] processing rules. 376 An operator at PE3, may similarly also initiate an LSP Ping to PE2 377 with the target FEC stack TLV containing EVPN Inclusive Multicast 378 sub- TLV in the echo request packet. The echo request packet is sent 379 with the {transport Label(s) to reach PE2 + EVPN Incl. Multicast 380 Label = 17002 + GAL} MPLS label stack and IP ACH Channel header. 381 Once the echo request packet reaches PE2, PE2 will use the GAL label 382 and the IP ACH Channel header to determine that the packet is IPv4 383 OAM Packet. Since PE2 is not the DF for ISID 10 for the port 384 corresponding to the ESI value in the Inclusive Multicast sub- TLV in 385 the Echo Request, PE2 will reply with the special code indicating 386 that FEC exists on the router and the behavior is to drop the packet 387 because of not DF as described in Section 8. 389 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 390 and the associated MPLS Split Horizon Label above the GAL label in 391 the MPLS label stack, may be added to emulate traffic coming from a 392 MH site, this label is used by leaf PE(s) attached to the same MH 393 site not to forward packets back to the MH site. If the behavior on 394 a leaf PE is to drop the packet because of Split Horizon filtering, 395 the PE2 will reply with the special code indicating that FEC exists 396 on the router and the behavior is to drop the packet because of Split 397 Horizon Filtering as described in Section 8. 399 6.2.2. Using P2MP P-tree 401 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 402 EVPN or PBB-EVPN networks. 404 When using an inclusive P-tree arrangement, p2mp p-tree transport 405 label itself is used to identify the L2 service associated with the 406 Inclusive Multicast Route, this L2 service could be a customer 407 Bridge, or a Provider Backbone Bridge. 409 For an Inclusive P-tree arrangement, when an operator performs a 410 connectivity check for the multicast L2 service, the operator 411 initiates an LSP Ping request with the target FEC stack TLV 412 containing EVPN Inclusive Multicast sub-TLV in the echo request 413 packet. The echo request packet is sent over P2MP LSP with the {P2MP 414 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 416 When using Aggregate Inclusive P-tree, a PE announces an upstream 417 assigned MPLS label along with the P-tree ID, in that case both the 418 p2mp p-tree MPLS transport label and the upstream MPLS label can be 419 used to identify the L2 service. 421 For an Aggregate Inclusive P-tree arrangement, when an operator 422 performs a connectivity check for the multicast L2 service, the 423 operator initiates an LSP Ping request with the target FEC stack TLV 424 containing EVPN Inclusive Multicast sub-TLV in the echo request 425 packet. The echo request packet is sent over P2MP LSP using the IP- 426 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 427 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 428 header. 430 The Leaf PE(s) of the p2mp tree will process the packet and perform 431 checks for the EVPN Inclusive Multicast sub-TLV present in the Target 432 FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond 433 according to [RFC8029] processing rules. A PE that is not the DF for 434 the EVI on the ESI in the Inclusive Multicast sub-TLV, will reply 435 with a special code indicating that FEC exists on the router and the 436 behavior is to drop the packet because of not DF as described in 437 Section 8. 439 In case of EVPN, in the Echo Request packet, an Ethernet AD sub-TLV 440 and the associated MPLS Split Horizon Label above the GAL Label in 441 MPLS label stack, may be added to emulate traffic coming from a MH 442 site, this label is used by leaf PE(s) attached to the same MH site 443 not to forward packets back to the MH site. If the behavior on a 444 leaf PE is to drop the packet because of Split Horizon filtering, the 445 PE2 will reply with special code indicating that FEC exists on the 446 router and the behavior is to drop the packet because of Split 447 Horizon Filtering as described in Section 8. 449 6.2.3. Controlling Echo Responses when using P2MP P-tree 451 The procedures described in [RFC6425] for preventing congestion of 452 Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 453 single egress node (Node Address P2MP Responder Identifier TLV) can 454 be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees 455 for broadcast, multicast, and unknown unicast traffic. 457 6.3. EVPN Aliasing Data-plane connectivity check 459 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 460 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 461 discovery Route with the ESI set to CE1 system ID and MPLS label 462 19002. 464 When an operator performs at PE3 a connectivity check for the 465 aliasing aspect of the Ethernet AD route to PE1, the operator 466 initiates an LSP Ping request with the target FEC stack TLV 467 containing EVPN Ethernet AD sub-TLV in the echo request packet. The 468 echo request packet is sent with the {Transport label(s) to reach PE1 469 + EVPN Ethernet AD Label 19001 + GAL} MPLS label stack and IP ACH 470 Channel header. 472 When PE1 receives the packet it will process the packet and perform 473 checks for the EVPN Ethernet AD sub-TLV present in the Target FEC 474 Stack TLV as described in Section 4.4 in [RFC8029] and respond 475 according to [RFC8029] processing rules. 477 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 479 Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an 480 IP prefix reachable behind CE1 and MPLS label 20001. When an 481 operator on PE3 performs a connectivity check for the IP prefix on 482 PE1, the operator initiates an LSP Ping request with the target FEC 483 stack TLV containing EVPN IP Prefix sub-TLV in the echo request 484 packet. The echo request packet is sent with the {Transport label(s) 485 to reach PE1 + EVPN IP Prefix Label 20001 } MPLS label stack. 487 When PE1 receives the packet it will process the packet and perform 488 checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack 489 TLV as described in Section 4.4 in [RFC8029] and respond according to 490 [RFC8029] processing rules. 492 7. Security Considerations 494 The proposal introduced in this document does not introduce any new 495 security considerations beyond that already apply to [RFC7432], 496 [RFC7623] and [RFC6425]. 498 8. IANA Considerations 500 8.1. Sub-TLV Type 502 This document defines 4 new sub-TLV type to be included in Target FEC 503 Stack TLV (TLV Type 1) [RFC8029] in LSP Ping. 505 IANA is requested to assign a sub-TLV type value to the following 506 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label Switched 507 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- TLVs" sub- 508 registry: 510 o EVPN MAC route sub-TLV 512 o EVPN Inclusive Multicast route sub-TLV 514 o EVPN Auto-Discovery Route sub-TLV 516 o EVPN IP Prefix Route sub-TLV 518 8.2. Proposed new Return Codes 520 [RFC8029] defines values for the Return Code field of Echo Reply. 521 This document proposes two new Return Codes, which SHOULD be included 522 in the Echo Reply message by a PE in response to LSP Ping Echo 523 Request message: 525 1. The FEC exists on the PE and the behavior is to drop the packet 526 because of not DF. 528 2. The FEC exists on the PE and the behavior is to drop the packet 529 because of Split Horizon Filtering. 531 9. Acknowledgments 533 The authors would like to thank Patrice Brissette and Weiguo Hao for 534 their comments. 536 10. References 538 10.1. Normative References 540 [I-D.ietf-bess-evpn-prefix-advertisement] 541 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 542 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 543 bess-evpn-prefix-advertisement-11 (work in progress), May 544 2018. 546 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 547 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 548 Failures in Point-to-Multipoint MPLS - Extensions to LSP 549 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 550 . 552 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 553 On-Demand Connectivity Verification and Route Tracing", 554 RFC 6426, DOI 10.17487/RFC6426, November 2011, 555 . 557 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 558 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 559 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 560 2015, . 562 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 563 Henderickx, "Provider Backbone Bridging Combined with 564 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 565 September 2015, . 567 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 568 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 569 Switched (MPLS) Data-Plane Failures", RFC 8029, 570 DOI 10.17487/RFC8029, March 2017, 571 . 573 10.2. Informative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 581 Yasukawa, Ed., "Extensions to Resource Reservation 582 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 583 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 584 DOI 10.17487/RFC4875, May 2007, 585 . 587 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 588 Circuit Connectivity Verification (VCCV): A Control 589 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 590 December 2007, . 592 [RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform 593 Resource Name (URN) Namespace for the Schema for Academia 594 (SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011, 595 . 597 Authors' Addresses 599 Parag Jain (editor) 600 Cisco Systems, Inc. 601 2000 Innovation Drive 602 Kanata, ON K2K 3E8 603 Canada 605 Email: paragj@cisco.com 607 Samer Salam 608 Cisco Systems, Inc. 609 595 Burrard Street, Suite 2123 610 Vancouver, BC V7X 1J1 611 Canada 613 Email: ssalam@cisco.com 615 Ali Sajassi 616 Cisco Systems, Inc. 617 USA 619 Email: sajassi@cisco.com 620 Sami Boutros 621 VmWare, Inc. 622 USA 624 Email: sboutros@vmware.com 626 Greg Mirsky 627 ZTE Corporation. 628 USA 630 Email: gregmirsky@gmail.com>