rfc9489.original   rfc9489.txt 
BESS Workgroup P. Jain Internet Engineering Task Force (IETF) P. Jain
Internet-Draft A. Sajassi Request for Comments: 9489 A. Sajassi
Intended status: Standards Track S. Salam Category: Standards Track S. Salam
Expires: 30 November 2023 Cisco ISSN: 2070-1721 Cisco
S. Boutros S. Boutros
Ciena Ciena
G. Mirsky G. Mirsky
Ericsson Ericsson
29 May 2023 November 2023
LSP-Ping Mechanisms for EVPN and PBB-EVPN Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone
draft-ietf-bess-evpn-lsp-ping-11 Bridging EVPN (PBB-EVPN)
Abstract Abstract
LSP Ping is a widely deployed Operation, Administration, and Label Switched Path (LSP) Ping is a widely deployed Operation,
Maintenance mechanism in MPLS networks. This document describes Administration, and Maintenance (OAM) mechanism in MPLS networks.
mechanisms for detecting data plane failures using LSP Ping in MPLS This document describes mechanisms for detecting data plane failures
based Ethernet VPN (EVPN) and Provider Backbone Bridging with EVPN using LSP Ping in MPLS-based Ethernet VPN (EVPN) and Provider
(PBB-EVPN) networks. Backbone Bridging EVPN (PBB-EVPN) networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 30 November 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9489.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. Proposed Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 4 4. Target FEC Stack Sub-TLVs
4.1. EVPN MAC/IP Sub-TLV . . . . . . . . . . . . . . . . . . . 4 4.1. EVPN MAC/IP Sub-TLV
4.2. EVPN Inclusive Multicast Sub-TLV . . . . . . . . . . . . 7 4.2. EVPN Inclusive Multicast Sub-TLV
4.3. EVPN Ethernet Auto-Discovery Sub-TLV . . . . . . . . . . 8 4.3. EVPN Ethernet Auto-Discovery (A-D) Sub-TLV
4.3.1. Ethernet TAG Value . . . . . . . . . . . . . . . . . 9 4.3.1. Ethernet Tag Value
4.3.2. Per-ES EVPN Auto-Discovery Route with different 4.3.2. Per-ES EVPN Auto-Discovery Route with Different RDs
RDs . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.3. EVPN VPWS
4.3.3. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . 10 4.4. EVPN IP Prefix Sub-TLV
4.4. EVPN IP Prefix Sub-TLV . . . . . . . . . . . . . . . . . 10 5. Encapsulation of OAM Ping Packets
5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 12 6. Operations
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Unicast Data Plane Connectivity Checks
6.1. Unicast Data-plane connectivity checks . . . . . . . . . 12 6.2. Inclusive Multicast Data Plane Connectivity Checks
6.2. Inclusive Multicast Data-plane Connectivity Checks . . . 14 6.2.1. Ingress Replication
6.2.1. Ingress Replication . . . . . . . . . . . . . . . . . 14 6.2.2. Using P2MP P-Tree
6.2.2. Using P2MP P-tree . . . . . . . . . . . . . . . . . . 15 6.2.3. Controlling Echo Responses When Using P2MP P-Tree
6.2.3. Controlling Echo Responses when using P2MP P-tree . . 16 6.3. EVPN Aliasing Data Plane Connectivity Check
6.3. EVPN Aliasing Data-plane connectivity check . . . . . . . 17 6.4. EVPN IP Prefix (RT-5) Data Plane Connectivity Check
6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check . . . 17 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. Sub-TLV Type
8.1. Sub-TLV Type . . . . . . . . . . . . . . . . . . . . . . 18 8.2. New Return Codes
8.2. Proposed new Return Codes . . . . . . . . . . . . . . . . 18 9. Normative References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments
10. Normative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[RFC7432] describes MPLS based EVPN technology. An EVPN comprises [RFC7432] describes MPLS-based EVPN technology. An EVPN comprises
CE(s) connected to PE(s). The PEs provide layer-2 EVPN among the one or more Customer Edge devices (CEs) connected to one or more
CE(s) over the MPLS core infrastructure. In EVPN networks, the PEs Provider Edge devices (PEs). The PEs provide Layer 2 (L2) EVPN among
advertise the MAC addresses learned from the locally connected CE(s), the CE(s) over the MPLS core infrastructure. In EVPN networks, the
along with MPLS Label, to remote PE(s) in the control plane using PEs advertise the Media Access Control (MAC) addresses learned from
multiprotocol BGP [RFC4760]. EVPN enables multihoming of CE(s) the locally connected CE(s), along with the MPLS label, to remote
connected to multiple PEs and load balancing of traffic to and from PE(s) in the control plane using multiprotocol BGP [RFC4760]. EVPN
multihomed CE(s). 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] [RFC7623] describes the use of Provider Backbone Bridging EVPN. PBB-
with EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in EVPN maintains the Customer MAC (C-MAC) learning in the data plane
data plane and only advertises Provider Backbone MAC (B-MAC) and only advertises Backbone MAC (B-MAC) addresses in a control plane
addresses in control plane using BGP. using BGP.
Procedures for simple and efficient mechanisms to detect data plane Procedures for simple and efficient mechanisms to detect data plane
failures using LSP Ping in MPLS network are well defined in [RFC8029] failures using LSP Ping in MPLS networks are well defined in
and [RFC6425]. The basic idea for the LSP Ping mechanism is to send [RFC8029] and [RFC6425]. The basic idea for the LSP Ping mechanism
a MPLS Echo Request packet along the same data path as data packets is to send an MPLS Echo Request packet along the same data path as
belonging to the same Forwarding Equivalent Class (FEC). The Echo data packets belonging to the same Forwarding Equivalent Class (FEC).
Request packet carries the FEC being verified in the Target FEC Stack The Echo Request packet carries the FEC being verified in the Target
TLV [RFC8029]. Once the Echo Request packet reaches the end of the FEC Stack TLV [RFC8029]. Once the Echo Request packet reaches the
MPLS path, it is sent to the control plane of the egress PE. The end of the MPLS path, it is sent to the control plane of the egress
Echo Request packet contains sufficient information to verify the PE. The Echo Request packet contains sufficient information to
correctness of data plane operations and validate data plane against verify the correctness of data plane operations and validate the data
the control plane. The Egress PE sends the results of the validation plane against the control plane. The egress PE sends the results of
in an Echo Reply packet to the originating PE of the Echo Request the validation in an Echo Reply packet to the originating PE of the
packet. Echo Request packet.
This document defines procedures to detect data plane failures using This document defines procedures to detect data plane failures using
LSP Ping in MPLS networks deploying EVPN and PBB-EVPN. This document 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 defines four new sub-TLVs for the Target FEC Stack TLV with the
of identifying the FEC on the Egress PE. purpose of identifying the FEC on the egress PE.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
AD: Auto Discovery A-D: Auto-Discovery
B-MAC: Backbone MAC Address B-MAC: Backbone MAC
BUM: Broadcast, Unknown Unicast or Multicast BUM: Broadcast, Unknown Unicast, and Multicast
CE: Customer Edge Device CE: Customer Edge device
C-MAC: Customer MAC Address C-MAC: Customer MAC
DF: Designated Forwarder DF: Designated Forwarder
ES: Ethernet Segment ES: Ethernet Segment
ESI: Ethernet Segment Identifier
EVI: EVPN Instance Identifier that globally identifies the EVPN ESI: Ethernet Segment Identifier
Instance
EVPN: Ethernet Virtual Private Network EVI: EVPN Instance Identifier that globally identifies the EVPN
Instance
FEC: Forwarding Equivalent Classs EVPN: Ethernet Virtual Private Network
G-ACh: Generic Associated Channel FEC: Forwarding Equivalent Class
GAL: G-ACh Label G-ACh: Generic Associated Channel
OAM: Operations, Administration, and Maintenance GAL: G-ACh Label
P2MP: Point-to-Multipoint MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on
a PE
PBB-EVPN: Provider Backbone Bridge with EVPN ND: Neighbor Discovery
PE: Provider Edge Device OAM: Operations, Administration, and Maintenance
VPWS: Virtual Private Wire Service P2MP: Point-to-Multipoint
4. Proposed Target FEC Stack Sub-TLVs PBB-EVPN: Provider Backbone Bridging EVPN
This document introduces four new Target FEC Stack Sub-TLVs that are PE: Provider Edge device
VPWS: Virtual Private Wire Service
4. 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 included in the MPLS Echo Request packet. The Echo Request packets
are used for connectivity check in data plane in EVPN and PBB-EVPN are used for connectivity checks in the data plane in EVPN and PBB-
networks. The target FEC stack Sub-TLVs MAY be used to validate that EVPN networks. The Target FEC Stack sub-TLVs MAY be used to validate
an identifier for a given EVPN is programmed at the target node. that an identifier for a given EVPN is programmed at the target node.
4.1. EVPN MAC/IP Sub-TLV 4.1. EVPN MAC/IP Sub-TLV
The EVPN MAC/IP Sub-TLV identifies the target MAC, MAC/IP binding for 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 ARP/ND, or IP address for an EVI under test at an egress PE. This
test at an egress PE. This Sub-TLV is included in the Echo Request sub-TLV is included in the Echo Request sent by an EVPN/PBB-EVPN PE
sent by a EVPN/PBB-EVPN PE to a Peer PE. to a peer PE.
The EVPN MAC/IP Sub-TLV fields are derived from the MAC/IP The fields of the EVPN MAC/IP sub-TLV are derived from the MAC/IP
Advertisement route defined in Section 7.2 in [RFC7432] and have the Advertisement route defined in Section 7.2 of [RFC7432] and have the
format as shown in Figure 1. The fields of EVPN MAC/IP Sub-TLV format shown in Figure 1. The fields of the EVPN MAC/IP sub-TLV
should be set according to the following that is consistent with should be set according to the following, which is consistent with
[RFC7432] and [RFC7623]: [RFC7432] and [RFC7623]:
* The Route Distinguisher (RD) field is a 10-octet field and is set * The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN
to the RD of the MAC-VRF on the Peer PE.
* The Ethernet TAG ID field can be 0 or a valid VLAN ID for EVPN
VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of
this field is always 0 as per Section 5.2 of [RFC7623]. this field is always 0 as per Section 5.2 of [RFC7623].
* The Ethernet Segment Identifier field is 10-octet field. For * The Ethernet Segment Identifier field is a 10-octet field. For
EVPN, it is set to 0 for singlehomed ES or to a valid ESI ID for a EVPN, it is set to 0 for a single-homed ES or to a valid ESI ID
multihomed ES. For PBB-EVPN, the Ethernet Segment Identifier for a multihomed ES. For PBB-EVPN, the Ethernet Segment
field must be set to either 0 (for single-homed segments or Identifier field must be set to either 0 (for single-homed
multihomed segments with per-I-SID load-balancing) or to MAX-ESI segments or multihomed segments with per-I-SID load balancing) or
(for multihomed segments with per-flow load-balancing) as describe to MAX-ESI (for multihomed segments with per-flow load balancing)
in Section 5.2 in [RFC7623]. as described in Section 5.2 of [RFC7623].
* The MAC Addr Len field specifies the MAC length in bits. Only 48 * The MAC Addr Len field specifies the MAC length in bits. Only
bit MAC Addresses are supported as this document follows MAC 48-bit MAC addresses are supported as this document follows the
address length supported by [RFC7432]. MAC address length supported by [RFC7432].
* The MAC Address field is set to the 6-octet MAC address. * The MAC Address field is set to the 6-octet MAC address.
* The IP Address field is optional. When the IP Address field is * 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 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 Address field is present, the IP Addr Len field is in bits and is
either set to 32 for IPv4 or 128 for IPv6 address. 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 * The Must Be Zero fields are set to 0. The receiving PE should
ignore the Must Be Zero fields. ignore the Must Be Zero fields.
0 1 2 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 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID | | Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier | | Ethernet Segment Identifier |
| (10 octets) | | (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | MAC Addr Len | | | Must Be Zero | MAC Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+ (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (6 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | IP Addr Len | | | Must Be Zero | IP Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (0, 4 or 16 Octets) | | IP Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EVPN MAC Sub-TLV format Figure 1: EVPN MAC/IP Sub-TLV Format
The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS 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 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. 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 In EVPN, the MAC/IP Advertisement route has multiple uses and is used
for the following cases: for the following cases:
* This route with only MAC address and MPLS Label1 is used for * This route with only a MAC address and MPLS Label1 is used for
populating MAC-VRF and performing MAC forwarding. populating MAC-VRF and performing MAC forwarding.
* This route with MAC and IP addresses and only MPLS Label1 is used * This route with MAC and IP addresses and only MPLS Label1 is used
for populating both MAC-VRF and ARP/ND tables (for ARP for populating both MAC-VRF and ARP/ND tables (for ARP
suppression) as well as for performing MAC forwarding suppression) as well as for performing MAC forwarding.
* This route with MAC and IP addresses and both MPLS Label1 and * 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 Label2 is used for populating MAC-VRF and IP-VRF tables as well as
for both MAC forwarding, and IP forwarding in case of symmetric for both MAC and IP forwarding in the case of symmetric Integrated
IRB. Routing and Bridging (IRB).
When MPLS Echo Request is sent by an ingress PE, the contents of Echo When an MPLS Echo Request is sent by an ingress PE, the contents of
Request and the egress PE mode of operation (i.e., IRB mode or L2 the Echo Request and the egress PE mode of operation (i.e., IRB mode
mode) along with EVPN MPLS label of the packet, determine which of or L2 mode) along with EVPN MPLS label of the packet determine which
the above three cases is this Echo Request for. When the egress PE of the three cases above this Echo Request is for. When the egress
receives MAC/IP Sub-TLV containing only MAC address, the egress PE PE receives the EVPN MAC/IP sub-TLV containing only the MAC address,
validates the MAC state and forwarding. When the egress PE receives the egress PE validates the MAC state and forwarding. When the
MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN egress PE receives the EVPN MAC/IP sub-TLV containing both MAC and IP
label points to a MAC-VRF, then the egress PE validates the MAC state addresses and if the EVPN label points to a MAC-VRF, then the egress
and forwarding. If the egress PE is not configured in symmetric IRB PE validates the MAC state and forwarding. If the egress PE is not
mode, it also validates ARP/ND state. However, if the EVPN label configured in symmetric IRB mode, it also validates ARP/ND state.
points to an IP-VRF, then the egress PE validates IP state and However, if the EVPN label points to an IP-VRF, then the egress PE
forwarding. Any other combinations, such as the egress PE receiving validates IP state and forwarding. Any other combinations (e.g., the
MAC/IP Sub-TLV containing only MAC address but with EVPN label egress PE receiving the EVPN MAC/IP sub-TLV containing only the MAC
pointing to an IP-VRF, should be considered invalid and Echo Reply address but with the EVPN label pointing to an IP-VRF) should be
should be sent with the appropriate return code by the egress PE to considered invalid, and the egress PE should send an Echo Reply with
the ingress PE. the appropriate Return Code to the ingress PE.
4.2. EVPN Inclusive Multicast Sub-TLV 4.2. EVPN Inclusive Multicast Sub-TLV
The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN The fields of the EVPN Inclusive Multicast sub-TLV are based on the
Inclusive Multicast Tag route defined in [RFC7432] Section 7.3. This EVPN Inclusive Multicast Tag route defined in Section 7.3 of
TLV is included in the Echo Request sent to the EVPN peer PE by the [RFC7432]. This TLV is included in the Echo Request sent to the EVPN
originator of request to verify the multicast connectivity state on peer PE by the originator of the request to verify the multicast
the peer PE(s) in EVPN and PBB-EVPN networks. connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.
The EVPN Inclusive Multicast Sub-TLV has the format as shown in The EVPN Inclusive Multicast sub-TLV has the format shown in
Figure 2. The fields of this Sub-TLV should be set according to the Figure 2. The fields of this sub-TLV should be set according to the
following that is consistent with [RFC7432] and [RFC7623]: following, which is consistent with [RFC7432] and [RFC7623]:
* The Route Distinguisher (RD) field is a 10-octet field and is set * The Route Distinguisher (RD) field is a 10-octet field and is set
to the RD of the MAC-VRF on the Peer PE. 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 * For EVPN, the Ethernet Tag ID field can be set to 0 or a valid
VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB- VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB-
EVPN, the value of this field is set to Service Instance EVPN, the value of this field is set to the Service Instance
Identifier (I-SID) value as per Section 5.3 of [RFC7623]. Identifier (I-SID) value as per Section 5.3 of [RFC7623].
* The IP Addr Len field specifies length of the Originating Router's * The IP Addr Len field specifies the length of the Originating
IP Addr field in bits and it is either set to 32 for IPv4 or 128 Router's IP Addr field in bits and is set to either 32 for IPv4
for IPv6 address. addresses or 128 for IPv6 addresses.
* The Originating Router's IP Addr field is set to IPv4 or IPv6 * The Originating Router's IP Addr field is set to the IPv4 or IPv6
address of the peer PE. address of the peer PE.
0 1 2 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 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID | | Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Addr Len | | | IP Addr Len | |
+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ |
~ Originating Router's IP Addr ~ ~ Originating Router's IP Addr ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EVPN Inclusive Multicast Sub-TLV format Figure 2: EVPN Inclusive Multicast Sub-TLV Format
Broadcast, unknown unicast or multicast (BUM) traffic can be sent BUM traffic can be sent using ingress replication or P2MP P-tree in
using ingress replication or P2MP P-tree in EVPN and PBB-EVPN EVPN and PBB-EVPN networks. When using ingress replication, the Echo
network. In case of ingress replication, the Echo Request is sent Request is sent using a label stack of [Transport label, Inclusive
using a label stack of [Transport label, Inclusive Multicast label] Multicast label] to each egress PE participating in EVPN or PBB-EVPN.
to each egress PE participating in EVPN or PBB-EVPN. The inclusive The Inclusive Multicast label is the downstream-assigned label
multicast label is the downstream assigned label announced by the announced by the egress PE to which the Echo Request is being sent.
egress PE to which the Echo Request is being sent. The Inclusive The Inclusive Multicast label is the inner label in the MPLS label
Multicast label is the inner label in the MPLS label stack. stack.
When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent 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 P2MP P-tree transport label for the Inclusive P-tree
using a label stack of [P2MP P-tree transport label, upstream arrangement or using a label stack of [P2MP P-tree Transport label,
assigned EVPN Inclusive Multicast label] for the aggregate inclusive upstream-assigned EVPN Inclusive Multicast label] for the Aggregate
P2MP P-tree arrangement as described in Section 6. Inclusive P2MP P-tree arrangement as described in Section 6.
In case of EVPN, to emulate traffic coming from a multihomed site, an In an EVPN network, to emulate traffic coming from a multihomed site,
additional EVPN Ethernet Auto-Discovery Sub-TLV in the Target FEC an additional EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV
stack TLV and ESI Split Horizon Group MPLS label as the bottom label, and an ESI Split Horizon Group MPLS label as the bottom label are
are also included in the Echo Request packet. When using P2MP also included in the Echo Request packet. When using P2MP P-tree,
P-tree, the ESI Split Horizon Group MPLS label is upstream assigned. the ESI Split Horizon Group MPLS label is upstream assigned. Please
Please see Section 6.2.2 for operations using P2MP P-trees. see Section 6.2.2 for operations using P2MP P-trees.
4.3. EVPN Ethernet Auto-Discovery Sub-TLV 4.3. EVPN Ethernet Auto-Discovery (A-D) Sub-TLV
The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the The fields in the EVPN Ethernet A-D sub-TLV are based on the EVPN
EVPN Ethernet Auto-Discovery route advertisement defined in [RFC7432] Ethernet A-D route advertisement defined in Section 7.1 of [RFC7432].
Section 7.1. EVPN Ethernet AD Sub-TLV applies to only EVPN. The EVPN Ethernet A-D sub-TLV only applies to EVPN.
The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3. The The EVPN Ethernet A-D sub-TLV has the format shown in Figure 3. The
fields of this Sub-TLV should be set according to the following that fields of this sub-TLV should be set according to the following,
is consistent with [RFC7432]: which is consistent with [RFC7432]:
* The Route Distinguisher (RD) field is a 10-octet field and is set * 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 Section 4.3.2 to the RD of the MAC-VRF on the peer PE. Please see Section 4.3.2
below for the case when per-ES AD route is announced with for the case when a per-ES A-D route is announced with different
different RDs RDs.
* The Ethernet TAG ID field can be 0, MAX-ET or a valid VLAN ID as * The Ethernet Tag ID field can be 0, MAX-ET, or a valid VLAN ID as
described in Section 4.3.1 below. described in Section 4.3.1.
* The Ethernet Segment Identifier field is 10-octet field and is set * The Ethernet Segment Identifier field is a 10-octet field and is
to 0 for singlehomed ES or to a valid ESI ID for a multihomed ES. 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 * The Must Be Zero field is set to 0. The receiving PE should
ignore the Must Be Zero field. ignore the Must Be Zero field.
0 1 2 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 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID | | Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier | | Ethernet Segment Identifier |
| (10 octets) | | (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | | | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format Figure 3: EVPN Ethernet A-D Sub-TLV Format
4.3.1. Ethernet TAG Value 4.3.1. Ethernet Tag Value
EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet The EVPN Ethernet A-D sub-TLV can be sent in the context of per-ES or
Segment (ES) or per-EVI. When an operator performs a connectivity per-EVI. When an operator performs a connectivity check for the BUM
check for the BUM L2 service, Echo Request packet sent, MAY contain L2 service, an Echo Request packet is sent and MAY contain the EVPN
EVPN Ethernet AD Sub-TLV to emulate traffic coming from a multihomed Ethernet A-D sub-TLV to emulate traffic coming from a multihomed
site. In this case, the EVPN Ethernet AD Sub-TLV is added in per-ES site. In this case, the EVPN Ethernet A-D sub-TLV is added in the
context. When Echo Request packet is sent for the connectivity check per-ES context. When an Echo Request packet is sent for the
for EVPN Aliasing state, the context for the EVPN Ethernet AD Sub-TLV connectivity check for EVPN Aliasing state, the context for the EVPN
is per-EVI. Ethernet A-D sub-TLV is per-EVI.
Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, MUST be set The Ethernet Tag field value in the EVPN Ethernet A-D sub-TLV MUST be
according to the context: set according to the context:
* For per-ES context, the Ethernet Tag field in the sub-TLV MUST be * For the per-ES context, the Ethernet Tag field in the sub-TLV MUST
set to the reserved MAX-ET value [RFC7432] be set to the reserved MAX-ET value [RFC7432].
* For per-EVI context, the Ethernet Tag field in the sub-TLV MUST be * For the per-EVI context, the Ethernet Tag field in the sub-TLV
set to the non-reserved value MUST be set to the non-reserved value.
4.3.2. Per-ES EVPN Auto-Discovery Route with different RDs 4.3.2. Per-ES EVPN Auto-Discovery Route with Different RDs
Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD route for a Section 8.2 of [RFC7432] specifies that a per-ES EVPN A-D route for a
given multihomed ES, may be advertised more than once with different given multihomed ES may be advertised more than once with different
RD values because many EVIs may be associated with the same ES and 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 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 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 sub-TLV MUST be the RD value received for the EVI in the per-ES EVPN
AD Route. A-D route.
4.3.3. EVPN VPWS 4.3.3. EVPN VPWS
LSP Ping can also be used to detect data plane failures for EVPN LSP Ping can also be used to detect data plane failures for the EVPN
Virtual Private Wire Service (VPWS) described in [RFC8214]. The Echo VPWS described in [RFC8214]. The Echo Request packet carries the
Request packet carries EVPN Ethernet AD Sub-TLV with fields populated EVPN Ethernet A-D sub-TLV with fields populated from the EVPN
from the EVPN Ethernet AD per EVI route announced by the egress PE Ethernet A-D per-EVI route announced by the egress PE for the EVPN
for the EVPN VPWS under test. The Echo Request is sent by the VPWS under test. The Echo Request is sent by the ingress PE using
ingress PE using the EVPN MPLS label associated with the EVPN the EVPN MPLS label associated with the EVPN Ethernet A-D route
Ethernet AD route announced by the egress PE and the MPLS transport announced by the egress PE and the MPLS transport label(s) to reach
label(s) to reach the egress PE. the egress PE.
The egress PE process the Echo Request packet and perform checks for The egress PE processes the Echo Request packet and performs checks
the EVPN Ethernet AD Sub-TLV present in the Target FEC Stack TLV as for the EVPN Ethernet A-D sub-TLV present in the Target FEC Stack TLV
described in Section 4.4 in [RFC8029] and respond according to as described in Section 4.4 of [RFC8029] and responds according to
[RFC8029] processing rule. Egress PE can identify that the Echo processing rules in [RFC8029]. The egress PE can identify that the
Request is for EVPN VPWS instance as EVI (identified by the RD) for Echo Request is for the EVPN VPWS instance as EVI (identified by the
EVPN VPWS is different from that for EVPN. The egress PE will use RD) for EVPN VPWS is different from EVI assigned for EVPN. The
the information from the EVPN Ethernet AD Sub-TLV in the Target FEC egress PE will use the information from the EVPN Ethernet A-D sub-TLV
Stack TLV and validate the VLAN state for the EVPN VPWS under test. in the Target FEC Stack TLV and validate the VLAN state for the EVPN
For the success case, the egress PE will reply with Return Code 3 - VPWS under test. For the success case, the egress PE will reply with
"Replying router is an egress for the FEC at stack-depth". Return Code 3 ("Replying router is an egress for the FEC at stack-
depth <RSC>").
4.4. EVPN IP Prefix Sub-TLV 4.4. EVPN IP Prefix Sub-TLV
The EVPN IP Prefix Sub-TLV identifies the IP Prefix for an EVI under The EVPN IP Prefix sub-TLV identifies the IP prefix for an EVI under
test at a peer PE. test at a peer PE.
The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix
Route (RT-5) advertisement defined in [RFC9136]. This sub-TLV route (RT-5) advertisement defined in [RFC9136]. This sub-TLV only
applies to only EVPN. applies to EVPN.
The EVPN IP Prefix Sub-TLV has the format shown in Figure 4. The The EVPN IP Prefix sub-TLV has the format shown in Figure 4. The
total length (not shown) of this sub-TLV MUST be either 32 bytes (if 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 IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are
carried). The IP prefix and gateway IP address MUST be from the same carried). The IP prefix and gateway IP address MUST be from the same
IP address family, as described in Section 3.1 of [RFC9136]. IP address family, as described in Section 3.1 of [RFC9136].
The fields of EVPN IP Prefix Sub-TLV should be set according to the The fields of the EVPN IP Prefix sub-TLV should be set according to
following that is consistent with [RFC9136]: the following, which is consistent with [RFC9136]:
* The Route Distinguisher (RD) field is a 10-octet field and is set * The Route Distinguisher (RD) field is a 10-octet field and is set
to the RD of the IP-VRF on the Peer PE. 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 * The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN
VLAN-aware bundle service [RFC7432]. VLAN-aware bundle service [RFC7432].
* The Ethernet Segment Identifier field is 10-octet field and is set * The Ethernet Segment Identifier field is a 10-octet field and is
to a valid ESI ID if ESI is used as Overlay Index as per set to a valid ESI ID if the ESI is used as an Overlay Index as
Section 3.1 of [RFC9136]. Otherwise the Ethernet Segment per Section 3.1 of [RFC9136]. Otherwise, the Ethernet Segment
Identifier field is set to all 0s. Identifier field is set to 0.
* The IP Prefix Len field specifies the number of bits in the IP * The IP Prefix Len field specifies the number of bits in the IP
Prefix field. It is set to between 0 and 32 for IPv4 or between 0 Prefix field. It is set to a value between 0 and 32 for IPv4 or
to 128 for IPv6. between 0 to 128 for IPv6.
* The IP prefix field is set to a 4-octet IPv4 address (with * The IP Prefix field is set to a 4-octet IPv4 address (with
trailing 0 bits to make 32 bits in all) or 16-octet IPv6 address 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 (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 family of this field is inferred from the sub-TLV length field, as
discussed above. discussed above.
* The Gateway (GW) IP Address field is set to a 4-octet IPv4 address * The Gateway (GW) IP Address field is set to a 4-octet IPv4 address
or 16-octet IPv6 address if it's used as an Overlay Index for the or a 16-octet IPv6 address if it's used as an Overlay Index for
IP prefixes. If the GW IP Address is not being used, it must be the IP prefixes. If the GW IP Address is not being used, it must
set to 0 as described in Section 3.1 of [RFC9136]. The address be set to 0 as described in Section 3.1 of [RFC9136]. The address
family of this field is inferred from the sub-TLV length field, as family of this field is inferred from the sub-TLV length field, as
discussed above. discussed above.
* The Must Be Zero field is set to 0. The receiving PE should * The Must Be Zero field is set to 0. The receiving PE should
ignore the Must Be Zero field. ignore the Must Be Zero field.
0 1 2 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 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Tag ID | | Ethernet Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Segment Identifier | | Ethernet Segment Identifier |
| (10 octets) | | (10 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Must Be Zero | IP Prefix Len | | | Must Be Zero | IP Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Prefix (4 or 16 Octets) ~ ~ IP Prefix (4 or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ GW IP Address (4 or 16 Octets) ~ ~ GW IP Address (4 or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EVPN IP Prefix Sub-TLV format Figure 4: EVPN IP Prefix Sub-TLV Format
The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS 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 label(s) associated with the IP Prefix route announced by the egress
PE and the MPLS transport label(s) to reach the egress PE. PE and the MPLS transport label(s) to reach the egress PE.
5. Encapsulation of OAM Ping Packets 5. Encapsulation of OAM Ping Packets
The MPLS Echo Request IP/UDP packets MUST be encapsulated with the The MPLS Echo Request IP/UDP packets MUST be encapsulated with the
Transport and EVPN Label(s) followed by the Generic Associated Transport and EVPN label(s) followed by the GAL [RFC5586], which is
Channel Label (GAL) [RFC5586] which is the bottom most label. The the bottommost label. The GAL is followed by a G-ACh header carrying
GAL is followed by a Generic Associated Channel Header carrying the IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for
IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 IPv4 and IPv6 channels are defined in the "Generic Associated Channel
and IPv6 channels are defined in Generic Associated Channel (G-ACh) (G-ACh) Parameters" IANA registry.
Parameters by IANA.
6. Operations 6. Operations
6.1. Unicast Data-plane connectivity checks 6.1. Unicast Data Plane Connectivity Checks
Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to 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 PE1 and PE2. Assume that PE1 announced a MAC route with RD
and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. 192.0.2.1:00 and B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001
Similarly, PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC for EVI 10. Similarly, PE2 announced a MAC route with RD
00-AA-00-BB-00-CC and with MPLS label 16002. 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 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 address 00-AA-00-BB-00-CC on PE1, the operator initiates an LSP Ping
request with the target FEC stack TLV containing EVPN MAC Sub-TLV in request with the Target FEC Stack TLV containing the EVPN MAC/IP sub-
the Echo Request packet. The Echo Request packet is sent with the TLV in the Echo Request packet. The Echo Request packet is sent with
{Transport Label(s) to reach PE1, EVPN Label = 16001, GAL} MPLS label the {Transport label(s) to reach PE1, EVPN label = 16001, GAL} MPLS
stack and IP ACH Channel header. Once the Echo Request packet 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 reaches PE1, PE1 will use the GAL and the IP ACH Channel header to
determine that the packet is IPv4 or IPv6 OAM Packet. The PE1 will determine if the packet is an IPv4 or IPv6 OAM packet. The PE1 will
process the packet and perform checks for the EVPN MAC Sub-TLV process the packet and perform checks for the EVPN MAC/IP sub-TLV
present in the Target FEC Stack TLV as described in Section 4.4 in present in the Target FEC Stack TLV as described in Section 4.4 of
[RFC8029] and respond according to [RFC8029] processing rules. [RFC8029] and respond according to the processing rules in [RFC8029].
+-----------------+ +-----------------+
| | | |
| | | |
+----+ AC1 +-----+ +-----+ +----+ +----+ AC1 +-----+ +-----+ +----+
| CE1|------| | | PE3 |-----| CE2| | CE1|------| | | PE3 |-----| CE2|
+----+\ | PE1 | IP/MPLS | | +----+ +----+\ | PE1 | IP/MPLS | | +----+
\ +-----+ Network +-----+ \ +-----+ Network +-----+
\ | | \ | |
AC2\ +-----+ | AC2\ +-----+ |
\ | | | \ | | |
\| PE2 | | \| PE2 | |
+-----+ | +-----+ |
| | | |
+-----------------+ +-----------------+
<-802.1Q-> <------PBB over MPLS------> <-802.1Q-> <-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 5: PBB-EVPN network Figure 5: PBB-EVPN Network
Similarly, on PE3, when an operator performs a connectivity check for 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 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 EVPN MAC LSP Ping request with the Target FEC Stack TLV containing the EVPN
Sub-TLV in the Echo Request packet. The Echo Request packet is sent MAC/IP sub-TLV in the Echo Request packet. The Echo Request packet
with the {MPLS transport Label(s) to reach PE2, EVPN Label = 16002, is sent with the {MPLS Transport label(s) to reach PE2, EVPN label =
GAL} MPLS label stack and IP ACH Channel header. 16002, GAL} MPLS label stack and IP ACH Channel header.
LSP Ping operation for unicast data plane connectivity checks in LSP Ping operations for unicast data plane connectivity checks in
EVPN, are similar to those described above for PBB-EVPN except that EVPN are similar to those described above for PBB-EVPN, except that
the checks are for C-MAC addresses instead of B-MAC addresses. the checks are for C-MAC addresses instead of B-MAC addresses.
In EVPN network, an operator can also perform MAC state test using In EVPN networks, an operator can also perform a MAC state test using
aliasing label for the MAC to verify the MAC state on the egress 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 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 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 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 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 route advertisement from the multihoming PE that has learned the CE's
MAC address locally. MAC address locally.
6.2. Inclusive Multicast Data-plane Connectivity Checks 6.2. Inclusive Multicast Data Plane Connectivity Checks
6.2.1. Ingress Replication 6.2.1. Ingress Replication
Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD 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 192.0.2.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel
type set to ingress replication and downstream assigned inclusive type set to ingress replication, and downstream-assigned Inclusive
multicast MPLS label 17001. Similarly, PE2 announced an Inclusive Multicast MPLS label 17001. Similarly, PE2 announced an Inclusive
Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag
(ISID 10), PMSI tunnel attribute Tunnel type set to ingress (ISID 10), PMSI tunnel attribute Tunnel type set to ingress
replication and downstream assigned inclusive multicast MPLS label replication, and downstream-assigned Inclusive Multicast MPLS label
17002. 17002.
Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for 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. ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc.
44dd.5500. 44dd.5500.
When an operator at PE3 initiates a connectivity check for the When an operator at PE3 initiates a connectivity check for the
inclusive multicast on PE1, the operator initiates an LSP Ping Inclusive Multicast on PE1, the operator initiates an LSP Ping
request with the target FEC stack TLV containing EVPN Inclusive request with the Target FEC Stack TLV containing the EVPN Inclusive
Multicast Sub-TLV in the Echo Request packet. The Echo Request Multicast sub-TLV in the Echo Request packet. The Echo Request
packet is sent with the {Transport Label(s) to reach PE1, EVPN Incl. packet is sent with the {Transport label(s) to reach PE1, EVPN
Multicast Label = 17001, GAL} MPLS label stack and IP ACH Channel Inclusive Multicast label = 17001, GAL} MPLS label stack and IP ACH
header. Once the Echo Request packet reaches PE1, PE1 will use the Channel header. Once the Echo Request packet reaches PE1, PE1 will
GAL and the IP ACH Channel header to determine that the packet is use the GAL and the IP ACH Channel header to determine if the packet
IPv4 or IPv6 OAM Packet. The packet will have EVPN Inclusive is an IPv4 or IPv6 OAM packet. The packet will have the EVPN
multicast label. PE1 will process the packet and perform checks for Inclusive Multicast label. PE1 will process the packet and perform
the EVPN Inclusive Multicast Sub-TLV present in the Target FEC Stack checks for the EVPN Inclusive Multicast sub-TLV present in the Target
TLV as described in Section 4.4 in [RFC8029] and respond according to FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond
[RFC8029] processing rules. For the success case, PE1 will reply according to the processing rules in [RFC8029]. For the success
with Return Code 3 - "Replying router is an egress for the FEC at case, PE1 will reply with Return Code 3 ("Replying router is an
stack-depth". egress for the FEC at stack-depth <RSC>").
Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with Similarly, an operator at PE3 may initiate an LSP Ping to PE2 with
the target FEC stack TLV containing EVPN Inclusive Multicast sub-TLV the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-
in the Echo Request packet. The Echo Request packet is sent with the TLV in the Echo Request packet. The Echo Request packet is sent with
{transport Label(s) to reach PE2, EVPN Incl. Multicast Label = the {Transport label(s) to reach PE2, EVPN Inclusive Multicast label
17002, GAL} MPLS label stack and IP ACH Channel header. Once the = 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 Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH
Channel header to determine that the packet is IPv4 or IPv6 OAM Channel header to determine if the packet is an IPv4 or IPv6 OAM
Packet. The processing on PE2 will be similar to the that on PE1 as packet. The processing on PE2 will be similar to that on PE1 as
described above and for the success case, PE2 will reply with Return described above. For the success case, PE2 will reply with Return
Code 3 - "Replying router is an egress for the FEC at stack-depth" as Code 3 ("Replying router is an egress for the FEC at stack-depth
per [RFC8029]. <RSC>") as per [RFC8029].
In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- In an Echo Request packet for EVPN, a combination of an EVPN Ethernet
TLV and the associated MPLS Split Horizon Label above the GAL in the A-D sub-TLV and the associated MPLS Split Horizon label, immediately
MPLS label stack, may be added to emulate traffic coming from a preceding the GAL in the MPLS label stack, may be used to emulate
multihomed site. The Split Horizon label is used by leaf PE(s) traffic coming from a multihomed site. The Split Horizon label is
attached to the same multihomed site to not forward packets back to used by leaf PE(s) attached to the same multihomed site to prevent
the multihomed site. If the behavior on a leaf PE is to not forward forwarding of packets back to the multihomed site. If the behavior
the packet to the multihomed site on the ESI identified by EVPN on a leaf PE is to not forward the packet to the multihomed site on
Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will the ESI identified by the EVPN Ethernet A-D sub-TLV because of Split
reply with a Return Code indicating that "Replying router is egress Horizon filtering, the PE will reply with Return Code 37 (see
for the FEC at the stack depth. In addition, the BUM packets are Section 8) and drop the BUM packets on the ES corresponding to the
dropped on the ES corresponding to the ESI received in EVPN Ethernet ESI received in the EVPN Ethernet A-D sub-TLV because of the Split
AD Sub-TLV because of the Split Horizon Group filtering" as described Horizon Group filtering.
in Section 8.
6.2.2. Using P2MP P-tree 6.2.2. Using P2MP P-Tree
Both inclusive P-Tree and aggregate inclusive P-tree can be used in Both Inclusive P-tree and Aggregate Inclusive P-tree can be used in
EVPN or PBB-EVPN networks. EVPN or PBB-EVPN networks.
When using an inclusive P-tree arrangement, p2mp p-tree transport When using an Inclusive P-tree arrangement, the P2MP P-tree transport
label itself is used to identify the L2 service associated with the label itself is used to identify the L2 service associated with the
Inclusive Multicast Route, this L2 service could be a customer Inclusive Multicast route. This L2 service could be a Customer
Bridge, or a Provider Backbone Bridge. Bridge or a Provider Backbone Bridge.
For an Inclusive P-tree arrangement, when an operator performs a For an Inclusive P-tree arrangement, when an operator performs a
connectivity check for the multicast L2 service, the operator connectivity check for the multicast L2 service, the operator
initiates an LSP Ping request with the target FEC stack TLV initiates an LSP Ping request with the Target FEC Stack TLV
containing EVPN Inclusive Multicast Sub-TLV in the Echo Request containing the EVPN Inclusive Multicast sub-TLV in the Echo Request
packet. The Echo Request packet is sent over P2MP LSP with the {P2MP 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. P-tree Transport label, GAL} MPLS label stack and IP ACH Channel
header.
When using Aggregate Inclusive P-tree, a PE announces an upstream When using an Aggregate Inclusive P-tree arrangement, a PE announces
assigned MPLS label along with the P-tree ID, so both the p2mp p-tree an upstream-assigned MPLS label along with the P-tree ID, so both the
MPLS transport label and the upstream MPLS label can be used to P2MP P-tree MPLS transport label and the upstream MPLS label can be
identify the L2 service. used to identify the L2 service.
For an Aggregate Inclusive P-tree arrangement, when an operator For an Aggregate Inclusive P-tree arrangement, when an operator
performs a connectivity check for the multicast L2 service, the performs a connectivity check for the multicast L2 service, the
operator initiates an LSP Ping request with the target FEC stack TLV operator initiates an LSP Ping request with the Target FEC Stack TLV
containing EVPN Inclusive Multicast Sub-TLV in the Echo Request containing the EVPN Inclusive Multicast sub-TLV in the Echo Request
packet. The Echo Request packet is sent over P2MP LSP using the IP- packet. The Echo Request packet is sent over P2MP LSP using the IP-
ACH Control channel with the {P2MP P-tree label, EVPN Upstream ACH Control channel with the {P2MP P-tree Transport label, EVPN
assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel upstream-assigned Multicast label, GAL} MPLS label stack and IP ACH
header. Channel header.
The Leaf PE(s) of the p2mp tree will process the packet and perform 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 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 FEC Stack TLV as described in Section 4.4 of [RFC8029] and respond
according to [RFC8029] processing rules. For the success case, the according to the processing rules in [RFC8029]. For the success
Leaf PE will reply with Return Code 3 - "Replying router is an egress case, the leaf PE will reply with Return Code 3 ("Replying router is
for the FEC at stack-depth". an egress for the FEC at stack-depth <RSC>").
In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub- In an Echo Request packet for EVPN, a combination of an EVPN Ethernet
TLV and the associated MPLS Split Horizon Label above the GAL in MPLS A-D sub-TLV and the associated MPLS Split Horizon label, immediately
label stack, may be added to emulate traffic coming from a multihomed preceding the GAL in the MPLS label stack, may be used to emulate
site. In case of p2mp p-tree, the Split Horizon Label is upstream traffic coming from a multihomed site. When using P2MP P-tree, the
assigned and is received by all the leaf PEs of the p2mp-ptree. The Split Horizon label is upstream assigned and is received by all the
Split Horizon label is used by leaf PE(s) attached to the same leaf PEs of the P2MP P-tree. The Split Horizon label is used by leaf
multihomed site not to forward packets back to the multihomed site. PE(s) attached to the same multihomed site so that packets will not
If the behavior on a leaf PE is to not forward the packet to the be forwarded back to the multihomed site. If the behavior on a leaf
multihomed site on the ESI in EVPN Ethernet AD Sub-TLV because of PE is to not forward the packet to the multihomed site on the ESI in
Split Horizon filtering, the PE will reply with a Return Code the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, the
indicating that "Replying router is egress for the FEC at the stack PE will reply with Return Code 37 (see Section 8) and drop the BUM
depth. In addition, the BUM packets are dropped on the ES packets on the ES corresponding to the ESI received in the EVPN
corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because Ethernet A-D sub-TLV because of the Split Horizon Group filtering.
of the Split Horizon Group filtering" as described in Section 8. If If the leaf PE does not have the ESI identified in the EVPN Ethernet
the leaf PE does not have the ESI identified in the EVPN Ethernet AD A-D sub-TLV, the PE MAY reply with Return Code 38 (see Section 8),
Sub-TLV, the PE can reply with a Return Code indicating that and the BUM packets are forwarded because there is no ES
"Replying router is egress for the FEC at the stack depth. In corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV.
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 6.2.3. Controlling Echo Responses When Using P2MP P-Tree
The procedures described in [RFC6425] for preventing congestion of The procedures described in [RFC6425] for preventing congestion of
Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a
single egress node (Node Address P2MP Responder Identifier TLV) can single egress node (P2MP Responder Identifier TLV with either the
be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees IPv4 Node Address P2MP Responder sub-TLV or the IPv6 Node Address
for broadcast, multicast, and unknown unicast traffic. P2MP Responder sub-TLV) can be applied to LSP Ping in EVPN and PBB-
EVPN when using P2MP P-trees for BUM traffic.
6.3. EVPN Aliasing Data-plane connectivity check 6.3. EVPN Aliasing Data Plane Connectivity Check
Assume PE1 announced an Ethernet AD per-EVI Route with the ESI set to Assume PE1 announced an Ethernet A-D per-EVI route with the ESI set
CE1 system ID and MPLS label 19001, and PE2 an Ethernet AD per-EVI to CE1 system ID and MPLS label 19001. Additionally, assume PE2
Route with the ESI set to CE1 system ID and MPLS label 19002. 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 At PE3, when an operator performs a connectivity check for the
aliasing aspect of the EVPN Ethernet AD route on PE1, the operator aliasing aspect of the EVPN Ethernet A-D route on PE1, the operator
initiates an LSP Ping request with the target FEC stack TLV initiates an LSP Ping request with the Target FEC Stack TLV
containing EVPN Ethernet AD Sub-TLV in the Echo Request packet. The containing the EVPN Ethernet A-D sub-TLV in the Echo Request packet.
Echo Request packet is sent with the {Transport label(s) to reach 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 PE1, EVPN Ethernet A-D label 19001, GAL} MPLS label stack and IP ACH
Channel header. Channel header.
When PE1 receives the packet it will process the packet and perform 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 checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC
Stack TLV as described in Section 4.4 in [RFC8029] and respond Stack TLV as described in Section 4.4 of [RFC8029] and respond
according to [RFC8029] processing rules. according to the processing rules in [RFC8029].
6.4. EVPN IP Prefix (RT-5) Data-plane connectivity check 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 Assume PE1 in Figure 5 announced an IP Prefix route (RT-5) with an IP
IP prefix reachable behind CE1 and MPLS label 20001. When an prefix reachable behind CE1 and MPLS label 20001. When an operator
operator on PE3 performs a connectivity check for the IP prefix on on PE3 performs a connectivity check for the IP prefix on PE1, the
PE1, the operator initiates an LSP Ping request with the target FEC operator initiates an LSP Ping request with the Target FEC Stack TLV
stack TLV containing EVPN IP Prefix Sub-TLV in the Echo Request containing the EVPN IP Prefix sub-TLV in the Echo Request packet.
packet. The Echo Request packet is sent with the {Transport label(s) The Echo Request packet is sent with the {Transport label(s) to reach
to reach PE1, EVPN IP Prefix Label 20001 } MPLS label stack. PE1, EVPN IP Prefix label 20001 } MPLS label stack.
When PE1 receives the packet it will process the packet and perform 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 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 TLV as described in Section 4.4 of [RFC8029] and respond according to
[RFC8029] processing rules. the processing rules in [RFC8029].
7. Security Considerations 7. Security Considerations
The proposal introduced in this document does not introduce any new This document does not introduce any new security considerations
security considerations beyond that already apply to [RFC7432], beyond those that apply in [RFC7432], [RFC7623], and [RFC6425].
[RFC7623] and [RFC6425]. Furthermore, the security considerations Furthermore, the security considerations discussed in [RFC8029] apply
discussed in [RFC8029] apply to this document and need to be to this document and need to be considered. As described in
considered. As described in [RFC8029], these security considerations [RFC8029], these security considerations are:
are:
* Denial-of-Service (DoS) attack, by sending MPLS echo requests/ * A Denial-of-Service (DoS) attack by sending MPLS Echo Requests/
replies to LSRs and thereby increasing their workload. Replies to Label Switching Routers (LSRs) and thereby increasing
their workload.
* Obfuscating the state of the MPLS data-plane liveness by spoofing, * Obfuscating the state of the MPLS data plane liveness by spoofing,
hijacking, replaying, or otherwise tampering with MPLS echo hijacking, replaying, or otherwise tampering with MPLS Echo
Requests and replies. Requests and Replies.
* Obtaining information about the network by an unauthorized source * Obtaining information about the network through an unauthorized
using an LSP ping. source using an LSP Ping.
There are mitigations described in [RFC8029]. The same mitigations There are mitigations described in [RFC8029]. The same mitigations
can be applied to the LSP Ping procedures described in this draft and can be applied to the LSP Ping procedures described in this document;
thus this document doesn't require additional security considerations thus, this document doesn't require additional security
beyond the one described in [RFC8029]. considerations beyond the ones described in [RFC8029].
The proposal does not introduce any new privacy concerns because This document does not introduce any new privacy concerns because
these TLVs contain the same information that are present in data these TLVs contain the same information that are present in data
packets and EVPN routes. packets and EVPN routes.
8. IANA Considerations 8. IANA Considerations
8.1. Sub-TLV Type 8.1. Sub-TLV Type
This document defines four new Sub-TLV type to be included in Target This document defines four new sub-TLV types to be included in the
FEC Stack TLV (TLV Type 1, 16 and 21) [RFC9041] in Echo Request and Target FEC Stack TLV (TLV types 1, 16, and 21) [RFC9041] in Echo
Echo Reply messages in EVPN and PBB-EVPN network. Request and Echo Reply messages in EVPN and PBB-EVPN networks.
IANA is requested to assign lowest 4 free values for the four Sub-
TLVs listed below from the Standards Action" (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:
* EVPN MAC/IP Sub-TLV
* EVPN Inclusive Multicast Sub-TLV
* EVPN Auto-Discovery Sub-TLV
* EVPN IP Prefix Sub-TLV 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.
8.2. Proposed new Return Codes +==========+==============================+===========+
| 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 |
+----------+------------------------------+-----------+
[RFC8029] defines values for the Return Code field of Echo Reply. Table 1
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 8.2. New Return Codes
Codes listed below from the Return Codes" registry in the
"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" name space:
* Replying router is egress for the FEC at the stack depth. In [RFC8029] defines values for the Return Code field of Echo Reply
addition, the BUM packets are dropped on the ES corresponding to messages. This document defines two new Return Codes that SHOULD be
the ESI received in EVPN Ethernet AD Sub-TLV because of the Split included in the Echo Reply message by a PE in response to an Echo
Horizon Group filtering. Request message in EVPN and PBB-EVPN networks.
* Replying router is egress for the FEC at the stack depth. In IANA has assigned the following values in the "Return Codes" registry
addition, the BUM packets are forwarded because there is no ES of the "Multiprotocol Label Switching (MPLS) Label Switched Paths
corresponding to the ESI received in EVPN Ethernet AD Sub-TLV. (LSPs) Ping Parameters" name space.
9. Acknowledgments +=======+=============================================+===========+
| Value | Meaning | Reference |
+=======+=============================================+===========+
| 37 | Replying router is egress for the FEC at | RFC 9489 |
| | 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. | |
+-------+---------------------------------------------+-----------+
| 38 | Replying router is egress for the FEC at | RFC 9489 |
| | 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. | |
+-------+---------------------------------------------+-----------+
The authors would like to thank Loa Andersson, Alexander Vainshtein, Table 2
Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Eric Vyncke,
Warren Kumari, Patrice Brissette and Weiguo Hao for their valuable
comments.
10. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
skipping to change at page 20, line 35 skipping to change at line 880
[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad, [RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,
"Updating the MPLS Label Switched Paths (LSPs) Ping "Updating the MPLS Label Switched Paths (LSPs) Ping
Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041, Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
July 2021, <https://www.rfc-editor.org/info/rfc9041>. July 2021, <https://www.rfc-editor.org/info/rfc9041>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>. <https://www.rfc-editor.org/info/rfc9136>.
Acknowledgments
The authors would like to thank Loa Andersson, Alexander Vainshtein,
Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Éric Vyncke,
Warren Kumari, Patrice Brissette, and Weiguo Hao for their valuable
comments.
Authors' Addresses Authors' Addresses
Parag Jain Parag Jain
Cisco Cisco
Canada Canada
Email: paragj@cisco.com Email: paragj@cisco.com
Ali Sajassi Ali Sajassi
Cisco Cisco
United States of America United States of America
 End of changes. 147 change blocks. 
540 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.48.