Cisco

Canada paragj@cisco.com

Cisco

United States of America sajassi@cisco.com

Cisco

Canada ssalam@cisco.com

Ciena

United States of America sboutros@ciena.com

Ericsson

United States of America gregimirsky@gmail.com

rtg bess EVPN LSP Ping MPLS OAM Label Switched Path (LSP) Ping is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) networks.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Specification of Requirements
• .  Terminology
• .  Target FEC Stack Sub-TLVs
  • .  EVPN MAC/IP Sub-TLV
  • .  EVPN Inclusive Multicast Sub-TLV
  • .  EVPN Ethernet Auto-Discovery (A-D) Sub-TLV
    • .  Ethernet Tag Value
    • .  Per-ES EVPN Auto-Discovery Route with Different RDs
    • .  EVPN VPWS
  • .  EVPN IP Prefix Sub-TLV
• .  Encapsulation of OAM Ping Packets
• .  Operations
  • .  Unicast Data Plane Connectivity Checks
  • .  Inclusive Multicast Data Plane Connectivity Checks
    • .  Ingress Replication
    • .  Using P2MP P-Tree
    • .  Controlling Echo Responses When Using P2MP P-Tree
  • .  EVPN Aliasing Data Plane Connectivity Check
  • .  EVPN IP Prefix (RT-5) Data Plane Connectivity Check
• .  Security Considerations
• .  IANA Considerations
  • .  Sub-TLV Type
  • .  New Return Codes
• .  Normative References
• Acknowledgments
• Authors' Addresses

Introduction describes MPLS-based EVPN technology. An EVPN comprises one or more Customer Edge devices (CEs) connected to one or more Provider Edge devices (PEs). The PEs provide Layer 2 (L2) EVPN among the CE(s) over the MPLS core infrastructure. In EVPN networks, the PEs advertise the Media Access Control (MAC) addresses learned from the locally connected CE(s), along with the MPLS label, to remote PE(s) in the control plane using multiprotocol BGP . EVPN enables multihoming of CE(s) connected to multiple PEs and load balancing of traffic to and from multihomed CE(s). describes the use of Provider Backbone Bridging EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in the data plane and only advertises Backbone MAC (B-MAC) addresses in a control plane using BGP. Procedures for simple and efficient mechanisms to detect data plane failures using LSP Ping in MPLS networks are well defined in and . The basic idea for the LSP Ping mechanism is to send an MPLS Echo Request packet along the same data path as data packets belonging to the same Forwarding Equivalent Class (FEC). The Echo Request packet carries the FEC being verified in the Target FEC Stack TLV . Once the Echo Request packet reaches the end of the MPLS path, it is sent to the control plane of the egress PE. The Echo Request packet contains sufficient information to verify the correctness of data plane operations and validate the data plane against the control plane. The egress PE sends the results of the validation in an Echo Reply packet to the originating PE of the Echo Request packet. This document defines procedures to detect data plane failures using LSP Ping in MPLS networks deploying EVPN and PBB-EVPN. This document defines four new sub-TLVs for the Target FEC Stack TLV with the purpose of identifying the FEC on the egress PE.

Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

A-D:

Auto-Discovery

B-MAC:

Backbone MAC

BUM:

Broadcast, Unknown Unicast, and Multicast

CE:

Customer Edge device

C-MAC:

Customer MAC

DF:

Designated Forwarder

ES:

Ethernet Segment

ESI:

Ethernet Segment Identifier

EVI:

EVPN Instance Identifier that globally identifies the EVPN Instance

EVPN:

Ethernet Virtual Private Network

FEC:

Forwarding Equivalent Class

G-ACh:

Generic Associated Channel

GAL:

G-ACh Label

MAC-VRF:

A Virtual Routing and Forwarding table for MAC addresses on a PE

ND:

Neighbor Discovery

OAM:

Operations, Administration, and Maintenance

P2MP:

Point-to-Multipoint

PBB-EVPN:

Provider Backbone Bridging EVPN

PE:

Provider Edge device

VPWS:

Virtual Private Wire Service

