idnits 2.17.1 draft-ietf-bess-evpn-lsp-ping-06.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 (January 16, 2022) is 831 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 657, but no explicit reference was found in the text == Unused Reference: 'RFC5085' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC6338' is defined on line 669, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-07 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: July 20, 2022 Cisco Systems, Inc. 6 S. Boutros 7 Ciena 8 G. Mirsky 9 Ericsson 10 January 16, 2022 12 LSP-Ping Mechanisms for EVPN and PBB-EVPN 13 draft-ietf-bess-evpn-lsp-ping-06 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 July 20, 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 . . . . . . . . . . . . . . . . . . . . . . . 16 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 as is described in 247 Section 6. 249 4.3. EVPN Ethernet Auto-Discovery Sub-TLV 251 The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the 252 EVPN Ethernet Auto-Discovery route advertisement defined in [RFC7432] 253 Section 7.1. EVPN Ethernet AD Sub-TLV applies to only EVPN. 255 The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Route Distinguisher | 261 | (8 octets) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Ethernet Tag ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Ethernet Segment Identifier | 266 | (10 octets) | 267 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | must be zero | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format 273 EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet 274 Segememnt (ES) or per-EVI. When an operator performs a connectivity 275 check for the BUM L2 service, Echo Request packet sent, may contain 276 EVPN Ethernet AD Sub-TLV to emulate traffic coming from a multi-homed 277 site. In this case, the EVPN Ethernet AD Sub-TLV is added in per-ES 278 context. When Echo Request packet is sent for the connectivity check 279 for EVPN Aliasing state, the context for the EVPN Ethernet AD Sub-TLV 280 is per-EVI. 282 Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, should be set 283 according to the context: 285 o For per-ES context, the Ethernet Tag field in the sub-TLV must be 286 set to the reserved MAX-ET value [RFC7432] 288 o For per-EVI context, the Ethernet Tag field in the sub-TLV must be 289 set to the non-reserved value 291 Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD route for a 292 given multi-homed ES, may be advertised more than once with different 293 RD values because many EVIs may be associated with the same ES and 294 Route Targets for all these EVIs may not fit in a single BGP Update 295 message. In this case, the RD value used in the EVPN Ethernet AD 296 Sub-TLV, must be the RD value received for the EVI in the per-ES EVPN 297 AD Route. 299 4.4. EVPN IP Prefix Sub-TLV 301 The EVPN IP Prefix Sub-TLV identifies the IP Prefix for an EVI under 302 test at a peer PE. 304 The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix 305 Route (RT-5) advertisement defined in [RFC9136] and has the format as 306 shown in Figure 4. This TLV is included in the Echo Request sent by 307 a PE to a EVPN peer PE. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Route Distinguisher | 313 | (8 octets) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Ethernet Tag ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Ethernet Segment Identifier | 318 | (10 octets) | 319 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | must be zero | IP Prefix Len | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ~ IP Prefix (4 or 16 Octets) ~ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 ~ GW IP Address (4 or 16 Octets) ~ 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4: EVPN IP Prefix Sub-TLV format 329 The LSP Echo Request is sent using the EVPN MPLS label(s) associated 330 with the IP Prefix route announced by a remote PE and the MPLS 331 transport label(s) to reach the remote PE. 333 5. Encapsulation of OAM Ping Packets 335 The LSP Ping Echo request IP/UDP packets MUST be encapsulated with 336 the Transport and EVPN Label(s) followed by the Generic Associated 337 Channel Label (GAL) [RFC5586] which is the bottom most label. The 338 GAL is followed by a Generic Associated Channel Header (G-ACH) 339 carrying IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points 340 for ipv4 and ipv6 channels are defiend in Generic Associated Channel 341 (G-ACh) Parameters by IANA. 343 6. Operations 345 6.1. Unicast Data-plane connectivity checks 347 Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 348 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 349 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. 350 Similarly, PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 351 00aa.00bb.00cc and with MPLS label 16002. 353 On PE3, when an operator performs a connectivity check for the B-MAC 354 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 355 request with the target FEC stack TLV containing EVPN MAC Sub-TLV in 356 the Echo Request packet. The Echo Request packet is sent with the 357 {Transport Label(s) to reach PE1, EVPN Label = 16001, GAL} MPLS label 358 stack and IP ACH Channel header. Once the Echo Request packet 359 reaches PE1, PE1 will use the GAL and the IP ACH Channel header to 360 determine that the packet is IPv4 OAM Packet. The PE1 will process 361 the packet and perform checks for the EVPN MAC Sub-TLV present in the 362 Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and 363 respond according to [RFC8029] processing rules. 365 +-----------------+ 366 | | 367 | | 368 +----+ AC1 +-----+ +-----+ +----+ 369 | CE1|------| | | PE3 |-----| CE2| 370 +----+\ | PE1 | IP/MPLS | | +----+ 371 \ +-----+ Network +-----+ 372 \ | | 373 AC2\ +-----+ | 374 \ | | | 375 \| PE2 | | 376 +-----+ | 377 | | 378 +-----------------+ 380 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 382 Figure 5: PBB-EVPN network 384 Similarly, on PE3, when an operator performs a connectivity check for 385 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 386 LSP Ping request with the target FEC stack TLV containing EVPN MAC 387 Sub-TLV in the Echo Request packet. The Echo Request packet is sent 388 with the {MPLS transport Label(s) to reach PE2, EVPN Label = 16002, 389 GAL} MPLS label stack and IP ACH Channel header. 391 LSP Ping operation for unicast data-plane connectivity checks in E- 392 VPN, are similar to those described above for PBB-EVPN except that 393 the checks are for C-MAC addresses instead of B-MAC addresses. 395 6.2. Inclusive Multicast Data-plane Connectivity Checks 397 6.2.1. Ingress Replication 399 Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 400 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type 401 set to ingress replication and downstream assigned inclusive 402 multicast MPLS label 17001. Similarly, PE2 announced an Inclusive 403 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 404 10), PMSI tunnel attribute Tunnel type set to ingress replication and 405 downstream assigned inclusive multicast MPLS label 17002. 407 Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for 408 ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 409 44dd.5500. 411 When an operator at PE3 initiates a connectivity check for the 412 inclusive multicast on PE1, the operator initiates an LSP Ping 413 request with the target FEC stack TLV containing EVPN Inclusive 414 Multicast Sub-TLV in the Echo Request packet. The Echo Request 415 packet is sent with the {Transport Label(s) to reach PE1, EVPN Incl. 416 Multicast Label = 17001, GAL} MPLS label stack and IP ACH Channel 417 header. Once the Echo Request packet reaches PE1, PE1 will use the 418 GAL and the IP ACH Channel header to determine that the packet is 419 IPv4 OAM Packet. The packet will have EVPN Inclusive multicast 420 label. PE1 will process the packet and perform checks for the EVPN 421 Inclusive Multicast Sub-TLV present in the Target FEC Stack TLV as 422 described in Section 4.4 in [RFC8029] and respond according to 423 [RFC8029] processing rules. For the success case, PE1 will reply 424 with with Return Code 3 - "Replying router is an egress for the FEC 425 at stack-depth". 427 Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with 428 the target FEC stack TLV containing EVPN Inclusive Multicast sub-TLV 429 in the Echo Request packet. The Echo Request packet is sent with the 430 {transport Label(s) to reach PE2, EVPN Incl. Multicast Label = 431 17002, GAL} MPLS label stack and IP ACH Channel header. Once the 432 Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH 433 Channel header to determine that the packet is IPv4 OAM Packet. The 434 processing on PE2 will be similar to the that on PE1 as described 435 above and for the success case, PE2 will reply with Return Code 3 - 436 "Replying router is an egress for the FEC at stack-depth" as per 437 [RFC8029]. 439 In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- 440 TLV and the associated MPLS Split Horizon Label above the GAL in the 441 MPLS label stack, may be added to emulate traffic coming from a 442 multi-homed site. The Split Horizon label is used by leaf PE(s) 443 attached to the same multi-homed site to not forward packets back to 444 the multi-homed site. If the behavior on a leaf PE is to not forward 445 the packet to the multi-homed site on the ESI identified by EVPN 446 Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will 447 reply with a Return Code indicating that "Replying router is egress 448 for the FEC at the stack depth. In addition, the BUM packets are 449 dropped on the ES corresponding to the ESI received in EVPN Ethernet 450 AD Sub-TLV because of the Split Horizon Group filtering" as described 451 in Section 8. 453 6.2.2. Using P2MP P-tree 455 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 456 EVPN or PBB-EVPN networks. 458 When using an inclusive P-tree arrangement, p2mp p-tree transport 459 label itself is used to identify the L2 service associated with the 460 Inclusive Multicast Route, this L2 service could be a customer 461 Bridge, or a Provider Backbone Bridge. 463 For an Inclusive P-tree arrangement, when an operator performs a 464 connectivity check for the multicast L2 service, the operator 465 initiates an LSP Ping request with the target FEC stack TLV 466 containing EVPN Inclusive Multicast Sub-TLV in the Echo Request 467 packet. The Echo Request packet is sent over P2MP LSP with the {P2MP 468 P-tree label, GAL} MPLS label stack and IP ACH Channel header. 470 When using Aggregate Inclusive P-tree, a PE announces an upstream 471 assigned MPLS label along with the P-tree ID, so both the p2mp p-tree 472 MPLS transport label and the upstream MPLS label can be used to 473 identify the L2 service. 475 For an Aggregate Inclusive P-tree arrangement, when an operator 476 performs a connectivity check for the multicast L2 service, the 477 operator initiates an LSP Ping request with the target FEC stack TLV 478 containing EVPN Inclusive Multicast Sub-TLV in the Echo Request 479 packet. The Echo Request packet is sent over P2MP LSP using the IP- 480 ACH Control channel with the {P2MP P-tree label, EVPN Upstream 481 assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel 482 header. 484 The Leaf PE(s) of the p2mp tree will process the packet and perform 485 checks for the EVPN Inclusive Multicast Sub-TLV present in the Target 486 FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond 487 according to [RFC8029] processing rules. For the success case, the 488 Leaf PE will reply with with Return Code 3 - "Replying router is an 489 egress for the FEC at stack-depth". 491 In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- 492 TLV and the associated MPLS Split Horizon Label above the GAL in MPLS 493 label stack, may be added to emulate traffic coming from a multi- 494 homed site. In case of p2mp p-tree, the Split Horizon Label is 495 upstream assigned [I-D.ietf-bess-mvpn-evpn-aggregation-label] and is 496 received by all the leaf PEs of the p2mp-ptree. The Split Horizon 497 label is used by leaf PE(s) attached to the same multi-homed site not 498 to forward packets back to the multi-homed site. If the behavior on 499 a leaf PE is to not forward the packet to the multi-homed site on the 500 ESI in EVPN Ethernet AD Sub-TLV because of Split Horizon filtering, 501 the PE will reply with a Return Code indicating that "Replying router 502 is egress for the FEC at the stack depth. In addition, the BUM 503 packets are dropped on the ES corresponding to the ESI received in 504 EVPN Ethernet AD Sub-TLV because of the Split Horizon Group 505 filtering" as described in Section 8. If the leaf PE does not have 506 the ESI identified in the EVPN Ethernet AD Sub-TLV, the PE can reply 507 with a Return Code indicating that "Replying router is egress for the 508 FEC at the stack depth. In addition, the BUM packets are forwarded 509 because there is no ES corresponding to the ESI received in EVPN 510 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 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 613 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 614 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 615 ietf-bess-mvpn-evpn-aggregation-label-07 (work in 616 progress), December 2021. 618 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 619 "MPLS Generic Associated Channel", RFC 5586, 620 DOI 10.17487/RFC5586, June 2009, 621 . 623 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 624 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 625 Failures in Point-to-Multipoint MPLS - Extensions to LSP 626 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 627 . 629 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 630 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 631 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 632 2015, . 634 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 635 Henderickx, "Provider Backbone Bridging Combined with 636 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 637 September 2015, . 639 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 640 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 641 Switched (MPLS) Data-Plane Failures", RFC 8029, 642 DOI 10.17487/RFC8029, March 2017, 643 . 645 [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and 646 A. Sajassi, "IP Prefix Advertisement in Ethernet VPN 647 (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, 648 . 650 10.2. Informative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 658 Yasukawa, Ed., "Extensions to Resource Reservation 659 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 660 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 661 DOI 10.17487/RFC4875, May 2007, 662 . 664 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 665 Circuit Connectivity Verification (VCCV): A Control 666 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 667 December 2007, . 669 [RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform 670 Resource Name (URN) Namespace for the Schema for Academia 671 (SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011, 672 . 674 Authors' Addresses 676 Parag Jain (editor) 677 Cisco Systems, Inc. 678 2000 Innovation Drive 679 Kanata, ON K2K 3E8 680 Canada 682 Email: paragj@cisco.com 684 Samer Salam 685 Cisco Systems, Inc. 686 595 Burrard Street, Suite 2123 687 Vancouver, BC V7X 1J1 688 Canada 690 Email: ssalam@cisco.com 692 Ali Sajassi 693 Cisco Systems, Inc. 694 USA 696 Email: sajassi@cisco.com 698 Sami Boutros 699 Ciena 700 USA 702 Email: sboutros@ciena.com 704 Greg Mirsky 705 Ericsson 706 USA 708 Email: gregimirsky@gmail.com