idnits 2.17.1 draft-ietf-bess-evpn-lsp-ping-07.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 (February 10, 2022) is 804 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: August 14, 2022 Cisco Systems, Inc. 6 S. Boutros 7 Ciena 8 G. Mirsky 9 Ericsson 10 February 10, 2022 12 LSP-Ping Mechanisms for EVPN and PBB-EVPN 13 draft-ietf-bess-evpn-lsp-ping-07 15 Abstract 17 LSP Ping is a widely deployed Operation, Administration, and 18 Maintenance mechanism in MPLS networks. This document describes 19 mechanisms for detecting data-plane failures using LSP Ping in MPLS 20 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 August 14, 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 Ethernet Auto-Discovery Sub-TLV . . . . . . . . . . 6 63 4.4. EVPN IP Prefix Sub-TLV . . . . . . . . . . . . . . . . . 8 64 5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 8 65 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Unicast Data-plane connectivity checks . . . . . . . . . 9 67 6.2. Inclusive Multicast Data-plane Connectivity Checks . . . 10 68 6.2.1. Ingress Replication . . . . . . . . . . . . . . . . . 10 69 6.2.2. Using P2MP P-tree . . . . . . . . . . . . . . . . . . 11 70 6.2.3. Controlling Echo Responses when using P2MP P-tree . . 12 71 6.3. EVPN Aliasing Data-plane connectivity check . . . . . . . 12 72 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. Sub-TLV Type . . . . . . . . . . . . . . . . . . . . . . 13 76 8.2. Proposed new Return Codes . . . . . . . . . . . . . . . . 14 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 [RFC8029] 101 and [RFC6425]. The basic idea for the LSP Ping mechanism is to send 102 a MPLS Echo Request packet along the same data path as data packets 103 belonging to the same Forwarding Equivalent Classs (FEC). The Echo 104 Request packet carries the FEC being verified in the Target FEC Stack 105 TLV. Once the Echo Request packet reaches the end of the MPLS path, 106 it is sent to the control plane of the egress PE. Echo Request 107 packet contains sufficient infiormation to verify correctness of data 108 plane operations and validate data plane against the control plan. 109 Egress PE sends the results of the validation in Echo Reply packet to 110 the originating PE of the Echo Request packet. 112 This document defines procedures to detect data- plane failures using 113 LSP Ping in MPLS networks deploying EVPN and PBB-EVPN. This document 114 defines four new Sub-TLVs for Target FEC Stack TLV with the purpose 115 of identifying the FEC on the Egress PE. 117 2. Specification of Requirements 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Terminology 125 AD: Auto Discovery 127 B-MAC: Backbone MAC Address 129 BUM: Broadcast, Unknown Unicast or Multicast 131 CE: Customer Edge Device 133 C-MAC: Customer MAC Address 135 DF: Designated Forwarder 137 ES: Ethernet Segment 139 ESI: Ethernet Segment Identifier 141 EVI: EVPN Instance Identifier that globally identifies the EVPN 142 Instance 143 EVPN: Ethernet Virtual Private Network 145 FEC: Forwarding Equivalent Classs 147 GAL: G-ACh Label 149 OAM: Operations, Administration, and Maintenance 151 P2MP: Point-to-Multipoint 153 PBB: Provider Backbone Bridge 155 PE: Provider Edge Device 157 4. Proposed Target FEC Stack Sub-TLVs 159 This document introduces four new Target FEC Stack Sub-TLVs that are 160 included in the LSP-Ping Echo Request packet. The Echo Request 161 packets are used for connectivity check in data-plane in EVPN and 162 PBB-EVPN networks. The target FEC stack Sub-TLVs MAY be used to 163 validate that an indentifier for a given EVPN is programmed at the 164 target node. These Target FEC Stack Sub-TLVs are described next. 166 4.1. EVPN MAC Sub-TLV 168 The EVPN MAC Sub-TLV identifies the MAC for an EVPN Instance 169 Identifier (EVI) under test at a peer PE. 171 The EVPN MAC Sub-TLV fields are derived from the MAC/IP advertisement 172 route defined in [RFC7432] Section 7.2 and have the format as shown 173 in Figure 1. This TLV is included in the Echo Request sent by a PE 174 to a PBB-EVPN/EVPN Peer PE. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Route Distinguisher | 180 | (8 octets) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Ethernet Tag ID | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Ethernet Segment Identifier | 185 | (10 octets) | 186 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | must be zero | MAC Addr Len | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | MAC Address | 190 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | Must be zero | IP Addr Len | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | IP Address (0, 4 or 16 Octets) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: EVPN MAC Sub-TLV format 198 The LSP Echo Request is sent using the EVPN MPLS label(s) associated 199 with the MAC route announced by a remote PE and the MPLS transport 200 label(s) to reach the remote PE. 202 4.2. EVPN Inclusive Multicast Sub-TLV 204 The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN 205 Inclusive Multicast route defined in [RFC7432] Section 7.3. 207 The EVPN Inclusive Multicast Sub-TLV has the format as shown in 208 Figure 2. This TLV is included in the Echo request sent to the EVPN 209 peer PE by the originator of request to verify the multicast 210 connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Route Distinguisher | 216 | (8 octets) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Ethernet Tag ID | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | IP Addr Len | | 221 +-+-+-+-+-+-+-+ | 222 ~ Originating Router's IP Addr ~ 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 2: EVPN Inclusive Multicast Sub-TLV format 228 Broadcast, unknown unicast or multicast (BUM) traffic can be sent 229 using ingress replication or P2MP P-tree in EVPN and PBB-EVPN 230 network. In case of ingress replication, the Echo Request is sent 231 using a label stack of [Transport label, Inclusive Multicast label] 232 to each remote PE participating in EVPN or PBB-EVPN. The inclusive 233 multicast label is the downstream assigned label announced by the 234 remote PE to which the Echo Request is being sent. The Inclusive 235 Multicast label is the inner label in the MPLS label stack. 237 When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent 238 using P2MP P-tree transport label for inclusive P-tree arrangement or 239 using a label stack of [P2MP P-tree transport label, upstream 240 assigned EVPN Inclusive Multicast label] for the aggregate inclusive 241 P2MP P-tree arrangement as described in Section 6. 243 In case of EVPN, to emulate traffic coming from a multi-homed site, 244 an additional EVPN Ethernet Auto-Discovery Sub-TLV in the Target FEC 245 stack TLV and ESI Split Horizon Group MPLS label as the bottom label, 246 are also included in the Echo Request packet. When using P2MP 247 P-tree, the ESI Split Horizon Group MPLS label is upstream assigned. 248 Please see Section 6.2.2 for operations using P2MP P-trees. 250 4.3. EVPN Ethernet Auto-Discovery Sub-TLV 252 The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the 253 EVPN Ethernet Auto-Discovery route advertisement defined in [RFC7432] 254 Section 7.1. EVPN Ethernet AD Sub-TLV applies to only EVPN. 256 The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Route Distinguisher | 262 | (8 octets) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Ethernet Tag ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Ethernet Segment Identifier | 267 | (10 octets) | 268 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | must be zero | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format 274 EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet 275 Segememnt (ES) or per-EVI. When an operator performs a connectivity 276 check for the BUM L2 service, Echo Request packet sent, MAY contain 277 EVPN Ethernet AD Sub-TLV to emulate traffic coming from a multi-homed 278 site. In this case, the EVPN Ethernet AD Sub-TLV is added in per-ES 279 context. When Echo Request packet is sent for the connectivity check 280 for EVPN Aliasing state, the context for the EVPN Ethernet AD Sub-TLV 281 is per-EVI. 283 Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, MUST be set 284 according to the context: 286 o For per-ES context, the Ethernet Tag field in the sub-TLV MUST be 287 set to the reserved MAX-ET value [RFC7432] 289 o For per-EVI context, the Ethernet Tag field in the sub-TLV MUST be 290 set to the non-reserved value 292 Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD route for a 293 given multi-homed ES, may be advertised more than once with different 294 RD values because many EVIs may be associated with the same ES and 295 Route Targets for all these EVIs may not fit in a single BGP Update 296 message. In this case, the RD value used in the EVPN Ethernet AD 297 Sub-TLV, MUST be the RD value received for the EVI in the per-ES EVPN 298 AD Route. 300 4.4. EVPN IP Prefix Sub-TLV 302 The EVPN IP Prefix Sub-TLV identifies the IP Prefix for an EVI under 303 test at a peer PE. 305 The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix 306 Route (RT-5) advertisement defined in [RFC9136] and has the format as 307 shown in Figure 4. This TLV is included in the Echo Request sent by 308 a PE to a EVPN peer PE. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Route Distinguisher | 314 | (8 octets) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Ethernet Tag ID | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Ethernet Segment Identifier | 319 | (10 octets) | 320 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | must be zero | IP Prefix Len | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ IP Prefix (4 or 16 Octets) ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 ~ GW IP Address (4 or 16 Octets) ~ 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 4: EVPN IP Prefix Sub-TLV format 330 The LSP Echo Request is sent using the EVPN MPLS label(s) associated 331 with the IP Prefix route announced by a remote PE and the MPLS 332 transport label(s) to reach the remote PE. 334 5. Encapsulation of OAM Ping Packets 336 The LSP Ping Echo request IP/UDP packets MUST be encapsulated with 337 the Transport and EVPN Label(s) followed by the Generic Associated 338 Channel Label (GAL) [RFC5586] which is the bottom most label. The 339 GAL is followed by a Generic Associated Channel Header (G-ACH) 340 carrying IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points 341 for ipv4 and ipv6 channels are defiend in Generic Associated Channel 342 (G-ACh) Parameters by IANA. 344 6. Operations 346 6.1. Unicast Data-plane connectivity checks 348 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 349 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 350 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 351 Similarly, PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 352 00aa.00bb.00cc and with MPLS label 16002. 354 On PE3, when an operator performs a connectivity check for the B-MAC 355 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 356 request with the target FEC stack TLV containing EVPN MAC Sub-TLV in 357 the Echo Request packet. The Echo Request packet is sent with the 358 {Transport Label(s) to reach PE1, EVPN Label = 16001, GAL} MPLS label 359 stack and IP ACH Channel header. Once the Echo Request packet 360 reaches PE1, PE1 will use the GAL and the IP ACH Channel header to 361 determine that the packet is IPv4 OAM Packet. The PE1 will process 362 the packet and perform checks for the EVPN MAC Sub-TLV present in the 363 Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and 364 respond according to [RFC8029] processing rules. 366 +-----------------+ 367 | | 368 | | 369 +----+ AC1 +-----+ +-----+ +----+ 370 | CE1|------| | | PE3 |-----| CE2| 371 +----+\ | PE1 | IP/MPLS | | +----+ 372 \ +-----+ Network +-----+ 373 \ | | 374 AC2\ +-----+ | 375 \ | | | 376 \| PE2 | | 377 +-----+ | 378 | | 379 +-----------------+ 381 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 383 Figure 5: PBB-EVPN network 385 Similarly, on PE3, when an operator performs a connectivity check for 386 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 387 LSP Ping request with the target FEC stack TLV containing EVPN MAC 388 Sub-TLV in the Echo Request packet. The Echo Request packet is sent 389 with the {MPLS transport Label(s) to reach PE2, EVPN Label = 16002, 390 GAL} MPLS label stack and IP ACH Channel header. 392 LSP Ping operation for unicast data-plane connectivity checks in E- 393 VPN, are similar to those described above for PBB-EVPN except that 394 the checks are for C-MAC addresses instead of B-MAC addresses. 396 6.2. Inclusive Multicast Data-plane Connectivity Checks 398 6.2.1. Ingress Replication 400 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 401 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 402 set to ingress replication and downstream assigned inclusive 403 multicast MPLS label 17001. Similarly, PE2 announced an Inclusive 404 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 405 10), PMSI tunnel attribute Tunnel type set to ingress replication and 406 downstream assigned inclusive multicast MPLS label 17002. 408 Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for 409 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 410 44dd.5500. 412 When an operator at PE3 initiates a connectivity check for the 413 inclusive multicast on PE1, the operator initiates an LSP Ping 414 request with the target FEC stack TLV containing EVPN Inclusive 415 Multicast Sub-TLV in the Echo Request packet. The Echo Request 416 packet is sent with the {Transport Label(s) to reach PE1, EVPN Incl. 417 Multicast Label = 17001, GAL} MPLS label stack and IP ACH Channel 418 header. Once the Echo Request packet reaches PE1, PE1 will use the 419 GAL and the IP ACH Channel header to determine that the packet is 420 IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 421 label. PE1 will process the packet and perform checks for the EVPN 422 Inclusive Multicast Sub-TLV present in the Target FEC Stack TLV as 423 described in Section 4.4 in [RFC8029] and respond according to 424 [RFC8029] processing rules. For the success case, PE1 will reply 425 with with Return Code 3 - "Replying router is an egress for the FEC 426 at stack-depth". 428 Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with 429 the target FEC stack TLV containing EVPN Inclusive Multicast sub-TLV 430 in the Echo Request packet. The Echo Request packet is sent with the 431 {transport Label(s) to reach PE2, EVPN Incl. Multicast Label = 432 17002, GAL} MPLS label stack and IP ACH Channel header. Once the 433 Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH 434 Channel header to determine that the packet is IPv4 OAM Packet. The 435 processing on PE2 will be similar to the that on PE1 as described 436 above and for the success case, PE2 will reply with Return Code 3 - 437 "Replying router is an egress for the FEC at stack-depth" as per 438 [RFC8029]. 440 In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- 441 TLV and the associated MPLS Split Horizon Label above the GAL in the 442 MPLS label stack, may be added to emulate traffic coming from a 443 multi-homed site. The Split Horizon label is used by leaf PE(s) 444 attached to the same multi-homed site to not forward packets back to 445 the multi-homed site. If the behavior on a leaf PE is to not forward 446 the packet to the multi-homed site on the ESI identified by EVPN 447 Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will 448 reply with a Return Code indicating that "Replying router is egress 449 for the FEC at the stack depth. In addition, the BUM packets are 450 dropped on the ES corresponding to the ESI received in EVPN Ethernet 451 AD Sub-TLV because of the Split Horizon Group filtering" as described 452 in Section 8. 454 6.2.2. Using P2MP P-tree 456 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 457 EVPN or PBB-EVPN networks. 459 When using an inclusive P-tree arrangement, p2mp p-tree transport 460 label itself is used to identify the L2 service associated with the 461 Inclusive Multicast Route, this L2 service could be a customer 462 Bridge, or a Provider Backbone Bridge. 464 For an Inclusive P-tree arrangement, when an operator performs a 465 connectivity check for the multicast L2 service, the operator 466 initiates an LSP Ping request with the target FEC stack TLV 467 containing EVPN Inclusive Multicast Sub-TLV in the Echo Request 468 packet. The Echo Request packet is sent over P2MP LSP with the {P2MP 469 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 471 When using Aggregate Inclusive P-tree, a PE announces an upstream 472 assigned MPLS label along with the P-tree ID, so both the p2mp p-tree 473 MPLS transport label and the upstream MPLS label can be used to 474 identify the L2 service. 476 For an Aggregate Inclusive P-tree arrangement, when an operator 477 performs a connectivity check for the multicast L2 service, the 478 operator initiates an LSP Ping request with the target FEC stack TLV 479 containing EVPN Inclusive Multicast Sub-TLV in the Echo Request 480 packet. The Echo Request packet is sent over P2MP LSP using the IP- 481 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 482 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 483 header. 485 The Leaf PE(s) of the p2mp tree will process the packet and perform 486 checks for the EVPN Inclusive Multicast Sub-TLV present in the Target 487 FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond 488 according to [RFC8029] processing rules. For the success case, the 489 Leaf PE will reply with with Return Code 3 - "Replying router is an 490 egress for the FEC at stack-depth". 492 In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- 493 TLV and the associated MPLS Split Horizon Label above the GAL in MPLS 494 label stack, may be added to emulate traffic coming from a multi- 495 homed site. In case of p2mp p-tree, the Split Horizon Label is 496 upstream assigned and is received by all the leaf PEs of the p2mp- 497 ptree. The Split Horizon label is used by leaf PE(s) attached to the 498 same multi-homed site not to forward packets back to the multi-homed 499 site. If the behavior on a leaf PE is to not forward the packet to 500 the multi-homed site on the ESI in EVPN Ethernet AD Sub-TLV because 501 of Split Horizon filtering, the PE will reply with a Return Code 502 indicating that "Replying router is egress for the FEC at the stack 503 depth. In addition, the BUM packets are dropped on the ES 504 corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because 505 of the Split Horizon Group filtering" as described in Section 8. If 506 the leaf PE does not have the ESI identified in the EVPN Ethernet AD 507 Sub-TLV, the PE can reply with a Return Code indicating that 508 "Replying router is egress for the FEC at the stack depth. In 509 addition, the BUM packets are forwarded because there is no ES 510 corresponding to the ESI received in EVPN Ethernet AD Sub-TLV". 512 6.2.3. Controlling Echo Responses when using P2MP P-tree 514 The procedures described in [RFC6425] for preventing congestion of 515 Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a 516 single egress node (Node Address P2MP Responder Identifier TLV) can 517 be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees 518 for broadcast, multicast, and unknown unicast traffic. 520 6.3. EVPN Aliasing Data-plane connectivity check 522 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 523 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 524 discovery Route with the ESI set to CE1 system ID and MPLS label 525 19002. 527 When an operator performs at PE3 a connectivity check for the 528 aliasing aspect of the EVPN Ethernet AD route to PE1, the operator 529 initiates an LSP Ping request with the target FEC stack TLV 530 containing EVPN Ethernet AD Sub-TLV in the Echo Request packet. The 531 Echo Request packet is sent with the {Transport label(s) to reach 532 PE1, EVPN Ethernet AD Label 19001, GAL} MPLS label stack and IP ACH 533 Channel header. 535 When PE1 receives the packet it will process the packet and perform 536 checks for the EVPN Ethernet AD Sub-TLV present in the Target FEC 537 Stack TLV as described in Section 4.4 in [RFC8029] and respond 538 according to [RFC8029] processing rules. 540 6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 542 Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an 543 IP prefix reachable behind CE1 and MPLS label 20001. When an 544 operator on PE3 performs a connectivity check for the IP prefix on 545 PE1, the operator initiates an LSP Ping request with the target FEC 546 stack TLV containing EVPN IP Prefix Sub-TLV in the Echo Request 547 packet. The Echo Request packet is sent with the {Transport label(s) 548 to reach PE1, EVPN IP Prefix Label 20001 } MPLS label stack. 550 When PE1 receives the packet it will process the packet and perform 551 checks for the EVPN IP Prefix Sub-TLV present in the Target FEC Stack 552 TLV as described in Section 4.4 in [RFC8029] and respond according to 553 [RFC8029] processing rules. 555 7. Security Considerations 557 The proposal introduced in this document does not introduce any new 558 security considerations beyond that already apply to [RFC7432], 559 [RFC7623] and [RFC6425]. 561 8. IANA Considerations 563 8.1. Sub-TLV Type 565 This document defines four new Sub-TLV type to be included in Target 566 FEC Stack TLV (TLV Type 1, 16 and 21) [RFC8029] in Echo Request and 567 Echo Reply messages in EVPN and PBB-EVPN network. 569 IANA is requested to assign lowest 4 free values for the four Sub- 570 TLVs listed below from the Standards Track" (0-16383) range, in the 571 "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry, in the "TLVs" 572 registry in the "Multiprotocol Label Switching (MPLS) Label Switched 573 Paths (LSPs) Ping Parameters" name space: 575 o EVPN MAC route Sub-TLV 577 o EVPN Inclusive Multicast route Sub-TLV 579 o EVPN Auto-Discovery Route Sub-TLV 580 o EVPN IP Prefix Route Sub-TLV 582 8.2. Proposed new Return Codes 584 [RFC8029] defines values for the Return Code field of Echo Reply. 585 This document proposes two new Return Codes, which SHOULD be included 586 in the Echo Reply message by a PE in response to Echo Request message 587 in EVPN and PBB-EVPN network. 589 IANA is requested to assign 2 lowest free values for the 2 Retuen 590 Codes listed below from the Return Codes" registry in the 591 "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 592 Ping Parameters" name space: 594 o Replying router is egress for the FEC at the stack depth. In 595 addition, the BUM packets are dropped on the ES corresponding to 596 the ESI received in EVPN Ethernet AD Sub-TLV because of the Split 597 Horizon Group filtering. 599 o Replying router is egress for the FEC at the stack depth. In 600 addition, the BUM packets are forwarded because there is no ES 601 corresponding to the ESI received in EVPN Ethernet AD Sub-TLV. 603 9. Acknowledgments 605 The authors would like to thank Loa Andersson, Alexander Vainshtein, 606 Patrice Brissette and Weiguo Hao for their valuable comments. 608 10. References 610 10.1. Normative References 612 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 613 "MPLS Generic Associated Channel", RFC 5586, 614 DOI 10.17487/RFC5586, June 2009, 615 . 617 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 618 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 619 Failures in Point-to-Multipoint MPLS - Extensions to LSP 620 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 621 . 623 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 624 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 625 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 626 2015, . 628 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 629 Henderickx, "Provider Backbone Bridging Combined with 630 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 631 September 2015, . 633 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 634 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 635 Switched (MPLS) Data-Plane Failures", RFC 8029, 636 DOI 10.17487/RFC8029, March 2017, 637 . 639 [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and 640 A. Sajassi, "IP Prefix Advertisement in Ethernet VPN 641 (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, 642 . 644 10.2. Informative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, 648 DOI 10.17487/RFC2119, March 1997, 649 . 651 Authors' Addresses 653 Parag Jain (editor) 654 Cisco Systems, Inc. 655 2000 Innovation Drive 656 Kanata, ON K2K 3E8 657 Canada 659 Email: paragj@cisco.com 661 Samer Salam 662 Cisco Systems, Inc. 663 595 Burrard Street, Suite 2123 664 Vancouver, BC V7X 1J1 665 Canada 667 Email: ssalam@cisco.com 669 Ali Sajassi 670 Cisco Systems, Inc. 671 USA 673 Email: sajassi@cisco.com 674 Sami Boutros 675 Ciena 676 USA 678 Email: sboutros@ciena.com 680 Greg Mirsky 681 Ericsson 682 USA 684 Email: gregimirsky@gmail.com