| Internet-Draft | MPLS OAM for EVPN | December 2022 |
| Jain, et al. | Expires 13 June 2023 | [Page] |
LSP Ping is a widely deployed Operation, Administration, and Maintenance mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 June 2023.¶
Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) 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.¶
[RFC7432] describes MPLS based Ethernet VPN (EVPN) technology. An EVPN comprises CE(s) connected to PE(s). The PEs provide layer 2 EVPN among the CE(s) over the MPLS core infrastructure. In EVPN networks, PEs advertise the MAC addresses learned from the locally connected CE(s), along with MPLS Label, to remote PE(s) in the control plane using multi-protocol BGP. EVPN enables multihoming of CE(s) connected to multiple PEs and load balancing of traffic to and from multihomed CE(s).¶
[RFC7623] describes the use of Provider Backbone Bridging [802.1ah] with EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in data plane and only advertises Provider Backbone MAC (B-MAC) addresses in control plane using BGP.¶
Procedures for simple and efficient mechanisms to detect data plane failures using LSP Ping in MPLS network are well defined in [RFC8029] and [RFC6425]. The basic idea for the LSP Ping mechanism is to send a MPLS Echo Request packet along the same data path as data packets belonging to the same Forwarding Equivalent Classs (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. Echo Request packet contains sufficient infiormation to verify correctness of data plane operations and validate data plane against the control plane. Egress PE sends the results of the validation in 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 Target FEC Stack TLV with the purpose of identifying the FEC on the Egress PE.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
AD: Auto Discovery¶
B-MAC: Backbone MAC Address¶
BUM: Broadcast, Unknown Unicast or Multicast¶
CE: Customer Edge Device¶
C-MAC: Customer MAC Address¶
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 Classs¶
G-ACh: Generic Associated Channel¶
GAL: G-ACh Label¶
OAM: Operations, Administration, and Maintenance¶
P2MP: Point-to-Multipoint¶
PBB: Provider Backbone Bridge¶
PE: Provider Edge Device¶
VPWS: Virtual Private Wire Service¶
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 check in data plane in EVPN and PBB-EVPN networks. The target FEC stack Sub-TLVs MAY be used to validate that an indentifier for a given EVPN is programmed at the target node. These Target FEC Stack Sub-TLVs are described next.¶
The EVPN MAC/IP Sub-TLV identifies the target MAC, MAC/IP binding for ARP/ND, or IP address for an EVPN Instance Identifier (EVI) under test at an egress PE.¶
The EVPN MAC/IP Sub-TLV fields are derived from the MAC/IP Advertisement route defined in [RFC7432] Section 7.2 and have the format as shown in Figure 1. This Sub-TLV is included in the Echo Request sent by a PBB-EVPN/EVPN PE to a Peer PE. IP Address field in this Sub-TLV is optional.¶
For PBB-EVPN, Ethernet Tag ID and Ethernet Segment Identifier fields of this Sub-TLV is set per section 5.2 of [RFC7623].¶
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EVPN MAC Sub-TLV format
¶
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, MAC/IP Advertisement has multiple personality and it is used for the following cases:¶
When MPLS Echo Request is sent by an ingress PE, the contents of 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 above three cases is this Echo Request for. When the egress PE receives MAC/IP Sub-TLV containing only MAC address, the egress PE validates the MAC state and forwarding. When the egress PE receives 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, such as the egress PE receiving MAC/IP Sub-TLV containing only MAC address but with EVPN label pointing to an IP-VRF, should be considered invalid and Echo Reply should be sent with the appropriate return code by the egress PE to the ingress PE.¶
The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN Inclusive Multicast route defined in [RFC7432] Section 7.3.¶
The EVPN Inclusive Multicast Sub-TLV has the format as shown in Figure 2. This TLV is included in the Echo Request sent to the EVPN peer PE by the originator of request to verify the multicast connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.¶
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EVPN Inclusive Multicast Sub-TLV format
¶
Broadcast, unknown unicast or multicast (BUM) traffic can be sent using ingress replication or P2MP P-tree in EVPN and PBB-EVPN network. In case of 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 P2MP P-tree transport label for 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 Section 6.¶
In case of EVPN, to emulate traffic coming from a multihomed site, an additional EVPN Ethernet Auto-Discovery Sub-TLV in the Target FEC stack TLV and 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 Section 6.2.2 for operations using P2MP P-trees.¶
The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the EVPN Ethernet Auto-Discovery route advertisement defined in [RFC7432] Section 7.1. EVPN Ethernet AD Sub-TLV applies to only EVPN.¶
The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format
¶
EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet Segememnt (ES) or per-EVI. When an operator performs a connectivity check for the BUM L2 service, Echo Request packet sent, MAY contain EVPN Ethernet AD Sub-TLV to emulate traffic coming from a multihomed site. In this case, the EVPN Ethernet AD Sub-TLV is added in per-ES context. When Echo Request packet is sent for the connectivity check for EVPN Aliasing state, the context for the EVPN Ethernet AD Sub-TLV is per-EVI.¶
Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, MUST be set according to the context:¶
Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD 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 AD Sub-TLV, MUST be the RD value received for the EVI in the per-ES EVPN AD Route.¶
LSP Ping can also be used to detect data plane failures for EVPN Virtual Private Wire Service (VPWS) described in [RFC8214]. The Echo Request packet carries EVPN Ethernet AD Sub-TLV with fields populated from the EVPN Ethernet AD 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 AD route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.¶
The egress PE process the Echo Request packet and perform checks for the EVPN Ethernet AD Sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rule. Egress PE can identify that the Echo Request is for EVPN VPWS instance as EVI (identified by the RD) for EVPN VPWS is different from that for EVPN. The egress PE will use the information from the EVPN Ethernet AD 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".¶
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 [RFC9136] and applies to only EVPN. This Sub-TLV has the format as shown in Figure 4.¶
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EVPN IP Prefix Sub-TLV format
¶
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.¶
The MPLS Echo Request IP/UDP packets MUST be encapsulated with the Transport and EVPN Label(s) followed by the Generic Associated Channel Label (GAL) [RFC5586] which is the bottom most label. The GAL is followed by a Generic Associated Channel Header carrying IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for ipv4 and ipv6 channels are defiend in Generic Associated Channel (G-ACh) Parameters by IANA.¶
Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to PE1 and PE2. Assume, PE1 announced a MAC route with RD 192.0.2.1:00 and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. Similarly, PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00aa.00bb.00cc and with MPLS label 16002.¶
On PE3, when an operator performs a connectivity check for the B-MAC address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping request with the target FEC stack TLV containing EVPN MAC 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 that the packet is IPv4 OAM Packet. The PE1 will process the packet and perform checks for the EVPN MAC Sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rules.¶
+-----------------+
| |
| |
+----+ AC1 +-----+ +-----+ +----+
| CE1|------| | | PE3 |-----| CE2|
+----+\ | PE1 | IP/MPLS | | +----+
\ +-----+ Network +-----+
\ | |
AC2\ +-----+ |
\ | | |
\| PE2 | |
+-----+ |
| |
+-----------------+
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 5: PBB-EVPN network
¶
Similarly, on PE3, when an operator performs a connectivity check for the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an LSP Ping request with the target FEC stack TLV containing EVPN MAC 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 operation 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 network, an operator can also perform MAC state test using 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 AD 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.¶
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 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 Incl. 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 that the packet is IPv4 OAM Packet. The packet will have 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 Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rules. For the success case, PE1 will reply with Return Code 3 - "Replying router is an egress for the FEC at stack-depth".¶
Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with the target FEC stack TLV containing 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 Incl. 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 that the packet is IPv4 OAM Packet. The processing on PE2 will be similar to the that on PE1 as described above and for the success case, PE2 will reply with Return Code 3 - "Replying router is an egress for the FEC at stack-depth" as per [RFC8029].¶
In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-TLV and the associated MPLS Split Horizon Label above the GAL in the MPLS label stack, may be added 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 not forward 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 EVPN Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will reply with a Return Code indicating that "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 EVPN Ethernet AD Sub-TLV because of the Split Horizon Group filtering" as described in Section 8.¶
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, 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 EVPN Inclusive Multicast Sub-TLV in the Echo Request packet. The Echo Request packet is sent over P2MP LSP with the {P2MP P-tree label, GAL} MPLS label stack and IP ACH Channel header.¶
When using Aggregate Inclusive P-tree, 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 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 label, EVPN Upstream assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel header.¶
The Leaf PE(s) of the p2mp 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 Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rules. For the success case, the Leaf PE will reply with Return Code 3 - "Replying router is an egress for the FEC at stack-depth".¶
In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-TLV and the associated MPLS Split Horizon Label above the GAL in MPLS label stack, may be added to emulate traffic coming from a multihomed site. In case of p2mp p-tree, the Split Horizon Label is upstream assigned and is received by all the leaf PEs of the p2mp-ptree. The Split Horizon label is used by leaf PE(s) attached to the same multihomed site not to forward 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 in EVPN Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will reply with a Return Code indicating that "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 EVPN Ethernet AD Sub-TLV because of the Split Horizon Group filtering" as described in Section 8. If the leaf PE does not have the ESI identified in the EVPN Ethernet AD Sub-TLV, the PE can reply with a Return Code indicating that "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 EVPN Ethernet AD Sub-TLV".¶
The procedures described in [RFC6425] for preventing congestion of Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a single egress node (Node Address P2MP Responder Identifier TLV) can be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees for broadcast, multicast, and unknown unicast traffic.¶
Assume PE1 announced an Ethernet AD per-EVI Route with the ESI set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet AD 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 AD route on PE1, the operator initiates an LSP Ping request with the target FEC stack TLV containing EVPN Ethernet AD Sub-TLV in the Echo Request packet. The Echo Request packet is sent with the {Transport label(s) to reach PE1, EVPN Ethernet AD 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 AD Sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rules.¶
Assume PE1 in Figure 5, 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 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 Section 4.4 in [RFC8029] and respond according to [RFC8029] processing rules.¶
The proposal introduced in this document does not introduce any new security considerations beyond that already apply to [RFC7432], [RFC7623] and [RFC6425]. Furthermore, the security considerations discussed in [RFC8029] apply to this document and need to be considered. As described in [RFC8029], these security considerations are:¶
The proposal does not introduce any new privacy concerns because these TLVs contain the same information that are present in data packets and EVPN routes.¶
This document defines four new Sub-TLV type to be included in Target FEC Stack TLV (TLV Type 1, 16 and 21) [RFC8029] in Echo Request and Echo Reply messages in EVPN and PBB-EVPN network.¶
IANA is requested to assign lowest 4 free values for the four Sub-TLVs listed below from the Standards Track" (0-16383) range, in the "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry, in the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space:¶
[RFC8029] defines values for the Return Code field of Echo Reply. This document proposes two new Return Codes, which SHOULD be included in the Echo Reply message by a PE in response to Echo Request message in EVPN and PBB-EVPN network.¶
IANA is requested to assign 2 lowest free values for the 2 Return Codes listed below from the Return Codes" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space:¶
The authors would like to thank Loa Andersson, Alexander Vainshtein, Ron Sdayoor, Patrice Brissette and Weiguo Hao for their valuable comments.¶