rfc9489xml2.original.xml   rfc9489.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="utf-8"?>
<!-- $Id: draft-jain-bess-evpn-lsp-ping.xml 2015-07-05 paragj $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
]>
<rfc category="std" docName="draft-ietf-bess-evpn-lsp-ping-11"
ipr="trust200902" updates="">
<?rfc toc="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc sortrefs="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-bess-evpn-lsp-ping-11" number="9489" i pr="trust200902" updates="" obsoletes="" xml:lang="en" tocInclude="true" symRefs ="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.2 -->
<front> <front>
<title abbrev="MPLS OAM for EVPN">LSP-Ping Mechanisms for EVPN and PBB-EVPN< <title abbrev="LSP Ping for EVPN and PBB-EVPN">Label Switched Path (LSP) Ping Me
/title> chanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)</title>
<seriesInfo name="RFC" value="9489"/>
<author fullname="Parag Jain" initials="P." surname="Jain"> <author fullname="Parag Jain" initials="P." surname="Jain">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>paragj@cisco.com</email> <email>paragj@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal> </postal>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Samer Salam" initials="S." surname="Salam"> <author fullname="Samer Salam" initials="S." surname="Salam">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>ssalam@cisco.com</email> <email>ssalam@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Sami Boutros" initials="S." surname="Boutros"> <author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal> </postal>
<email>sboutros@ciena.com</email> <email>sboutros@ciena.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date year="2023" month="November"/>
<date year="2023"/> <area>rtg</area>
<workgroup>bess</workgroup>
<area>Routing</area>
<workgroup>BESS Workgroup</workgroup>
<keyword>EVPN</keyword> <keyword>EVPN</keyword>
<keyword>LSP Ping</keyword> <keyword>LSP Ping</keyword>
<keyword>MPLS OAM</keyword> <keyword>MPLS OAM</keyword>
<abstract> <abstract>
<t>LSP Ping is a widely deployed Operation, Administration, and <t>Label Switched Path (LSP) Ping is a widely deployed Operation, Administ
Maintenance mechanism in MPLS networks. This document describes ration, and
mechanisms for detecting data plane failures using LSP Maintenance (OAM) mechanism in MPLS networks.
Ping in MPLS based Ethernet VPN (EVPN) and Provider Backbone Bridging This document describes mechanisms for detecting data plane failures using LSP
with EVPN (PBB-EVPN) networks.</t> Ping in MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-
EVPN) networks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC7432"/> <name>Introduction</name>
describes MPLS based EVPN technology. An EVPN <t><xref target="RFC7432" format="default"/> describes MPLS-based EVPN
comprises CE(s) connected to PE(s). The PEs provide layer-2 technology. An EVPN comprises one or more Customer Edge devices (CEs) con
EVPN among the CE(s) over the MPLS core infrastructure. In EVPN nected to one or more
networks, the PEs advertise the MAC addresses learned from the locally Provider Edge devices (PEs). The PEs provide Layer 2 (L2) EVPN among the
connected CE(s), along with MPLS Label, to remote PE(s) in the CE(s) over the MPLS core infrastructure. In EVPN networks, the PEs
control plane using multiprotocol BGP <xref target="RFC4760"/>. EVPN enables advertise the Media Access Control (MAC) addresses learned from the
multihoming locally connected CE(s), along with the MPLS label, to remote PE(s)
of CE(s) connected to multiple PEs and load balancing of traffic to in the control plane using multiprotocol BGP <xref target="RFC4760"
and from multihomed CE(s).</t> format="default"/>. EVPN enables multihoming of CE(s) connected to
multiple PEs and load balancing of traffic to and from multihomed
<t><xref target="RFC7623"/> CE(s).</t>
describes the use of Provider Backbone Bridging [802.1ah] <t><xref target="RFC7623" format="default"/> describes the use of
with EVPN. PBB-EVPN maintains the Customer MAC (C-MAC) learning in data plane Provider Backbone Bridging EVPN. PBB-EVPN maintains the Customer
and MAC (C-MAC) learning in the data plane and only advertises Backbone MAC
only advertises Provider Backbone MAC (B-MAC) addresses in control (B-MAC) addresses in a control plane using BGP.</t>
plane using BGP.</t> <t>Procedures for simple and efficient mechanisms to detect data plane
failures using LSP Ping in MPLS networks are well defined in
<t>Procedures for simple and efficient mechanisms to detect data plane <xref target="RFC8029" format="default"/> and <xref target="RFC6425" format="
failures using LSP Ping in MPLS network are well defined in default"/>.
<xref target="RFC8029"/> and <xref target="RFC6425"/>. The basic idea for the LSP Ping mechanism is to send an MPLS Echo Request pac
The basic idea for the LSP Ping mechanism is to send a MPLS Echo Request pack ket
et
along the same data path as data packets belonging to the same Forwarding along the same data path as data packets belonging to the same Forwarding
Equivalent Class (FEC). The Echo Request packet carries the FEC being verifie d Equivalent Class (FEC). The Echo Request packet carries the FEC being verifie d
in the Target FEC Stack TLV <xref target="RFC8029"/>. Once the Echo Request p acket reaches the end of in the Target FEC Stack TLV <xref target="RFC8029" format="default"/>. Once t he Echo Request packet reaches the end of
the MPLS path, it is sent to the control plane of the egress PE. the MPLS path, it is sent to the control plane of the egress PE.
The Echo Request packet contains sufficient information to verify the correct ness The Echo Request packet contains sufficient information to verify the correct ness
of data plane operations and validate data plane against the control plane. of data plane operations and validate the data plane against the control plan
The Egress PE sends the results of the validation in an Echo Reply packet to e.
the The egress PE sends the results of the validation in an Echo Reply packet to
the
originating PE of the Echo Request packet.</t> originating PE of the Echo Request packet.</t>
<t>This document defines procedures to detect data
<t>This document defines procedures to detect data
plane failures using LSP Ping in MPLS networks deploying EVPN and 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 PBB-EVPN. This document defines four new sub-TLVs for the Target FEC Stack TL
with the purpose of identifying the FEC on the Egress PE.</t> V
with the purpose of identifying the FEC on the egress PE.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Specification of Requirements"> <name>Specification of Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here. </t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<dl>
<t>AD: Auto Discovery</t> <dt>A-D:</dt><dd>Auto-Discovery</dd>
<dt>B-MAC:</dt><dd>Backbone MAC</dd>
<t>B-MAC: Backbone MAC Address</t> <dt>BUM:</dt><dd>Broadcast, Unknown Unicast, and Multicast</dd>
<dt>CE:</dt><dd>Customer Edge device</dd>
<t>BUM: Broadcast, Unknown Unicast or Multicast</t> <dt>C-MAC:</dt><dd>Customer MAC</dd>
<dt>DF:</dt><dd>Designated Forwarder</dd>
<t>CE: Customer Edge Device</t> <dt>ES:</dt><dd>Ethernet Segment</dd>
<dt>ESI:</dt><dd>Ethernet Segment Identifier</dd>
<t>C-MAC: Customer MAC Address</t> <dt>EVI:</dt><dd>EVPN Instance Identifier that globally identifies the EVP
N Instance</dd>
<t>DF: Designated Forwarder</t> <dt>EVPN:</dt><dd>Ethernet Virtual Private Network</dd>
<dt>FEC:</dt><dd>Forwarding Equivalent Class</dd>
<t>ES: Ethernet Segment</t> <dt>G-ACh:</dt><dd>Generic Associated Channel</dd>
<dt>GAL:</dt><dd>G-ACh Label</dd>
<t>ESI: Ethernet Segment Identifier</t> <dt>MAC-VRF:</dt><dd>A Virtual Routing and Forwarding table for MAC
addresses on a PE</dd>
<t>EVI: EVPN Instance Identifier that globally identifies the EVPN Instance</ <dt>ND:</dt><dd>Neighbor Discovery</dd>
t> <dt>OAM:</dt><dd>Operations, Administration, and Maintenance</dd>
<dt>P2MP:</dt><dd>Point-to-Multipoint</dd>
<t>EVPN: Ethernet Virtual Private Network</t> <dt>PBB-EVPN:</dt><dd>Provider Backbone Bridging EVPN</dd>
<dt>PE:</dt><dd>Provider Edge device</dd>
<t>FEC: Forwarding Equivalent Classs</t> <dt>VPWS:</dt><dd>Virtual Private Wire Service</dd>
</dl>
<t>G-ACh: Generic Associated Channel</t> </section>
<t>GAL: G-ACh Label</t> <section numbered="true" toc="default">
<name>Target FEC Stack Sub-TLVs</name>
<t>OAM: Operations, Administration, and Maintenance</t> <t>This document introduces four new Target FEC Stack sub-TLVs that
<t>P2MP: Point-to-Multipoint</t>
<t>PBB-EVPN: Provider Backbone Bridge with EVPN</t>
<t>PE: Provider Edge Device</t>
<t>VPWS: Virtual Private Wire Service</t>
</section>
<section title="Proposed Target FEC Stack Sub-TLVs">
<t>This document introduces four new Target FEC Stack Sub-TLVs that
are included in the MPLS Echo Request packet. The Echo Request packets are included in the MPLS Echo Request packet. The Echo Request packets
are used for connectivity check in data plane in EVPN and PBB-EVPN networks. are used for connectivity checks in the data plane in EVPN and PBB-EVPN netwo
The target FEC stack Sub-TLVs MAY be used to validate that an identifier rks.
The Target FEC Stack sub-TLVs <bcp14>MAY</bcp14> be used to validate that an
identifier
for a given EVPN is programmed at the target node.</t> for a given EVPN is programmed at the target node.</t>
<section numbered="true" toc="default">
<name>EVPN MAC/IP Sub-TLV</name>
<t>The EVPN MAC/IP sub-TLV identifies the target MAC, MAC/IP binding for
ARP/ND,
or IP address for an EVI under test at an egress PE.
This sub-TLV is included in the Echo Request sent by an
EVPN/PBB-EVPN PE to a peer PE.</t>
<section title="EVPN MAC/IP Sub-TLV"> <t>The fields of the EVPN MAC/IP sub-TLV are derived from the MAC/IP Adv
<t>The EVPN MAC/IP Sub-TLV identifies the target MAC, MAC/IP binding for A ertisement
RP/ND, route defined in <xref target="RFC7432" sectionFormat="of" section="7.2"/> an
or IP address for an EVPN Instance Identifier (EVI) under test at an egr d have the format
ess PE. shown in <xref target="fig1"/>. The fields of the EVPN MAC/IP sub-TLV should
This Sub-TLV is included in the Echo Request sent by a be set according to the
EVPN/PBB-EVPN PE to a Peer PE.</t> following, which is consistent with <xref target="RFC7432" format="default"/>
and <xref target="RFC7623" format="default"/>:</t>
<ul spacing="normal">
<li>The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLA
N-aware bundle
service <xref target="RFC7432" format="default"/>. For PBB-EVPN, the va
lue of this field is always 0 as
per <xref target="RFC7623" sectionFormat="of" section="5.2"/>.</li>
<li>The Ethernet Segment Identifier field is a 10-octet field. For EVP
N, it is set to 0 for a
single-homed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN,
the Ethernet
Segment Identifier field must be set to either 0 (for single-homed segm
ents or multihomed segments with per-I-SID load balancing) or to MAX-ESI (for mu
ltihomed segments with per-flow load balancing) as
described in <xref target="RFC7623" sectionFormat="of" section="5.2"/>.
</li>
<li>The MAC Addr Len field specifies the MAC length in bits. Only 48-b
it MAC addresses
are supported as this document follows the MAC address length supported
by <xref target="RFC7432" format="default"/>.</li>
<li>The MAC Address field is set to the 6-octet MAC address.</li>
<t>The EVPN MAC/IP Sub-TLV fields are derived from the MAC/IP Advertisemen <li>The IP Address field is optional. When the IP Address field is not
t present,
route defined in Section 7.2 in <xref target="RFC7432"/> and have the format
as
shown in Figure 1. The fields of EVPN MAC/IP Sub-TLV should be set according
to the
following that is consistent with <xref target="RFC7432"/> and <xref target="
RFC7623"/>:</t>
<t><list style="symbols">
<t>The Route Distinguisher (RD) field is a 10-octet field and is set to th
e RD
of the MAC-VRF on the Peer PE.</t>
<t>The Ethernet TAG ID field can be 0 or a valid VLAN ID for EVPN VLAN-awa
re bundle
service <xref target="RFC7432"/>. For PBB-EVPN, the value of this field
is always 0 as
per Section 5.2 of <xref target="RFC7623"/>.</t>
<t>The Ethernet Segment Identifier field is 10-octet field. For EVPN, it i
s set to 0 for
singlehomed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN,
the Ethernet
Segment Identifier field must be set to either 0 (for single-homed segm
ents or multihomed segments with per-I-SID load-balancing) or to MAX-ESI (for mu
ltihomed segments with per-flow load-balancing) as
describe in Section 5.2 in <xref target="RFC7623"/>.</t>
<t>The MAC Addr Len field specifies the MAC length in bits. Only 48 bit MA
C Addresses
are supported as this document follows MAC address length supported by
<xref target="RFC7432"/>.</t>
<t>The MAC Address field is set to the 6-octet MAC address.</t>
<t>The IP Address field is optional. When the IP Address field is not pres
ent,
the IP Addr Len field is set to 0. When the IP Address field is present , the IP Addr Len field is in 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 either set to 32 for IPv4 or 128 for IPv6 address. </t> bits and is set to either 32 for IPv4 addresses or 128 for IPv6 address
<t>The Must Be Zero fields are set to 0. The receiving PE should ignore th es. </li>
e <li>The Must Be Zero fields are set to 0. The receiving PE should igno
Must Be Zero fields. </t> re the
</list></t> Must Be Zero fields. </li>
</ul>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
<t>The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(
s) associated with the MAC/IP advertisement route announced by the egress PE and
the MPLS transport label(s) to reach the egress PE.</t>
<t>In EVPN, MAC/IP Advertisement has multiple personality and it is used for
the following cases: </t>
<t><list style="symbols">
<t>This route with only MAC address and MPLS Label1 is used for populating
MAC-VRF and performing MAC forwarding.</t>
<t>This route with MAC and IP addresses and only MPLS Label1 is used for p
opulating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for pe
rforming MAC forwarding</t>
<t>This route with MAC and IP addresses and both MPLS Label1 and Label2 is
used for populating MAC-VRF and IP-VRF tables as well as for both MAC forwardin
g, and IP forwarding in case of symmetric IRB.</t>
</list></t>
<t>When MPLS Echo Request is sent by an ingress PE, the contents of Echo Requ
est and the egress PE mode of operation (i.e., IRB mode or L2 mode) along with E
VPN MPLS label of the packet, determine which of the above three cases is this E
cho Request for. When the egress PE receives MAC/IP Sub-TLV containing only MAC
address, the egress PE validates the MAC state and forwarding. When the egress
PE receives MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN
label points to a MAC-VRF, then the egress PE validates the MAC state and forwar
ding. If the egress PE is not configured in symmetric IRB mode, it also validate
s ARP/ND state. However, if the EVPN label points to an IP-VRF, then the egress
PE validates IP state and forwarding. Any other combinations, such as the egress
PE receiving MAC/IP Sub-TLV containing only MAC address but with EVPN label poi
nting to an IP-VRF, should be considered invalid and Echo Reply should be sent w
ith the appropriate return code by the egress PE to the ingress PE.</t>
</section>
<section title="EVPN Inclusive Multicast Sub-TLV">
<t>The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN <figure anchor="fig1" title="EVPN MAC/IP Sub-TLV Format">
Inclusive Multicast Tag route defined in <xref target="RFC7432"/> Section 7.3 <artwork align="left" name="" type="" alt=""><![CDATA[
. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS l
abel(s) associated with the MAC/IP Advertisement route announced by the egress P
E and the MPLS transport label(s) to reach the egress PE.</t>
<t>In EVPN, the MAC/IP Advertisement route has multiple uses and is used for
the following cases:</t>
<ul spacing="normal">
<li>This route with only a MAC address and MPLS Label1 is used for pop
ulating MAC-VRF and performing MAC forwarding.</li>
<li>This route with MAC and IP addresses and only MPLS Label1 is used
for populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as f
or performing MAC forwarding.</li>
<li>This route with MAC and IP addresses and both MPLS Label1 and Labe
l2 is used for populating MAC-VRF and IP-VRF tables as well as for both MAC and
IP forwarding in the case of symmetric Integrated Routing and Bridging (IRB).</l
i>
</ul>
<t>When an MPLS Echo Request is sent by an ingress PE, the contents of t
he Echo Request and the egress PE mode of operation (i.e., IRB mode or L2 mode)
along with EVPN MPLS label of the packet determine which of the three cases abov
e this Echo Request is for. When the egress PE receives the EVPN MAC/IP sub-TLV
containing only the MAC address, the egress PE validates the MAC state and forwa
rding. When the egress PE receives the EVPN MAC/IP sub-TLV containing both MAC
and IP addresses and if the EVPN label points to a MAC-VRF, then the egress PE v
alidates the MAC state and forwarding. If the egress PE is not configured in sym
metric IRB mode, it also validates ARP/ND state. However, if the EVPN label poin
ts to an IP-VRF, then the egress PE validates IP state and forwarding.
Any other combinations (e.g., the egress PE receiving
the EVPN MAC/IP sub-TLV containing only the MAC address but with the EVPN lab
el
pointing to an IP-VRF) should be considered invalid,
and the egress PE should send an Echo Reply with the appropriate Return
Code to the ingress PE.</t>
</section>
<section numbered="true" toc="default">
<name>EVPN Inclusive Multicast Sub-TLV</name>
<t>The fields of the EVPN Inclusive Multicast sub-TLV are based on the E
VPN
Inclusive Multicast Tag route defined in <xref target="RFC7432" sectionFormat
="of" section="7.3"/>.
This TLV is included in the Echo Request sent to the EVPN This TLV is included in the Echo Request sent to the EVPN
peer PE by the originator of request to verify the multicast peer PE by the originator of the request to verify the multicast
connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks. connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.
</t> </t>
<t>The EVPN Inclusive Multicast sub-TLV has the format shown in
<t>The EVPN Inclusive Multicast Sub-TLV has the format as shown in <xref target="fig2"/>. The fields of this sub-TLV should be set according to
Figure 2. The fields of this Sub-TLV should be set according to the the
following that is consistent with <xref target="RFC7432"/> and following, which is consistent with <xref target="RFC7432" format="default"/>
<xref target="RFC7623"/>:</t> and
<t><list style="symbols"> <xref target="RFC7623" format="default"/>:</t>
<t>The Route Distinguisher (RD) field is a 10-octet field and is set to th <ul spacing="normal">
e RD <li>The Route Distinguisher (RD) field is a 10-octet field and is set
of the MAC-VRF on the Peer PE.</t> to the RD
<t>For EVPN, the Ethernet TAG ID field can be set to 0 or a valid VLAN ID of the MAC-VRF on the peer PE.</li>
for <li>For EVPN, the Ethernet Tag ID field can be set to 0 or a valid VLA
EVPN VLAN-aware bundle service <xref target="RFC7432"/>. N ID for
For PBB-EVPN, the value of this field is set to Service EVPN VLAN-aware bundle service <xref target="RFC7432" format="default"/
Instance Identifier (I-SID) value as per Section 5.3 of <xref target="R >.
FC7623"/>.</t> For PBB-EVPN, the value of this field is set to the Service
<t>The IP Addr Len field specifies length of the Originating Router's IP A Instance Identifier (I-SID) value as per <xref target="RFC7623" section
ddr field in bits Format="of" section="5.3"/>.</li>
and it is either set to 32 for IPv4 or 128 for IPv6 address.</t> <li>The IP Addr Len field specifies the length of the Originating Rout
<t>The Originating Router's IP Addr field is set to IPv4 or IPv6 address o er's IP Addr field in bits and is set to either 32 for IPv4 addresses or 128 for
f the peer PE.</t> IPv6 addresses.</li>
</list></t> <li>The Originating Router's IP Addr field is set to the IPv4 or IPv6
address of the peer PE.</li>
<figure align="left"> </ul>
<preamble/>
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
<t>Broadcast, unknown unicast or multicast (BUM) traffic can be sent using
ingress replication or P2MP P-tree in EVPN and PBB-EVPN network. In
case of ingress replication, the Echo Request is sent using a label
stack of [Transport label, Inclusive Multicast label] to each egress
PE participating in EVPN or PBB-EVPN. The inclusive multicast label
is the downstream assigned label announced by the egress PE to which
the Echo Request is being sent. The Inclusive Multicast label is the
inner label in the MPLS label stack.</t>
<t>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.</t>
<t>In case of EVPN, to emulate traffic coming from a multihomed
site, an additional EVPN Ethernet Auto-Discovery Sub-TLV in
the Target FEC stack TLV and ESI Split Horizon Group MPLS label as
the bottom label, are also included in the Echo Request packet.
When using P2MP P-tree, the ESI Split Horizon Group MPLS label is
upstream assigned. Please see Section 6.2.2 for operations using
P2MP P-trees.</t>
</section>
<section title="EVPN Ethernet Auto-Discovery Sub-TLV">
<t>The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the
EVPN Ethernet Auto-Discovery route advertisement defined in <xref target="RFC
7432"/>
Section 7.1. EVPN Ethernet AD Sub-TLV applies to only EVPN.</t>
<t>The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3.
The fields of this Sub-TLV should be set according to the
following that is consistent with <xref target="RFC7432"/>:</t>
<t><list style="symbols">
<t>The Route Distinguisher (RD) field is a 10-octet field and is set to th
e RD
of the MAC-VRF on the Peer PE. Please see Section 4.3.2 below for the c
ase when
per-ES AD route is announced with different RDs</t>
<t>The Ethernet TAG ID field can be 0, MAX-ET or a valid VLAN ID as descri
bed in
Section 4.3.1 below.</t>
<t>The Ethernet Segment Identifier field is 10-octet field and is set to 0
for
singlehomed ES or to a valid ESI ID for a multihomed ES.</t>
<t>The Must Be Zero field is set to 0. The receiving PE should ignore the
Must Be Zero field. </t>
</list></t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
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 <figure anchor="fig2" title="EVPN Inclusive Multicast Sub-TLV Format">
<artwork align="left" name="" type="" alt=""><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>BUM traffic can be sent using ingress replication or P2MP P-tree in
EVPN and PBB-EVPN networks. When using ingress replication, the Echo
Request is sent using a label stack of [Transport label, Inclusive
Multicast label] to each egress PE participating in EVPN or
PBB-EVPN. The Inclusive Multicast label is the downstream-assigned
label announced by the egress PE to which the Echo Request is being
sent. The Inclusive Multicast label is the inner label in the MPLS
label stack.</t>
<t>When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is
sent using a P2MP P-tree transport label for the Inclusive P-tree
arrangement or using a label stack of [P2MP P-tree Transport label,
upstream-assigned EVPN Inclusive Multicast label] for the Aggregate
Inclusive P2MP P-tree arrangement as described in <xref target="operations"/>
.</t>
]]></artwork> <t> In an EVPN network, to emulate traffic coming from a multihomed site, an
</figure> additional EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV
and an ESI Split Horizon Group MPLS label as the bottom label are also
included in the Echo Request packet. When using P2MP P-tree, the ESI Split
Horizon Group MPLS label is upstream assigned. Please see <xref
target="p2mp-ptree"/> for operations using P2MP P-trees.</t>
</section>
<section numbered="true" toc="default">
<name>EVPN Ethernet Auto-Discovery (A-D) Sub-TLV</name>
<t>The fields in the EVPN Ethernet A-D sub-TLV are based on the
EVPN Ethernet A-D route advertisement defined in <xref target="RFC7432" secti
onFormat="of" section="7.1"/>. The EVPN Ethernet A-D sub-TLV only applies to EV
PN.</t>
<section title="Ethernet TAG Value"> <t>The EVPN Ethernet A-D sub-TLV has the format shown in <xref target="fig3"/
<t> EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet Se >.
gment (ES) or The fields of this sub-TLV should be set according to the
per-EVI. When an operator performs a connectivity check for the BUM L2 following, which is consistent with <xref target="RFC7432" format="def
service, ault"/>:</t>
Echo Request packet sent, MAY contain EVPN Ethernet AD Sub-TLV to emula <ul spacing="normal">
te traffic <li>The Route Distinguisher (RD) field is a 10-octet field and is set
coming from a multihomed site. In this case, the EVPN Ethernet AD Sub- to the RD
TLV is of the MAC-VRF on the peer PE. Please see <xref target="adroute"/> for
added in per-ES context. When Echo Request packet is sent for the conne the case when a
ctivity per-ES A-D route is announced with different RDs.</li>
check for EVPN Aliasing state, the context for the EVPN Ethernet AD <li>The Ethernet Tag ID field can be 0, MAX-ET, or a valid VLAN ID as
Sub-TLV is per-EVI.</t> described in
<xref target="etagvalue"/>.</li>
<li>The Ethernet Segment Identifier field is a 10-octet field and is s
et to 0 for
a single-homed ES or to a valid ESI ID for a multihomed ES.</li>
<li>The Must Be Zero field is set to 0. The receiving PE should ignore
the
Must Be Zero field. </li>
</ul>
<t>Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, MUST be set ac <figure anchor="fig3" title="EVPN Ethernet A-D Sub-TLV Format">
cording <artwork align="left" name="" type="" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<section anchor="etagvalue" numbered="true" toc="default">
<name>Ethernet Tag Value</name>
<t>The EVPN Ethernet A-D sub-TLV can be sent in the context of per-ES
or per-EVI.
When an operator performs a connectivity check for the BUM L2 service,
an Echo Request packet is sent and <bcp14>MAY</bcp14> contain the EVPN
Ethernet A-D sub-TLV to emulate traffic
coming from a multihomed site. In this case, the EVPN Ethernet A-D sub
-TLV is
added in the per-ES context. When an Echo Request packet is sent for th
e connectivity
check for EVPN Aliasing state, the context for the EVPN Ethernet A-D
sub-TLV is per-EVI.</t>
<t>The Ethernet Tag field value in the EVPN Ethernet A-D sub-TLV <bcp1
4>MUST</bcp14> be set according
to the context:</t> to the context:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>For the per-ES context, the Ethernet Tag field in the sub-TLV <b
<t>For per-ES context, the Ethernet Tag field in the sub-TLV MUST be s cp14>MUST</bcp14> be set to
et to the reserved MAX-ET value <xref target="RFC7432" format="default"/>.</l
the reserved MAX-ET value <xref target="RFC7432"/></t> i>
<t>For per-EVI context, the Ethernet Tag field in the sub-TLV MUST be <li>For the per-EVI context, the Ethernet Tag field in the sub-TLV <
set to bcp14>MUST</bcp14> be set to
the non-reserved value</t> the non-reserved value.</li>
</list></t> </ul>
</section> </section>
<section anchor="adroute" numbered="true" toc="default">
<section title="Per-ES EVPN Auto-Discovery Route with different RDs"> <name>Per-ES EVPN Auto-Discovery Route with Different RDs</name>
<t>Section 8.2 of <xref target="RFC7432"/> specifies that a per-ES EVPN AD <t><xref target="RFC7432" sectionFormat="of" section="8.2"/> specifies
route for that a per-ES EVPN A-D route for
a given multihomed ES, may be advertised more than once with different R a given multihomed ES may be advertised more than once with different RD
D values values
because many EVIs may be associated with the same ES and Route Targets f or all these because many EVIs may be associated with the same ES and Route Targets f or all these
EVIs may not fit in a single BGP Update message. In this case, the RD v alue used EVIs may not fit in a single BGP Update message. In this case, the RD v alue used
in the EVPN Ethernet AD Sub-TLV, MUST be the RD value received for the E in the EVPN Ethernet A-D sub-TLV <bcp14>MUST</bcp14> be the RD value rec
VI in the eived for the EVI in the
per-ES EVPN AD Route.</t> per-ES EVPN A-D route.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="EVPN VPWS"> <name>EVPN VPWS</name>
<t>LSP Ping can also be used to detect data plane failures for the EVP
<t>LSP Ping can also be used to detect data plane failures for EVPN Virtu N VPWS described in <xref target="RFC8214" format="default"/>.
al Private Wire The Echo Request packet carries the EVPN Ethernet A-D sub-TLV with field
Service (VPWS) described in <xref target="RFC8214"/>. s populated from
The Echo Request packet carries EVPN Ethernet AD Sub-TLV with fields pop the EVPN Ethernet A-D per-EVI route announced by the egress PE for the E
ulated from VPN VPWS under test.
the EVPN Ethernet AD per EVI route announced by the egress PE for the EV
PN VPWS under test.
The Echo Request is sent by the ingress The Echo Request is sent by the ingress
PE using the EVPN MPLS label associated with the EVPN Ethernet AD route announced by the PE using the EVPN MPLS label associated with the EVPN Ethernet A-D route announced by the
egress PE and the MPLS transport label(s) to reach the egress PE.</t> egress PE and the MPLS transport label(s) to reach the egress PE.</t>
<t>The egress PE processes the Echo Request packet and performs
<t>The egress PE process the Echo Request packet and perform checks for checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC
the EVPN Ethernet AD Stack TLV as described in <xref target="RFC8029" sectionFormat="of"
Sub-TLV present in the Target FEC Stack TLV as described in Section 4.4 section="4.4"/> and responds according to processing rules in <xref
in <xref target="RFC8029"/> target="RFC8029" format="default"/>. The egress PE can identify
and respond according to <xref target="RFC8029"/> processing rule. that the Echo Request is for the EVPN VPWS instance as EVI
Egress PE can identify that (identified by the RD) for EVPN VPWS is different from EVI assigned
the Echo Request is for EVPN VPWS instance as EVI (identified by the RD) for EVPN. The egress PE will use the information from the EVPN
for EVPN VPWS is different Ethernet A-D sub-TLV in the Target FEC Stack TLV and validate the
from that for EVPN. The egress PE will use the information from the EVPN VLAN state for the EVPN VPWS under test. For the success case, the
Ethernet AD egress PE will reply with Return Code 3 ("Replying router is an
Sub-TLV in the Target FEC Stack TLV and validate the VLAN state for the egress for the FEC at stack-depth &lt;RSC&gt;").</t>
EVPN </section>
VPWS under test. </section>
For the success case, the egress PE will reply <section numbered="true" toc="default">
with Return Code 3 - "Replying router is an egress for the FEC at stack- <name>EVPN IP Prefix Sub-TLV</name>
depth".</t> <t>The EVPN IP Prefix sub-TLV identifies the IP prefix for an EVI under
</section>
</section>
<section title="EVPN IP Prefix Sub-TLV">
<t>The EVPN IP Prefix Sub-TLV identifies the IP Prefix for an EVI under
test at a peer PE.</t> test at a peer PE.</t>
<t>The EVPN IP Prefix sub-TLV fields are derived from the IP Prefix rout
<t>The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix Route e (RT-5)
(RT-5) advertisement defined in <xref target="RFC9136" format="default"/>. Th
advertisement defined in <xref target="RFC9136"/>. This sub-TLV applie is sub-TLV only applies to
s to EVPN.</t>
only EVPN.</t> <t>The EVPN IP Prefix sub-TLV has the format shown in <xref target="fig4
"/>. The
<t>The EVPN IP Prefix Sub-TLV has the format shown in Figure 4. The total length (not shown) of this sub-TLV <bcp14>MUST</bcp14> be eithe
total length (not shown) of this sub-TLV MUST be either 32 bytes (if r 32 bytes (if
IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carrie d). IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carrie d).
The IP prefix and gateway IP address MUST be from the same IP address The IP prefix and gateway IP address <bcp14>MUST</bcp14> be from the s
family, as described in Section 3.1 of <xref target="RFC9136"/>.</t> ame IP address
family, as described in <xref target="RFC9136" sectionFormat="of" sect
<t>The fields of EVPN IP Prefix Sub-TLV should be set according to the ion="3.1"/>.</t>
following that is consistent with <xref target="RFC9136"/>:</t> <t>The fields of the EVPN IP Prefix sub-TLV should be set according to t
<t><list style="symbols"> he
<t>The Route Distinguisher (RD) field is a 10-octet field and is set to th following, which is consistent with <xref target="RFC9136" format="def
e RD ault"/>:</t>
of the IP-VRF on the Peer PE.</t> <ul spacing="normal">
<t>The Ethernet TAG ID field can be 0 or a valid VLAN ID for EVPN VLAN-awa <li>The Route Distinguisher (RD) field is a 10-octet field and is set
re bundle to the RD
service <xref target="RFC7432"/>.</t> of the IP-VRF on the peer PE.</li>
<t>The Ethernet Segment Identifier field is 10-octet field and is set to <li>The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLA
a valid ESI ID if ESI is used as Overlay Index as per Section 3.1 of <x N-aware bundle
ref target="RFC9136"/>. service <xref target="RFC7432" format="default"/>.</li>
Otherwise the Ethernet Segment Identifier field is set to all 0s.</t> <li>The Ethernet Segment Identifier field is a 10-octet field and is se
<t>The IP Prefix Len field specifies the number of bits in the IP Prefix f t to
ield. It a valid ESI ID if the ESI is used as an Overlay Index as per <xref targ
is set to between 0 and 32 for IPv4 or between 0 to 128 for IPv6.</t> et="RFC9136" sectionFormat="of" section="3.1"/>.
<t>The IP prefix field is set to a 4-octet IPv4 address (with Otherwise, the Ethernet Segment Identifier field is set to 0.</li>
trailing 0 bits to make 32 bits in all) or 16-octet IPv6 address <li>The IP Prefix Len field specifies the number of bits in the IP Pre
fix field. It
is set to a value between 0 and 32 for IPv4 or between 0 to 128 for IPv6
.</li>
<li>The IP Prefix field is set to a 4-octet IPv4 address (with
trailing 0 bits to make 32 bits in all) or a 16-octet IPv6 address
(with trailing 0 bits to make 128 bits in all). The address family (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 of this field is inferred from the sub-TLV length field, as
discussed above.</t> discussed above.</li>
<t> The Gateway (GW) IP Address field is set to a 4-octet IPv4 address <li> The Gateway (GW) IP Address field is set to a 4-octet IPv4 addres
or 16-octet IPv6 address if it's used as an Overlay Index for the s
or a 16-octet IPv6 address if it's used as an Overlay Index for the
IP prefixes. If the GW IP Address is not being used, it must be IP prefixes. If the GW IP Address is not being used, it must be
set to 0 as described in Section 3.1 of <xref target="RFC9136"/>. The a ddress set to 0 as described in <xref target="RFC9136" sectionFormat="of" sect ion="3.1"/>. 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.</t> discussed above.</li>
<t>The Must Be Zero field is set to 0. The receiving PE should ignore th <li>The Must Be Zero field is set to 0. The receiving PE should ignore
e the
Must Be Zero field. </t> Must Be Zero field. </li>
</ul>
</list></t>
<figure align="left">
<preamble/>
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
<t>The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label <figure anchor="fig4" title="EVPN IP Prefix Sub-TLV Format">
(s) <artwork align="left" name="" type="" alt=""><![CDATA[
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS l
abel(s)
associated with the IP Prefix route announced by the egress PE and the MPLS associated with the IP Prefix route announced by the egress PE and the MPLS
transport label(s) to reach the egress PE.</t> transport label(s) to reach the egress PE.</t>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Encapsulation of OAM Ping Packets</name>
<section title="Encapsulation of OAM Ping Packets"> <t>The MPLS Echo Request IP/UDP packets <bcp14>MUST</bcp14> be encapsulate
<t>The MPLS Echo Request IP/UDP packets MUST be encapsulated d
with the Transport and EVPN Label(s) followed by the Generic Associated with the Transport and EVPN label(s) followed by the
Channel Label (GAL) <xref target="RFC5586"/> which is the bottom most l GAL <xref target="RFC5586" format="default"/>, which is the bottommost
abel. label.
The GAL is followed by a Generic Associated Channel Header carrying The GAL is followed by a G-ACh header carrying the
IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 and IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 and
IPv6 channels are defined in Generic Associated Channel (G-ACh) Paramet IPv6 channels are defined in the "Generic Associated Channel (G-ACh) Pa
ers rameters" IANA registry.</t>
by IANA.</t>
</section> </section>
<section anchor="operations" numbered="true" toc="default">
<section title="Operations"> <name>Operations</name>
<section numbered="true" toc="default">
<section title="Unicast Data-plane connectivity checks"> <name>Unicast Data Plane Connectivity Checks</name>
<t>Figure 5 is an example of a PBB-EVPN network. CE1 is dual-homed to <t><xref target="fig5"/> is an example of a PBB-EVPN network. CE1 is dua
PE1 and PE2. Assume, PE1 announced a MAC route with RD 192.0.2.1:00 and l-homed to
PE1 and PE2. Assume that PE1 announced a MAC route with RD 192.0.2.1:00 and
B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. Similarly, B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. Similarly,
PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00-AA-00-BB-00-CC PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00-AA-00-BB-00-CC
and with MPLS label 16002.</t> and with MPLS label 16002.</t>
<t>On PE3, when an operator performs a connectivity check for the B-MAC
<t>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-TLV in
the Echo Request packet. The Echo Request packet is sent with the the Echo Request packet. The Echo Request packet is sent with the
{Transport Label(s) to reach PE1, EVPN Label = 16001, GAL} MPLS label {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, stack and IP ACH Channel header. Once the Echo Request packet reaches PE1,
PE1 will use the GAL and the IP ACH Channel header 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 process to determine if the packet is an IPv4 or IPv6 OAM packet. The PE1 will process
the the
packet and perform checks for the EVPN MAC Sub-TLV present in 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 <xref target="RFC8029"/> a Target FEC Stack TLV as described in <xref target="RFC8029" sectionFormat="of"
nd section="4.4"/> and
respond according to <xref target="RFC8029"/> processing rules.</t> respond according to the processing rules in <xref target="RFC8029" format="de
<figure align="left"> fault"/>.</t>
<preamble/>
<artwork align="left"><![CDATA[
+-----------------+
| |
| |
+----+ AC1 +-----+ +-----+ +----+
| CE1|------| | | PE3 |-----| CE2|
+----+\ | PE1 | IP/MPLS | | +----+
\ +-----+ Network +-----+
\ | |
AC2\ +-----+ |
\ | | |
\| PE2 | |
+-----+ |
| |
+-----------------+
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 5: PBB-EVPN network
]]></artwork> <figure anchor="fig5" title="PBB-EVPN Network">
</figure> <artwork align="left" name="" type="" alt=""><![CDATA[
+-----------------+
| |
| |
+----+ AC1 +-----+ +-----+ +----+
| CE1|------| | | PE3 |-----| CE2|
+----+\ | PE1 | IP/MPLS | | +----+
\ +-----+ Network +-----+
\ | |
AC2\ +-----+ |
\ | | |
\| PE2 | |
+-----+ |
| |
+-----------------+
<t>Similarly, on PE3, when an operator performs a connectivity check for <-802.1Q-> <------PBB over MPLS------> <-802.1Q->
]]></artwork></figure>
<t>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 MAC/IP
Sub-TLV in the Echo Request packet. The Echo Request packet is sent 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} with the {MPLS Transport label(s) to reach PE2, EVPN label = 16002, GAL}
MPLS label stack and IP ACH Channel header.</t> MPLS label stack and IP ACH Channel header.</t>
<t>LSP Ping operations for unicast data plane connectivity checks in EVP
<t>LSP Ping operation for unicast data plane connectivity checks in EVPN, N
are similar to those described above for PBB-EVPN except that the are similar to those described above for PBB-EVPN, except that the
checks are for C-MAC addresses instead of B-MAC addresses.</t> checks are for C-MAC addresses instead of B-MAC addresses.</t>
<t> In EVPN networks, an operator can also perform a MAC state test usin
<t> In EVPN network, an operator can also perform MAC state test using aliasin g an aliasing
g
label for the MAC to verify the MAC state on the egress multihoming PE that did label for the MAC to verify the MAC state on the egress multihoming PE that did
not learn the MAC from the multihomed CE on a local ESI but has announced Et hernet not learn the MAC from the multihomed CE on a local ESI but has announced Et hernet
AD per-EVI and per-ESI routes for the ESI. This is due to the fact that A-D per-EVI and per-ESI routes for the ESI. This is due to the fact that
MAC state on multihoming PEs that did not learn the MAC locally, get created MAC state on multihoming PEs that did not learn the MAC locally get created
from EVPN MAC/IP route advertisement from the multihoming PE that has from EVPN MAC/IP route advertisement from the multihoming PE that has
learned the CE's MAC address locally. learned the CE's MAC address locally.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Inclusive Multicast Data Plane Connectivity Checks</name>
<section title="Inclusive Multicast Data-plane Connectivity Checks"> <section numbered="true" toc="default">
<name>Ingress Replication</name>
<section title="Ingress Replication"> <t>Assume PE1 announced an Inclusive Multicast route for EVI 10, with
<t>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 RD 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 (ISID Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag (ISID
10), PMSI tunnel attribute Tunnel type set to ingress replication 10), PMSI tunnel attribute Tunnel type set to ingress replication,
and downstream assigned inclusive multicast MPLS label 17002.</t> and downstream-assigned Inclusive Multicast MPLS label 17002.</t>
<t>Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF
<t>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. for ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc.
44dd.5500.</t> 44dd.5500.</t>
<t>When an operator at PE3 initiates a connectivity check for the
<t>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 the EVPN Inclusive
request with the target FEC stack TLV containing 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
packet is sent with the {Transport Label(s) to reach PE1, EVPN Inclusive Multicast label = 17001, GAL} MPLS label stack and IP ACH Channel h
Incl. Multicast Label = 17001, GAL} MPLS label stack and IP ACH Channel heade eader.
r.
Once the Echo Request packet reaches PE1, Once the Echo Request packet reaches PE1,
PE1 will use the GAL and the IP ACH Channel header PE1 will use the GAL and the IP ACH Channel header
to determine that the packet is IPv4 or IPv6 OAM Packet. to determine if the packet is an IPv4 or IPv6 OAM packet.
The packet will have EVPN Inclusive multicast label. The packet will have the EVPN Inclusive Multicast label.
PE1 will process the packet and perform checks for the EVPN PE1 will process the packet and perform checks for the EVPN
Inclusive Multicast Sub-TLV present in the Target FEC Stack TLV as Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as
described in Section 4.4 in <xref target="RFC8029"/> and respond according to described in <xref target="RFC8029" sectionFormat="of" section="4.4"/> and re
<xref target="RFC8029"/> processing rules. For the success case, PE1 will rep spond according to
ly the processing rules in <xref target="RFC8029" format="default"/>. For the su
with Return Code 3 - "Replying router is an egress for the FEC at stack-depth ccess case, PE1 will reply
". </t> with Return Code 3 ("Replying router is an egress for the FEC at stack-depth
&lt;RSC&gt;"). </t>
<t>Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with <t>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 the Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in t
he
Echo Request packet. The Echo Request packet is sent with Echo Request packet. The Echo Request packet is sent with
the {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. 17002, GAL} MPLS label stack and IP ACH Channel header.
Once the Echo Request packet reaches PE2, Once the Echo Request packet reaches PE2,
PE2 will use the GAL and the IP ACH Channel header PE2 will use the GAL and the IP ACH Channel header
to determine that the packet is IPv4 or IPv6 OAM Packet. The processing on PE to determine if the packet is an IPv4 or IPv6 OAM packet. The processing on P
2 will be similar E2 will be similar
to the that on PE1 as described above and for the success case, PE2 will to that on PE1 as described above. For the success case, PE2 will
reply with Return Code 3 - "Replying reply with Return Code 3 ("Replying
router is an egress for the FEC at stack-depth" as per <xref target="RFC8029" router is an egress for the FEC at stack-depth &lt;RSC&gt;") as per <xref tar
/>.</t> get="RFC8029" format="default"/>.</t>
<t>In an Echo Request packet for EVPN, a combination of an EVPN
<t>In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-TLV Ethernet A-D sub-TLV and the associated MPLS Split Horizon label,
and the associated MPLS Split Horizon Label above the GAL in the immediately preceding the GAL in the MPLS label stack, may be used
MPLS label stack, may be added to emulate traffic coming from a multihomed to emulate traffic coming from a multihomed site. The Split Horizon
site. The Split Horizon label is used by leaf PE(s) attached to the same mult label is used by leaf PE(s) attached to the same multihomed site to
ihomed site prevent forwarding of packets back to the multihomed site. If the
to not forward packets back to the multihomed site. behavior on a leaf PE is to not forward the packet to the multihomed
If the behavior on a leaf PE is to not forward the packet to the multihomed s site on the ESI identified by the EVPN Ethernet A-D sub-TLV because
ite of Split Horizon filtering, the PE will reply with Return Code 37 (see
on the ESI identified by EVPN Ethernet AD Sub-TLV because of Split Horizon fi <xref target="iana"/>) and drop the BUM packets on the ES corresponding to the
ltering, ESI received in the EVPN
the PE will reply with a Return Code indicating that "Replying router is egre Ethernet A-D sub-TLV because of the Split Horizon Group filtering.</t>
ss </section>
for the FEC at the stack depth. In addition, the BUM packets are dropped on t <section anchor="p2mp-ptree" numbered="true" toc="default">
he ES <name>Using P2MP P-Tree</name>
corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because of the <t>Both Inclusive P-tree and Aggregate Inclusive P-tree can be used in
Split
Horizon Group filtering" as described in Section 8.</t>
</section>
<section title="Using P2MP P-tree">
<t>Both inclusive P-Tree and aggregate inclusive P-tree can be used in
EVPN or PBB-EVPN networks.</t> EVPN or PBB-EVPN networks.</t>
<t>When using an Inclusive P-tree arrangement, the P2MP P-tree transpo
<t>When using an inclusive P-tree arrangement, p2mp p-tree transport rt
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.</t> Bridge or a Provider Backbone Bridge.</t>
<t>For an Inclusive P-tree arrangement, when an operator performs a
<t>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 packet. The Echo Request packet is sent over P2MP LSP
with the {P2MP P-tree label, GAL} with the {P2MP P-tree Transport label, GAL}
MPLS label stack and IP ACH Channel header.</t> MPLS label stack and IP ACH Channel header.</t>
<t>When using an Aggregate Inclusive P-tree arrangement, a PE announce
<t>When using Aggregate Inclusive P-tree, a PE announces an upstream s an upstream-assigned MPLS label along with the P-tree ID, so both the
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
p2mp p-tree MPLS transport label and the upstream MPLS label can be
used to identify the L2 service.</t> used to identify the L2 service.</t>
<t>For an Aggregate Inclusive P-tree arrangement, when an operator
<t>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 packet. The Echo Request packet is sent over P2MP LSP using the
IP-ACH Control channel with the {P2MP P-tree label, IP-ACH Control channel with the {P2MP P-tree Transport label,
EVPN Upstream assigned Multicast Label, GAL} MPLS label stack and EVPN upstream-assigned Multicast label, GAL} MPLS label stack and
IP ACH Channel header.</t> IP ACH Channel header.</t>
<t>The Leaf PE(s) of the p2mp tree will process the packet and perform <t>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 checks for the EVPN Inclusive Multicast sub-TLV present in the
Target FEC Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> a Target FEC Stack TLV as described in <xref target="RFC8029" sectionFormat="of"
nd section="4.4"/> and
respond according to <xref target="RFC8029"/> processing rules. respond according to the processing rules in <xref target="RFC8029" format="de
For the success case, the Leaf PE will reply with Return Code 3 - fault"/>.
"Replying router is an egress for the FEC at stack-depth".</t> For the success case, the leaf PE will reply with Return Code 3
("Replying router is an egress for the FEC at stack-depth &lt;RSC&gt;").</t>
<t>In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-TLV <t>In an Echo Request packet for EVPN, a combination of an EVPN
and the associated MPLS Split Horizon Label above the GAL in Ethernet A-D sub-TLV and the associated MPLS Split Horizon label,
MPLS label stack, may be added to emulate traffic coming from a multihomed immediately preceding the GAL in the MPLS label stack, may be used
site. In case of p2mp p-tree, the Split Horizon Label is upstream assigned to emulate traffic coming from a multihomed site. When using P2MP
and is received by all the leaf PEs of the p2mp-ptree. P-tree, the Split Horizon label is upstream assigned and is received
by all the leaf PEs of the P2MP P-tree. The Split Horizon label is
The Split Horizon label is used by leaf PE(s) attached to used by leaf PE(s) attached to the same multihomed site so that
the same multihomed site not to forward packets back to the multihomed site. I packets will not be forwarded back to the multihomed site. If the
f the behavior on a leaf PE is to not forward the packet to the multihomed
behavior on a leaf PE is to not forward the packet to the multihomed site site on the ESI in the EVPN Ethernet A-D sub-TLV because of Split
on the ESI in EVPN Ethernet AD Sub-TLV because of Split Horizon filtering, Horizon filtering, the PE will reply with Return Code 37 (see <xref ta
the PE will reply with a Return Code indicating that "Replying router is egres rget="iana"/>) and drop the BUM packets on the ES
s corresponding to the ESI received in the EVPN Ethernet A-D sub-TLV
for the FEC at the stack depth. In addition, the BUM packets are dropped on th because of the Split Horizon Group filtering.
e ES
corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because of the S
plit
Horizon Group filtering" as described in Section 8. If the leaf PE does not ha
ve
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".
</t>
</section>
<section title="Controlling Echo Responses when using P2MP P-tree"> If the leaf PE does not have the ESI identified in the
<t>The procedures described in [RFC6425] for preventing congestion of EVPN Ethernet A-D sub-TLV, the PE <bcp14>MAY</bcp14> reply with Return
Code 38 (see <xref target="iana"/>), and the BUM packets are forwarded
because there is no ES corresponding to the
ESI received in the EVPN Ethernet A-D sub-TLV.</t>
</section>
<section numbered="true" toc="default">
<name>Controlling Echo Responses When Using P2MP P-Tree</name>
<t>The procedures described in <xref target="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
IPv4 Node Address P2MP Responder sub-TLV or the IPv6 Node Address P2MP
Responder sub-TLV) can
be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees
for broadcast, multicast, and unknown unicast traffic.</t> for BUM traffic.</t>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>EVPN Aliasing Data Plane Connectivity Check</name>
<section title="EVPN Aliasing Data-plane connectivity check"> <t>Assume PE1 announced an Ethernet A-D per-EVI route with the ESI
<t>Assume PE1 announced an Ethernet AD per-EVI Route with the ESI set to CE1 system ID and MPLS label 19001. Additionally, assume PE2 announced
set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet AD per-EVI Rou an Ethernet A-D per-EVI route
te
with the ESI set to CE1 system ID and MPLS label 19002.</t> with the ESI set to CE1 system ID and MPLS label 19002.</t>
<t>At PE3, when an operator performs a connectivity check for the
<t>At PE3, when an operator performs a connectivity check for the aliasing aspect of the EVPN Ethernet A-D route on PE1, the operator
aliasing aspect of the EVPN Ethernet AD 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 the EVPN Ethernet A-D sub-TLV in the Echo Request packet. The
containing EVPN Ethernet AD Sub-TLV in the Echo Request packet. The
Echo Request packet is sent with the {Transport label(s) to reach Echo Request packet is sent with the {Transport label(s) to reach
PE1, EVPN Ethernet AD Label 19001, GAL} MPLS label stack and PE1, EVPN Ethernet A-D label 19001, GAL} MPLS label stack and
IP ACH Channel header.</t> IP ACH Channel header.</t>
<t>When PE1 receives the packet, it will process the packet and perform
<t>When PE1 receives the packet it will process the packet and perform checks for the EVPN Ethernet A-D sub-TLV present in the Target FEC
checks for the EVPN Ethernet AD Sub-TLV present in the Target FEC Stack TLV as described in <xref target="RFC8029" sectionFormat="of" section="
Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> and respond 4.4"/> and respond
according to <xref target="RFC8029"/> processing rules.</t> according to the processing rules in <xref target="RFC8029" format="default"/
>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="EVPN IP Prefix (RT-5) Data-plane connectivity check"> <name>EVPN IP Prefix (RT-5) Data Plane Connectivity Check</name>
<t>Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an IP pre <t>Assume PE1 in <xref target="fig5"/> announced an IP Prefix route (RT-
fix 5) with an IP prefix
reachable behind CE1 and MPLS label 20001. When an operator on PE3 performs a reachable behind CE1 and MPLS label 20001. When an operator on PE3 performs a
connectivity check for the IP prefix on PE1, the operator connectivity check for the IP prefix 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 IP Prefix Sub-TLV in the Echo Request packet. The containing the EVPN IP Prefix sub-TLV in the Echo Request packet. The
Echo Request packet is sent with the {Transport label(s) to reach Echo Request packet is sent with the {Transport label(s) to reach
PE1, EVPN IP Prefix Label 20001 } MPLS label stack.</t> PE1, EVPN IP Prefix label 20001 } MPLS label stack.</t>
<t>When PE1 receives the packet, it will process the packet and perform
<t>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
checks for the EVPN IP Prefix Sub-TLV present in the Target FEC Stack TLV as described in <xref target="RFC8029" sectionFormat="of" section="
Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> and respond 4.4"/> and respond
according to <xref target="RFC8029"/> processing rules.</t> according to the processing rules in <xref target="RFC8029" format="default"/
>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t> The proposal introduced in this document does not introduce any new <t> This document does not introduce any new
security considerations beyond that already apply to security considerations beyond those that apply in
<xref target="RFC7432"/>, <xref target="RFC7432" format="default"/>,
<xref target="RFC7623"/> and <xref target="RFC7623" format="default"/>, and
<xref target="RFC6425"/>. <xref target="RFC6425" format="default"/>.
Furthermore, the security considerations Furthermore, the security considerations
discussed in <xref target="RFC8029"/> apply to this document and need discussed in <xref target="RFC8029" format="default"/> apply to this d
to be ocument and need to be
considered. As described in <xref target="RFC8029"/>, these security c considered. As described in <xref target="RFC8029" format="default"/>,
onsiderations these security considerations
are: are:
<t><list style="symbols"> </t>
<t>Denial-of-Service (DoS) attack, by sending MPLS echo <ul spacing="normal">
requests/replies to LSRs and thereby increasing their workload.< <li>A Denial-of-Service (DoS) attack by sending MPLS Echo
/t> Requests/Replies to Label Switching Routers (LSRs) and thereby i
<t>Obfuscating the state of the MPLS data-plane liveness by spoofi ncreasing their workload.</li>
ng, <li>Obfuscating the state of the MPLS data plane liveness by spoofing,
hijacking, replaying, or otherwise tampering with MPLS echo Req hijacking, replaying, or otherwise tampering with MPLS Echo Req
uests uests
and replies.</t> and Replies.</li>
<t>Obtaining information about the network by an unauthorized sour <li>Obtaining information about the network through an unauthorized sour
ce ce
using an LSP ping.</t> using an LSP Ping.</li>
</list></t> </ul>
<t> There are mitigations described in <xref target="RFC8029" format="defa
<t> There are mitigations described in <xref target="RFC8029"/>. Th ult"/>. The same mitigations
e same mitigations can be applied to the LSP Ping procedures described in this document
can be applied to the LSP Ping procedures described in this draft an ; thus, this document
d thus this document doesn't require additional security considerations beyond the ones d
doesn't require additional security considerations beyond the one de escribed
scribed in <xref target="RFC8029" format="default"/>.</t>
in <xref target="RFC8029"/>.</t> <t> This document does not introduce any new privacy concerns because thes
e TLVs contain the same information that are present in data packets and EVPN ro
<t> The proposal does not introduce any new privacy concerns because utes.
these TLVs contain the same information that are present in data packets and EV
PN routes.
</t>
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<section numbered="true" toc="default">
<section title="Sub-TLV Type"> <name>Sub-TLV Type</name>
<t> This document defines four new sub-TLV types to be included in the
<t> This document defines four new Sub-TLV type to be included in Target Target
FEC Stack TLV (TLV Type 1, 16 and 21) <xref target="RFC9041"/> in Echo Reques FEC Stack TLV (TLV types 1, 16, and 21) <xref target="RFC9041" format="defaul
t and Echo t"/> in Echo Request and Echo
Reply messages in EVPN and PBB-EVPN network.</t> Reply messages in EVPN and PBB-EVPN networks.</t>
<t>IANA has assigned the following values
<t>IANA is requested to assign lowest 4 free values for the four Sub-TLVs lis from the "Standards Action" (0-16383) range in the "Sub-TLVs for TLV
ted below Types 1, 16, and 21" subregistry within the "TLVs" registry of the
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) "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" name space: </t> Ping Parameters" name space. </t>
<t><list style="symbols">
<t>EVPN MAC/IP Sub-TLV </t>
<t>EVPN Inclusive Multicast Sub-TLV </t>
<t>EVPN Auto-Discovery Sub-TLV</t>
<t>EVPN IP Prefix Sub-TLV </t>
</list></t>
</section>
<section title="Proposed new Return Codes"> <table anchor="iana1">
<name></name>
<thead>
<tr>
<th>Sub-Type</th>
<th>Sub-TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>42</td>
<td>EVPN MAC/IP</td>
<td>RFC 9489</td>
</tr>
<tr>
<td>43</td>
<td>EVPN Inclusive Multicast</td>
<td>RFC 9489</td>
</tr>
<tr>
<td>44</td>
<td>EVPN Ethernet Auto-Discovery</td>
<td>RFC 9489</td>
</tr>
<tr>
<td>45</td>
<td>EVPN IP Prefix</td>
<td>RFC 9489</td>
</tr>
</tbody>
</table>
<t><xref target="RFC8029"/> defines values for the Return Code field of Echo </section>
Reply. <section numbered="true" toc="default">
This document proposes two new Return Codes, which SHOULD be <name>New Return Codes</name>
<t><xref target="RFC8029" format="default"/> defines values for the Retu
rn Code field of Echo Reply messages.
This document defines two new Return Codes that <bcp14>SHOULD</bcp14> be
included in the Echo Reply message by a PE in response to included in the Echo Reply message by a PE in response to
Echo Request message in EVPN and PBB-EVPN network. </t> an Echo Request message in EVPN and PBB-EVPN networks. </t>
<t> IANA has assigned the following values in the "Return Codes"
<t> IANA is requested to assign 2 lowest free values for the 2 Return Codes l registry of the "Multiprotocol Label Switching (MPLS) Label Switched
isted below from the Return Codes" registry in the "Multiprotocol Label Switchi Paths (LSPs) Ping Parameters" name space.</t>
ng (MPLS) Label
Switched Paths (LSPs) Ping Parameters" name space:</t>
<t><list style="symbols">
<t>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 Su
b-TLV because of
the Split Horizon Group filtering.</t>
<t>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-T
LV.</t>
</list></t>
</section>
</section>
<section title="Acknowledgments"> <table anchor="iana2">
<t>The authors would like to thank Loa Andersson, Alexander Vainshtein, <name></name>
Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Eric Vyncke, Warr <thead>
en Kumari, <tr>
Patrice Brissette and Weiguo Hao for their valuable comments.</t> <th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>37</td>
<td>Replying router is egress for the FEC at the stack depth. In
addition, the BUM packets are dropped on the ES corresponding to the ESI
received in the EVPN Ethernet Auto-Discovery sub-TLV because of the Split
Horizon Group
filtering.</td>
<td>RFC 9489</td>
</tr>
<tr>
<td>38</td>
<td>Replying router is egress for the FEC at the stack depth. In
addition, the BUM packets are forwarded because there is no ES
corresponding to the ESI received in the EVPN Ethernet Auto-Discovery sub-
TLV.</td>
<td>RFC 9489</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<name>Normative References</name>
<?rfc include="reference.RFC.2119"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
<?rfc include="reference.RFC.4760"?> 9.xml"/>
<?rfc include="reference.RFC.8174"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.476
<?rfc include="reference.RFC.7623"?> 0.xml"/>
<?rfc include="reference.RFC.8029"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
<?rfc include="reference.RFC.6425"?> 4.xml"/>
<?rfc include="reference.RFC.5586"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.762
<?rfc include="reference.RFC.7432"?> 3.xml"/>
<?rfc include="reference.RFC.9136"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.802
<?rfc include="reference.RFC.8214"?> 9.xml"/>
<?rfc include="reference.RFC.9041"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.642
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.558
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.743
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.913
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.821
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.904
1.xml"/>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Loa Andersson"/>,
<contact fullname="Alexander Vainshtein"/>, <contact fullname="Ron
Sdayoor"/>, <contact fullname="Jim Guichard"/>, <contact fullname="Lars
Eggert"/>, <contact fullname="John Scudder"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Warren Kumari"/>, <contact
fullname="Patrice Brissette"/>, and <contact fullname="Weiguo Hao"/> for
their valuable comments.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 110 change blocks. 
871 lines changed or deleted 791 lines changed or added

This html diff was produced by rfcdiff 1.48.