LSP-Ping Mechanisms for EVPN and PBB-EVPN
draft-ietf-bess-evpn-lsp-ping-06
BESS Workgroup P. Jain, Ed.
Internet-Draft S. Salam
Intended status: Standards Track A. Sajassi
Expires: July 20, 2022 Cisco Systems, Inc.
S. Boutros
Ciena
G. Mirsky
Ericsson
January 16, 2022
LSP-Ping Mechanisms for EVPN and PBB-EVPN
draft-ietf-bess-evpn-lsp-ping-06
Abstract
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.
Status of This Memo
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 July 20, 2022.
Copyright Notice
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
Jain, et al. Expires July 20, 2022 [Page 1]
Internet-Draft MPLS OAM for EVPN January 2022
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 4
4.1. EVPN MAC Sub-TLV . . . . . . . . . . . . . . . . . . . . 4
4.2. EVPN Inclusive Multicast Sub-TLV . . . . . . . . . . . . 5
4.3. EVPN Ethernet Auto-Discovery Sub-TLV . . . . . . . . . . 6
4.4. EVPN IP Prefix Sub-TLV . . . . . . . . . . . . . . . . . 8
5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 8
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Unicast Data-plane connectivity checks . . . . . . . . . 9
6.2. Inclusive Multicast Data-plane Connectivity Checks . . . 10
6.2.1. Ingress Replication . . . . . . . . . . . . . . . . . 10
6.2.2. Using P2MP P-tree . . . . . . . . . . . . . . . . . . 11
6.2.3. Controlling Echo Responses when using P2MP P-tree . . 12
6.3. EVPN Aliasing Data-plane connectivity check . . . . . . . 12
6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. Sub-TLV Type . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Proposed new Return Codes . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
[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 multi-homing of
CE(s) connected to multiple PEs and load balancing of traffic to and
from multi-homed CE(s).
[RFC7623] describes the use of Provider Backbone Bridging [802.1ah]
with EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in
Jain, et al. Expires July 20, 2022 [Page 2]
Internet-Draft MPLS OAM for EVPN January 2022
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 plan.
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.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
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
Jain, et al. Expires July 20, 2022 [Page 3]
Internet-Draft MPLS OAM for EVPN January 2022
EVPN: Ethernet Virtual Private Network
FEC: Forwarding Equivalent Classs
GAL: G-ACh Label
OAM: Operations, Administration, and Maintenance
P2MP: Point-to-Multipoint
PBB: Provider Backbone Bridge
PE: Provider Edge Device
4. Proposed Target FEC Stack Sub-TLVs
This document introduces four new Target FEC Stack Sub-TLVs that are
included in the LSP-Ping 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.
4.1. EVPN MAC Sub-TLV
The EVPN MAC Sub-TLV identifies the MAC for an EVPN Instance
Identifier (EVI) under test at a peer PE.
The EVPN MAC 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 TLV is included in the Echo Request sent by a PE
to a PBB-EVPN/EVPN Peer PE.
Jain, et al. Expires July 20, 2022 [Page 4]
Internet-Draft MPLS OAM for EVPN January 2022
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 LSP Echo Request is sent using the EVPN MPLS label(s) associated
with the MAC route announced by a remote PE and the MPLS transport
label(s) to reach the remote PE.
4.2. EVPN Inclusive Multicast Sub-TLV
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.
Jain, et al. Expires July 20, 2022 [Page 5]
Internet-Draft MPLS OAM for EVPN January 2022
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 remote PE participating in EVPN or PBB-EVPN. The inclusive
multicast label is the downstream assigned label announced by the
remote 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 multi-homed 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 as is described in
Section 6.
4.3. EVPN Ethernet Auto-Discovery Sub-TLV
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.
Jain, et al. Expires July 20, 2022 [Page 6]
Internet-Draft MPLS OAM for EVPN January 2022
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 multi-homed
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, should be set
according to the context:
o For per-ES context, the Ethernet Tag field in the sub-TLV must be
set to the reserved MAX-ET value [RFC7432]
o For per-EVI context, the Ethernet Tag field in the sub-TLV must be
set to the non-reserved value
Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD route for a
given multi-homed 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.
Jain, et al. Expires July 20, 2022 [Page 7]
Internet-Draft MPLS OAM for EVPN January 2022
4.4. 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 [RFC9136] and has the format as
shown in Figure 4. This TLV is included in the Echo Request sent by
a PE to a EVPN peer PE.
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 LSP Echo Request is sent using the EVPN MPLS label(s) associated
with the IP Prefix route announced by a remote PE and the MPLS
transport label(s) to reach the remote PE.
5. Encapsulation of OAM Ping Packets
The LSP Ping 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 (G-ACH)
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.
Jain, et al. Expires July 20, 2022 [Page 8]
Internet-Draft MPLS OAM for EVPN January 2022
6. Operations
6.1. Unicast Data-plane connectivity checks
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 1.1.1.1:00
and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10.
Similarly, PE2 announced a MAC route with RD 2.2.2.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
Jain, et al. Expires July 20, 2022 [Page 9]
Internet-Draft MPLS OAM for EVPN January 2022
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 E-
VPN, are similar to those described above for PBB-EVPN except that
the checks are for C-MAC addresses instead of B-MAC addresses.
6.2. Inclusive Multicast Data-plane Connectivity Checks
6.2.1. Ingress Replication
Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD
1.1.1.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 2.2.2.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 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
Jain, et al. Expires July 20, 2022 [Page 10]
Internet-Draft MPLS OAM for EVPN January 2022
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
multi-homed site. The Split Horizon label is used by leaf PE(s)
attached to the same multi-homed site to not forward packets back to
the multi-homed site. If the behavior on a leaf PE is to not forward
the packet to the multi-homed 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.
6.2.2. 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, 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.
Jain, et al. Expires July 20, 2022 [Page 11]
Internet-Draft MPLS OAM for EVPN January 2022
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 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 multi-
homed site. In case of p2mp p-tree, the Split Horizon Label is
upstream assigned [I-D.ietf-bess-mvpn-evpn-aggregation-label] 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 multi-homed site not
to forward packets back to the multi-homed site. If the behavior on
a leaf PE is to not forward the packet to the multi-homed 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".
6.2.3. Controlling Echo Responses when using P2MP P-tree
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.
6.3. EVPN Aliasing Data-plane connectivity check
Assume PE1 announced an Ethernet Auto discovery Route with the ESI
set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto
discovery Route with the ESI set to CE1 system ID and MPLS label
19002.
When an operator performs at PE3 a connectivity check for the
aliasing aspect of the EVPN Ethernet AD route to 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
Jain, et al. Expires July 20, 2022 [Page 12]
Internet-Draft MPLS OAM for EVPN January 2022
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.
6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check
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.
7. Security Considerations
The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to [RFC7432],
[RFC7623] and [RFC6425].
8. IANA Considerations
8.1. Sub-TLV Type
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:
o EVPN MAC route Sub-TLV
o EVPN Inclusive Multicast route Sub-TLV
o EVPN Auto-Discovery Route Sub-TLV
Jain, et al. Expires July 20, 2022 [Page 13]
Internet-Draft MPLS OAM for EVPN January 2022
o EVPN IP Prefix Route Sub-TLV
8.2. Proposed new Return Codes
[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 Retuen
Codes listed below from the Return Codes" registry in the
"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" name space:
o 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.
o 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.
9. Acknowledgments
The authors would like to thank Loa Andersson, Alexander Vainshtein,
Patrice Brissette and Weiguo Hao for their valuable comments.
10. References
10.1. Normative References
[I-D.ietf-bess-mvpn-evpn-aggregation-label]
Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
ietf-bess-mvpn-evpn-aggregation-label-07 (work in
progress), December 2021.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
Jain, et al. Expires July 20, 2022 [Page 14]
Internet-Draft MPLS OAM for EVPN January 2022
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC6338] Giralt, V. and R. McDuff, "Definition of a Uniform
Resource Name (URN) Namespace for the Schema for Academia
(SCHAC)", RFC 6338, DOI 10.17487/RFC6338, August 2011,
<https://www.rfc-editor.org/info/rfc6338>.
Jain, et al. Expires July 20, 2022 [Page 15]
Internet-Draft MPLS OAM for EVPN January 2022
Authors' Addresses
Parag Jain (editor)
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON K2K 3E8
Canada
Email: paragj@cisco.com
Samer Salam
Cisco Systems, Inc.
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Canada
Email: ssalam@cisco.com
Ali Sajassi
Cisco Systems, Inc.
USA
Email: sajassi@cisco.com
Sami Boutros
Ciena
USA
Email: sboutros@ciena.com
Greg Mirsky
Ericsson
USA
Email: gregimirsky@gmail.com
Jain, et al. Expires July 20, 2022 [Page 16]