Target FEC Stack Sub-TLVs This document introduces four new Target FEC Stack sub-TLVs that are included in the MPLS Echo Request packet. The Echo Request packets are used for connectivity checks in the data plane in EVPN and PBB-EVPN networks. The Target FEC Stack sub-TLVs MAY be used to validate that an identifier for a given EVPN is programmed at the target node.

EVPN MAC/IP Sub-TLV The EVPN MAC/IP sub-TLV identifies the target MAC, MAC/IP binding for ARP/ND, or IP address for an EVI under test at an egress PE. This sub-TLV is included in the Echo Request sent by an EVPN/PBB-EVPN PE to a peer PE. The fields of the EVPN MAC/IP sub-TLV are derived from the MAC/IP Advertisement route defined in and have the format shown in . The fields of the EVPN MAC/IP sub-TLV should be set according to the following, which is consistent with and :

• The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle service . For PBB-EVPN, the value of this field is always 0 as per .
• The Ethernet Segment Identifier field is a 10-octet field. For EVPN, it is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN, the Ethernet Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load balancing) or to MAX-ESI (for multihomed segments with per-flow load balancing) as described in .
• The MAC Addr Len field specifies the MAC length in bits. Only 48-bit MAC addresses are supported as this document follows the MAC address length supported by .
• The MAC Address field is set to the 6-octet MAC address.
• The IP Address field is optional. When the IP Address field is not present, the IP Addr Len field is set to 0. When the IP Address field is present, the IP Addr Len field is in bits and is set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
• The Must Be Zero fields are set to 0. The receiving PE should ignore the Must Be Zero fields.

EVPN MAC/IP Sub-TLV Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Tag ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Segment Identifier | | (10 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Must Be Zero | MAC Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | + (6 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Must Be Zero | IP Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (0, 4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) associated with the MAC/IP Advertisement route announced by the egress PE and the MPLS transport label(s) to reach the egress PE. In EVPN, the MAC/IP Advertisement route has multiple uses and is used for the following cases:

• This route with only a MAC address and MPLS Label1 is used for populating MAC-VRF and performing MAC forwarding.
• This route with MAC and IP addresses and only MPLS Label1 is used for populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for performing MAC forwarding.
• This route with MAC and IP addresses and both MPLS Label1 and Label2 is used for populating MAC-VRF and IP-VRF tables as well as for both MAC and IP forwarding in the case of symmetric Integrated Routing and Bridging (IRB).

When an MPLS Echo Request is sent by an ingress PE, the contents of the Echo Request and the egress PE mode of operation (i.e., IRB mode or L2 mode) along with EVPN MPLS label of the packet determine which of the three cases above this Echo Request is for. When the egress PE receives the EVPN MAC/IP sub-TLV containing only the MAC address, the egress PE validates the MAC state and forwarding. When the egress PE receives the EVPN MAC/IP sub-TLV containing both MAC and IP addresses and if the EVPN label points to a MAC-VRF, then the egress PE validates the MAC state and forwarding. If the egress PE is not configured in symmetric IRB mode, it also validates ARP/ND state. However, if the EVPN label points to an IP-VRF, then the egress PE validates IP state and forwarding. Any other combinations (e.g., the egress PE receiving the EVPN MAC/IP sub-TLV containing only the MAC address but with the EVPN label pointing to an IP-VRF) should be considered invalid, and the egress PE should send an Echo Reply with the appropriate Return Code to the ingress PE.

EVPN Inclusive Multicast Sub-TLV The fields of the EVPN Inclusive Multicast sub-TLV are based on the EVPN Inclusive Multicast Tag route defined in . This TLV is included in the Echo Request sent to the EVPN peer PE by the originator of the request to verify the multicast connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks. The EVPN Inclusive Multicast sub-TLV has the format shown in . The fields of this sub-TLV should be set according to the following, which is consistent with and :

• The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE.
• For EVPN, the Ethernet Tag ID field can be set to 0 or a valid VLAN ID for EVPN VLAN-aware bundle service . For PBB-EVPN, the value of this field is set to the Service Instance Identifier (I-SID) value as per .
• The IP Addr Len field specifies the length of the Originating Router's IP Addr field in bits and is set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
• The Originating Router's IP Addr field is set to the IPv4 or IPv6 address of the peer PE.

EVPN Inclusive Multicast Sub-TLV Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Tag ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Addr Len | | +-+-+-+-+-+-+-+ | ~ Originating Router's IP Addr ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BUM traffic can be sent using ingress replication or P2MP P-tree in EVPN and PBB-EVPN networks. When using ingress replication, the Echo Request is sent using a label stack of [Transport label, Inclusive Multicast label] to each egress PE participating in EVPN or PBB-EVPN. The Inclusive Multicast label is the downstream-assigned label announced by the egress PE to which the Echo Request is being sent. The Inclusive Multicast label is the inner label in the MPLS label stack. When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent using a P2MP P-tree transport label for the Inclusive P-tree arrangement or using a label stack of [P2MP P-tree Transport label, upstream-assigned EVPN Inclusive Multicast label] for the Aggregate Inclusive P2MP P-tree arrangement as described in . In an EVPN network, to emulate traffic coming from a multihomed site, an additional EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV and an ESI Split Horizon Group MPLS label as the bottom label are also included in the Echo Request packet. When using P2MP P-tree, the ESI Split Horizon Group MPLS label is upstream assigned. Please see for operations using P2MP P-trees.

EVPN Ethernet Auto-Discovery (A-D) Sub-TLV The fields in the EVPN Ethernet A-D sub-TLV are based on the EVPN Ethernet A-D route advertisement defined in . The EVPN Ethernet A-D sub-TLV only applies to EVPN. The EVPN Ethernet A-D sub-TLV has the format shown in . The fields of this sub-TLV should be set according to the following, which is consistent with :

• The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE. Please see for the case when a per-ES A-D route is announced with different RDs.
• The Ethernet Tag ID field can be 0, MAX-ET, or a valid VLAN ID as described in .
• The Ethernet Segment Identifier field is a 10-octet field and is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES.
• The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field.

EVPN Ethernet A-D Sub-TLV Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Tag ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Segment Identifier | | (10 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ethernet Tag Value The EVPN Ethernet A-D sub-TLV can be sent in the context of per-ES or per-EVI. When an operator performs a connectivity check for the BUM L2 service, an Echo Request packet is sent and MAY contain the EVPN Ethernet A-D sub-TLV to emulate traffic coming from a multihomed site. In this case, the EVPN Ethernet A-D sub-TLV is added in the per-ES context. When an Echo Request packet is sent for the connectivity check for EVPN Aliasing state, the context for the EVPN Ethernet A-D sub-TLV is per-EVI. The Ethernet Tag field value in the EVPN Ethernet A-D sub-TLV MUST be set according to the context:

• For the per-ES context, the Ethernet Tag field in the sub-TLV MUST be set to the reserved MAX-ET value .
• For the per-EVI context, the Ethernet Tag field in the sub-TLV MUST be set to the non-reserved value.

Per-ES EVPN Auto-Discovery Route with Different RDs specifies that a per-ES EVPN A-D route for a given multihomed ES may be advertised more than once with different RD values because many EVIs may be associated with the same ES and Route Targets for all these EVIs may not fit in a single BGP Update message. In this case, the RD value used in the EVPN Ethernet A-D sub-TLV MUST be the RD value received for the EVI in the per-ES EVPN A-D route.

EVPN VPWS LSP Ping can also be used to detect data plane failures for the EVPN VPWS described in . The Echo Request packet carries the EVPN Ethernet A-D sub-TLV with fields populated from the EVPN Ethernet A-D per-EVI route announced by the egress PE for the EVPN VPWS under test. The Echo Request is sent by the ingress PE using the EVPN MPLS label associated with the EVPN Ethernet A-D route announced by the egress PE and the MPLS transport label(s) to reach the egress PE. The egress PE processes the Echo Request packet and performs checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC Stack TLV as described in and responds according to processing rules in . The egress PE can identify that the Echo Request is for the EVPN VPWS instance as EVI (identified by the RD) for EVPN VPWS is different from EVI assigned for EVPN. The egress PE will use the information from the EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV and validate the VLAN state for the EVPN VPWS under test. For the success case, the egress PE will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>").

EVPN IP Prefix Sub-TLV The EVPN IP Prefix sub-TLV identifies the IP prefix for an EVI under test at a peer PE. The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix route (RT-5) advertisement defined in . This sub-TLV only applies to EVPN. The EVPN IP Prefix sub-TLV has the format shown in . The total length (not shown) of this sub-TLV MUST be either 32 bytes (if IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carried). The IP prefix and gateway IP address MUST be from the same IP address family, as described in . The fields of the EVPN IP Prefix sub-TLV should be set according to the following, which is consistent with :

• The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the IP-VRF on the peer PE.
• The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle service .
• The Ethernet Segment Identifier field is a 10-octet field and is set to a valid ESI ID if the ESI is used as an Overlay Index as per . Otherwise, the Ethernet Segment Identifier field is set to 0.
• The IP Prefix Len field specifies the number of bits in the IP Prefix field. It is set to a value between 0 and 32 for IPv4 or between 0 to 128 for IPv6.
• The IP Prefix field is set to a 4-octet IPv4 address (with trailing 0 bits to make 32 bits in all) or a 16-octet IPv6 address (with trailing 0 bits to make 128 bits in all). The address family of this field is inferred from the sub-TLV length field, as discussed above.
• The Gateway (GW) IP Address field is set to a 4-octet IPv4 address or a 16-octet IPv6 address if it's used as an Overlay Index for the IP prefixes. If the GW IP Address is not being used, it must be set to 0 as described in . The address family of this field is inferred from the sub-TLV length field, as discussed above.
• The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field.

EVPN IP Prefix Sub-TLV Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Tag ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Segment Identifier | | (10 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Must Be Zero | IP Prefix Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Prefix (4 or 16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ GW IP Address (4 or 16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) associated with the IP Prefix route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.

Encapsulation of OAM Ping Packets The MPLS Echo Request IP/UDP packets MUST be encapsulated with the Transport and EVPN label(s) followed by the GAL , which is the bottommost label. The GAL is followed by a G-ACh header carrying the IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 and IPv6 channels are defined in the "Generic Associated Channel (G-ACh) Parameters" IANA registry.

Operations

Unicast Data Plane Connectivity Checks is an example of a PBB-EVPN network. CE1 is dual-homed to PE1 and PE2. Assume that PE1 announced a MAC route with RD 192.0.2.1:00 and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. Similarly, PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16002. On PE3, when an operator performs a connectivity check for the B-MAC address 00-AA-00-BB-00-CC on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN MAC/IP sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN label = 16001, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE1, PE1 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The PE1 will process the packet and perform checks for the EVPN MAC/IP sub-TLV present in the Target FEC Stack TLV as described in and respond according to the processing rules in .

PBB-EVPN Network +-----------------+ | | | | +----+ AC1 +-----+ +-----+ +----+ | CE1|------| | | PE3 |-----| CE2| +----+\ | PE1 | IP/MPLS | | +----+ \ +-----+ Network +-----+ \ | | AC2\ +-----+ | \ | | | \| PE2 | | +-----+ | | | +-----------------+ <-802.1Q-> <------PBB over MPLS------> <-802.1Q->

Similarly, on PE3, when an operator performs a connectivity check for the B-MAC address 00-AA-00-BB-00-CC on PE2, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN MAC/IP sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {MPLS Transport label(s) to reach PE2, EVPN label = 16002, GAL} MPLS label stack and IP ACH Channel header. LSP Ping operations for unicast data plane connectivity checks in EVPN are similar to those described above for PBB-EVPN, except that the checks are for C-MAC addresses instead of B-MAC addresses. In EVPN networks, an operator can also perform a MAC state test using an aliasing label for the MAC to verify the MAC state on the egress multihoming PE that did not learn the MAC from the multihomed CE on a local ESI but has announced Ethernet A-D per-EVI and per-ESI routes for the ESI. This is due to the fact that MAC state on multihoming PEs that did not learn the MAC locally get created from EVPN MAC/IP route advertisement from the multihoming PE that has learned the CE's MAC address locally.

Inclusive Multicast Data Plane Connectivity Checks

Ingress Replication Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 192.0.2.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type set to ingress replication, and downstream-assigned Inclusive Multicast MPLS label 17001. Similarly, PE2 announced an Inclusive Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type set to ingress replication, and downstream-assigned Inclusive Multicast MPLS label 17002. Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 44dd.5500. When an operator at PE3 initiates a connectivity check for the Inclusive Multicast on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN Inclusive Multicast label = 17001, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE1, PE1 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The packet will have the EVPN Inclusive Multicast label. PE1 will process the packet and perform checks for the EVPN Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as described in and respond according to the processing rules in . For the success case, PE1 will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>"). Similarly, an operator at PE3 may initiate an LSP Ping to PE2 with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE2, EVPN Inclusive Multicast label = 17002, GAL} MPLS label stack and IP ACH Channel header. Once the Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH Channel header to determine if the packet is an IPv4 or IPv6 OAM packet. The processing on PE2 will be similar to that on PE1 as described above. For the success case, PE2 will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") as per . In an Echo Request packet for EVPN, a combination of an EVPN Ethernet A-D sub-TLV and the associated MPLS Split Horizon label, immediately preceding the GAL in the MPLS label stack, may be used to emulate traffic coming from a multihomed site. The Split Horizon label is used by leaf PE(s) attached to the same multihomed site to prevent forwarding of packets back to the multihomed site. If the behavior on a leaf PE is to not forward the packet to the multihomed site on the ESI identified by the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, the PE will reply with Return Code 37 (see ) and drop the BUM packets on the ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV because of the Split Horizon Group filtering.

Using P2MP P-Tree Both Inclusive P-tree and Aggregate Inclusive P-tree can be used in EVPN or PBB-EVPN networks. When using an Inclusive P-tree arrangement, the P2MP P-tree transport label itself is used to identify the L2 service associated with the Inclusive Multicast route. This L2 service could be a Customer Bridge or a Provider Backbone Bridge. For an Inclusive P-tree arrangement, when an operator performs a connectivity check for the multicast L2 service, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent over P2MP LSP with the {P2MP P-tree Transport label, GAL} MPLS label stack and IP ACH Channel header. When using an Aggregate Inclusive P-tree arrangement, a PE announces an upstream-assigned MPLS label along with the P-tree ID, so both the P2MP P-tree MPLS transport label and the upstream MPLS label can be used to identify the L2 service. For an Aggregate Inclusive P-tree arrangement, when an operator performs a connectivity check for the multicast L2 service, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request packet is sent over P2MP LSP using the IP-ACH Control channel with the {P2MP P-tree Transport label, EVPN upstream-assigned Multicast label, GAL} MPLS label stack and IP ACH Channel header. The leaf PE(s) of the P2MP P-tree will process the packet and perform checks for the EVPN Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as described in and respond according to the processing rules in . For the success case, the leaf PE will reply with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>"). In an Echo Request packet for EVPN, a combination of an EVPN Ethernet A-D sub-TLV and the associated MPLS Split Horizon label, immediately preceding the GAL in the MPLS label stack, may be used to emulate traffic coming from a multihomed site. When using P2MP P-tree, the Split Horizon label is upstream assigned and is received by all the leaf PEs of the P2MP P-tree. The Split Horizon label is used by leaf PE(s) attached to the same multihomed site so that packets will not be forwarded back to the multihomed site. If the behavior on a leaf PE is to not forward the packet to the multihomed site on the ESI in the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, the PE will reply with Return Code 37 (see ) and drop the BUM packets on the ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV because of the Split Horizon Group filtering. If the leaf PE does not have the ESI identified in the EVPN Ethernet A-D sub-TLV, the PE MAY reply with Return Code 38 (see ), and the BUM packets are forwarded because there is no ES corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV.

Controlling Echo Responses When Using P2MP P-Tree The procedures described in for preventing congestion of Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a single egress node (P2MP Responder Identifier TLV with either the IPv4 Node Address P2MP Responder sub-TLV or the IPv6 Node Address P2MP Responder sub-TLV) can be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees for BUM traffic.

EVPN Aliasing Data Plane Connectivity Check Assume PE1 announced an Ethernet A-D per-EVI route with the ESI set to CE1 system ID and MPLS label 19001. Additionally, assume PE2 announced an Ethernet A-D per-EVI route with the ESI set to CE1 system ID and MPLS label 19002. At PE3, when an operator performs a connectivity check for the aliasing aspect of the EVPN Ethernet A-D route on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN Ethernet A-D sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN Ethernet A-D label 19001, GAL} MPLS label stack and IP ACH Channel header. When PE1 receives the packet, it will process the packet and perform checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC Stack TLV as described in and respond according to the processing rules in .

EVPN IP Prefix (RT-5) Data Plane Connectivity Check Assume PE1 in announced an IP Prefix route (RT-5) with an IP prefix reachable behind CE1 and MPLS label 20001. When an operator on PE3 performs a connectivity check for the IP prefix on PE1, the operator initiates an LSP Ping request with the Target FEC Stack TLV containing the EVPN IP Prefix sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN IP Prefix label 20001 } MPLS label stack. When PE1 receives the packet, it will process the packet and perform checks for the EVPN IP Prefix sub-TLV present in the Target FEC Stack TLV as described in and respond according to the processing rules in .

Security Considerations This document does not introduce any new security considerations beyond those that apply in , , and . Furthermore, the security considerations discussed in apply to this document and need to be considered. As described in , these security considerations are:

• A Denial-of-Service (DoS) attack by sending MPLS Echo Requests/Replies to Label Switching Routers (LSRs) and thereby increasing their workload.
• Obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS Echo Requests and Replies.
• Obtaining information about the network through an unauthorized source using an LSP Ping.

There are mitigations described in . The same mitigations can be applied to the LSP Ping procedures described in this document; thus, this document doesn't require additional security considerations beyond the ones described in . This document does not introduce any new privacy concerns because these TLVs contain the same information that are present in data packets and EVPN routes.

IANA Considerations

Sub-TLV Type This document defines four new sub-TLV types to be included in the Target FEC Stack TLV (TLV types 1, 16, and 21) in Echo Request and Echo Reply messages in EVPN and PBB-EVPN networks. IANA has assigned the following values from the "Standards Action" (0-16383) range in the "Sub-TLVs for TLV Types 1, 16, and 21" subregistry within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space.

Sub-Type	Sub-TLV Name	Reference
42	EVPN MAC/IP	RFC 9489
43	EVPN Inclusive Multicast	RFC 9489
44	EVPN Ethernet Auto-Discovery	RFC 9489
45	EVPN IP Prefix	RFC 9489

New Return Codes defines values for the Return Code field of Echo Reply messages. This document defines two new Return Codes that SHOULD be included in the Echo Reply message by a PE in response to an Echo Request message in EVPN and PBB-EVPN networks. IANA has assigned the following values in the "Return Codes" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space.

Value	Meaning	Reference
37	Replying router is egress for the FEC at the stack depth. In addition, the BUM packets are dropped on the ES corresponding to the ESI received in the EVPN Ethernet Auto-Discovery sub-TLV because of the Split Horizon Group filtering.	RFC 9489
38	Replying router is egress for the FEC at the stack depth. In addition, the BUM packets are forwarded because there is no ES corresponding to the ESI received in the EVPN Ethernet Auto-Discovery sub-TLV.	RFC 9489

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment. This document updates RFC 4379. [STANDARDS-TRACK] This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "Vendor Private Use") has been changed to "First Come First Served" for the TLV and sub-TLV registries. It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoleted RFC 5226 (both titled "Guidelines for Writing an IANA Considerations Section in RFCs"). The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.

Acknowledgments The authors would like to thank , , , , , , , , , and for their valuable comments.

Authors' Addresses Cisco

Canada paragj@cisco.com

Cisco

United States of America sajassi@cisco.com

Cisco

Canada ssalam@cisco.com

Ciena

United States of America sboutros@ciena.com

Ericsson

United States of America gregimirsky@gmail.com