<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-jain-bess-evpn-lsp-ping.xml 2015-07-05 paragj $ --> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<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" ipr="trust200902" updates="">
  <?rfc toc="yes" ?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <?rfc sortrefs="yes" ?> updates="" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 3.17.2 -->
  <front>
<title abbrev="MPLS OAM abbrev="LSP Ping for EVPN">LSP-Ping EVPN and PBB-EVPN">Label Switched Path (LSP) Ping Mechanisms for EVPN and PBB-EVPN</title> Provider Backbone Bridging EVPN (PBB-EVPN)</title>
    <seriesInfo name="RFC" value="9489"/>
    <author fullname="Parag Jain" initials="P." surname="Jain">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>
          <country>Canada</country>
        </postal>
        <email>paragj@cisco.com</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author fullname="Samer Salam" initials="S." surname="Salam">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>
          <country>Canada</country>
        </postal>
        <email>ssalam@cisco.com</email>
      </address>
    </author>
    <author fullname="Sami Boutros" initials="S." surname="Boutros">
      <organization>Ciena</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>sboutros@ciena.com</email>
      </address>
    </author>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date year="2023"/>

    <area>Routing</area>

    <workgroup>BESS Workgroup</workgroup> year="2023" month="November"/>
    <area>rtg</area>
    <workgroup>bess</workgroup>
    <keyword>EVPN</keyword>
    <keyword>LSP Ping</keyword>
    <keyword>MPLS OAM</keyword>
    <abstract>
   <t>LSP
      <t>Label Switched Path (LSP) Ping is a widely deployed Operation, Administration, and
   Maintenance (OAM) mechanism in MPLS networks.
This document describes mechanisms for detecting data plane failures using LSP
Ping in MPLS based MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging
   with EVPN (PBB-EVPN) networks.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC7432"/> target="RFC7432" format="default"/> describes MPLS based MPLS-based EVPN
      technology.  An EVPN comprises CE(s) one or more Customer Edge devices (CEs) connected to PE(s). one or more
      Provider Edge devices (PEs). The PEs provide layer-2 Layer 2 (L2) EVPN among the
      CE(s) over the MPLS core infrastructure.  In EVPN networks, the PEs
      advertise the MAC Media Access Control (MAC) addresses learned from the
      locally connected CE(s), along with the MPLS Label, label, to remote PE(s)
      in the control plane using multiprotocol BGP <xref target="RFC4760"/>. target="RFC4760"
      format="default"/>. EVPN enables multihoming of CE(s) connected to
      multiple PEs and load balancing of traffic to and from multihomed
      CE(s).</t>
      <t><xref target="RFC7623"/> target="RFC7623" format="default"/> describes the use of
      Provider Backbone Bridging [802.1ah]
   with EVPN. PBB-EVPN maintains the Customer
      MAC (C-MAC) learning in the data plane and only advertises Provider Backbone MAC
      (B-MAC) addresses in a control plane using BGP.</t>
      <t>Procedures for simple and efficient mechanisms to detect data plane
   failures using LSP Ping in MPLS network networks are well defined in
   <xref target="RFC8029"/> target="RFC8029" format="default"/> and <xref target="RFC6425"/>. target="RFC6425" format="default"/>.
   The basic idea for the LSP Ping mechanism is to send a an MPLS Echo Request packet
   along the same data path as data packets belonging to the same Forwarding
   Equivalent Class (FEC). The Echo Request packet carries the FEC being verified
   in the Target FEC Stack TLV <xref target="RFC8029"/>. target="RFC8029" format="default"/>. Once the Echo Request packet reaches the end of
   the MPLS path, it is sent to the control plane of the egress PE.
   The Echo Request packet contains sufficient information to verify the correctness
   of data plane operations and validate the data plane against the control plane.
   The Egress egress PE sends the results of the validation in an Echo Reply packet to the
   originating PE of the Echo Request packet.</t>
      <t>This document defines procedures to detect data
   plane failures using LSP Ping in MPLS networks deploying EVPN and
   PBB-EVPN. This document defines four new Sub-TLVs sub-TLVs for the Target FEC Stack TLV
   with the purpose of identifying the FEC on the Egress egress PE.</t>
    </section>
    <section title="Specification numbered="true" toc="default">
      <name>Specification of Requirements">
   <t>The Requirements</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section title="Terminology">

   <t>AD: Auto Discovery</t>

   <t>B-MAC: Backbone MAC Address</t>

   <t>BUM: Broadcast, numbered="true" toc="default">
      <name>Terminology</name>
<dl>
      <dt>A-D:</dt><dd>Auto-Discovery</dd>
      <dt>B-MAC:</dt><dd>Backbone MAC</dd>
      <dt>BUM:</dt><dd>Broadcast, Unknown Unicast or Multicast</t>

   <t>CE: Customer Unicast, and Multicast</dd>
      <dt>CE:</dt><dd>Customer Edge Device</t>

   <t>C-MAC: Customer MAC Address</t>

   <t>DF: Designated Forwarder</t>

   <t>ES: Ethernet Segment</t>

   <t>ESI: Ethernet device</dd>
      <dt>C-MAC:</dt><dd>Customer MAC</dd>
      <dt>DF:</dt><dd>Designated Forwarder</dd>
      <dt>ES:</dt><dd>Ethernet Segment</dd>
      <dt>ESI:</dt><dd>Ethernet Segment Identifier</t>

   <t>EVI: EVPN Identifier</dd>
      <dt>EVI:</dt><dd>EVPN Instance Identifier that globally identifies the EVPN Instance</t>

   <t>EVPN: Ethernet Instance</dd>
      <dt>EVPN:</dt><dd>Ethernet Virtual Private Network</t>

   <t>FEC: Forwarding Network</dd>
      <dt>FEC:</dt><dd>Forwarding Equivalent Classs</t>

   <t>G-ACh: Generic Class</dd>
      <dt>G-ACh:</dt><dd>Generic Associated Channel</t>
   <t>GAL: G-ACh Label</t>

   <t>OAM: Operations, Channel</dd>
      <dt>GAL:</dt><dd>G-ACh Label</dd>
      <dt>MAC-VRF:</dt><dd>A Virtual Routing and Forwarding table for MAC
      addresses on a PE</dd>
      <dt>ND:</dt><dd>Neighbor Discovery</dd>
      <dt>OAM:</dt><dd>Operations, Administration, and Maintenance</t>

   <t>P2MP: Point-to-Multipoint</t>

   <t>PBB-EVPN: Provider Maintenance</dd>
      <dt>P2MP:</dt><dd>Point-to-Multipoint</dd>
      <dt>PBB-EVPN:</dt><dd>Provider Backbone Bridge with EVPN</t>

   <t>PE: Provider Bridging EVPN</dd>
      <dt>PE:</dt><dd>Provider Edge Device</t>

   <t>VPWS: Virtual device</dd>
      <dt>VPWS:</dt><dd>Virtual Private Wire Service</t> Service</dd>
</dl>
    </section>
    <section title="Proposed Target numbered="true" toc="default">
      <name>Target FEC Stack Sub-TLVs"> Sub-TLVs</name>
      <t>This document introduces four new Target FEC Stack Sub-TLVs sub-TLVs that
   are included in the MPLS Echo Request packet. The Echo Request packets
   are used for connectivity check checks in the data plane in EVPN and PBB-EVPN networks.
   The target Target FEC stack Sub-TLVs MAY Stack sub-TLVs <bcp14>MAY</bcp14> be used to validate that an identifier
   for a given EVPN is programmed at the target node.</t>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN MAC/IP Sub-TLV"> Sub-TLV</name>
        <t>The EVPN MAC/IP Sub-TLV sub-TLV identifies the target MAC, MAC/IP binding for ARP/ND,
        or IP address for an EVPN Instance Identifier (EVI) EVI under test at an egress PE.
        This Sub-TLV sub-TLV is included in the Echo Request sent by a an
        EVPN/PBB-EVPN PE to a Peer peer PE.</t>

        <t>The fields of the EVPN MAC/IP Sub-TLV fields sub-TLV are derived from the MAC/IP Advertisement
   route defined in Section 7.2 in <xref target="RFC7432"/> target="RFC7432" sectionFormat="of" section="7.2"/> and have the format as
   shown in Figure 1. <xref target="fig1"/>. The fields of the EVPN MAC/IP Sub-TLV sub-TLV should be set according to the
   following that
   following, which is consistent with <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC7623"/>:</t>
   <t><list style="symbols">
      <t>The Route Distinguisher (RD) field is a 10-octet field and is set to the RD
         of the MAC-VRF on the Peer PE.</t>
      <t>The target="RFC7623" format="default"/>:</t>
        <ul spacing="normal">
          <li>The Ethernet TAG Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle
         service <xref target="RFC7432"/>. target="RFC7432" format="default"/>. For PBB-EVPN, the value of this field is always 0 as
         per Section 5.2 of <xref target="RFC7623"/>.</t>
      <t>The target="RFC7623" sectionFormat="of" section="5.2"/>.</li>
          <li>The Ethernet Segment Identifier field is a 10-octet field. For EVPN, it is set to 0 for
         singlehomed a
         single-homed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN, the Ethernet
         Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load-balancing) load balancing) or to MAX-ESI (for multihomed segments with per-flow load-balancing) load balancing) as
         describe in Section 5.2
         described in <xref target="RFC7623"/>.</t>
      <t>The target="RFC7623" sectionFormat="of" section="5.2"/>.</li>
          <li>The MAC Addr Len field specifies the MAC length in bits. Only 48 bit 48-bit MAC Addresses addresses
         are supported as this document follows the MAC address length supported by <xref target="RFC7432"/>.</t>
      <t>The target="RFC7432" format="default"/>.</li>
          <li>The MAC Address field is set to the 6-octet MAC address.</t>
      <t>The address.</li>

          <li>The IP Address field is optional. When the IP Address field is not present,
         the IP Addr Len field is set to 0. When the IP Address field is present, the IP Addr Len field is in
         bits and is either set to either 32 for IPv4 addresses or 128 for IPv6 address. </t>
      <t>The addresses. </li>
          <li>The Must Be Zero fields are set to 0. The receiving PE should ignore the
         Must Be Zero fields. </t>
  </list></t> </li>
        </ul>

<figure align="left">
          <preamble/> anchor="fig1" title="EVPN MAC/IP Sub-TLV Format">
      <artwork align="left"><![CDATA[ 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) octets)    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | Must Be Zero  |  IP Addr Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                IP Address (0, 4 or 16 Octets) octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: EVPN MAC Sub-TLV format
]]></artwork>
        </figure>
]]></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 Advertisement route announced by the egress PE and the MPLS transport label(s) to reach the egress PE.</t>
<t>In EVPN, the MAC/IP Advertisement route has multiple personality uses and it is used for
the following cases: </t>
      <t><list style="symbols">
      <t>This cases:</t>
        <ul spacing="normal">
          <li>This route with only a MAC address and MPLS Label1 is used for populating MAC-VRF and performing MAC forwarding.</t>
      <t>This 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 for performing MAC forwarding</t>
      <t>This forwarding.</li>
          <li>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 forwarding, and IP forwarding in the case of symmetric IRB.</t>
      </list></t> Integrated Routing and Bridging (IRB).</li>
        </ul>
        <t>When an MPLS Echo Request is sent by an ingress PE, the contents of the Echo Request and the egress PE mode of operation (i.e., IRB mode or L2 mode) along with EVPN MPLS label of the packet, packet determine which of the above three cases is above this Echo Request is for. When the egress PE receives the EVPN MAC/IP Sub-TLV sub-TLV containing only the MAC address, the egress PE validates the MAC state and forwarding.  When the egress PE receives the EVPN MAC/IP Sub-TLV sub-TLV containing both MAC and IP addresses and if the EVPN label points to a MAC-VRF, then the egress PE validates the MAC state and forwarding. If the egress PE is not configured in symmetric IRB mode, it also validates ARP/ND state. However, if the EVPN label points to an IP-VRF, then the egress PE validates IP state and forwarding.
Any other combinations, such as combinations (e.g., the egress PE receiving
   the EVPN MAC/IP Sub-TLV sub-TLV containing only the MAC address but with the EVPN label
   pointing to an IP-VRF, IP-VRF) should be considered invalid invalid,
   and the egress PE should send an Echo Reply should be sent with the appropriate return code by the egress PE Return
   Code to the ingress PE.</t>
      </section>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN Inclusive Multicast Sub-TLV"> Sub-TLV</name>
        <t>The fields of the EVPN Inclusive Multicast Sub-TLV fields sub-TLV are based on the EVPN
   Inclusive Multicast Tag route defined in <xref target="RFC7432"/> Section 7.3. target="RFC7432" sectionFormat="of" section="7.3"/>.
   This TLV is included in the Echo Request sent to the EVPN
   peer PE by the originator of the request to verify the multicast
   connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.
        </t>
        <t>The EVPN Inclusive Multicast Sub-TLV sub-TLV has the format as shown in
   Figure 2.
   <xref target="fig2"/>. The fields of this Sub-TLV sub-TLV should be set according to the
   following that
   following, which is consistent with <xref target="RFC7432"/> target="RFC7432" format="default"/> and
   <xref target="RFC7623"/>:</t>
   <t><list style="symbols">
      <t>The target="RFC7623" format="default"/>:</t>
        <ul spacing="normal">
          <li>The Route Distinguisher (RD) field is a 10-octet field and is set to the RD
         of the MAC-VRF on the Peer PE.</t>
      <t>For peer PE.</li>
          <li>For EVPN, the Ethernet TAG Tag ID field can be set to 0 or a valid VLAN ID for
         EVPN VLAN-aware bundle service <xref target="RFC7432"/>. target="RFC7432" format="default"/>.
         For PBB-EVPN, the value of this field is set to the Service
         Instance Identifier (I-SID) value as per Section 5.3 of <xref target="RFC7623"/>.</t>
      <t>The target="RFC7623" sectionFormat="of" section="5.3"/>.</li>
          <li>The IP Addr Len field specifies the length of the Originating Router's IP Addr field in bits and it is either set to either 32 for IPv4 addresses or 128 for IPv6 address.</t>
      <t>The addresses.</li>
          <li>The Originating Router's IP Addr field is set to the IPv4 or IPv6 address of the peer PE.</t>
     </list></t> PE.</li>
        </ul>

	<figure align="left">
          <preamble/> anchor="fig2" title="EVPN Inclusive Multicast Sub-TLV Format">
        <artwork align="left"><![CDATA[ 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                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: EVPN Inclusive Multicast Sub-TLV format

            ]]></artwork>
        </figure>

   <t>Broadcast, unknown unicast or multicast (BUM)
]]></artwork></figure>
        <t>BUM traffic can be sent using ingress replication or P2MP P-tree in
        EVPN and PBB-EVPN network. In
   case of 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 Inclusive Multicast label is the downstream assigned 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 inclusive the Inclusive P-tree
   arrangement or using a label stack of [P2MP P-tree transport Transport label,
   upstream assigned
   upstream-assigned EVPN Inclusive Multicast label] for the aggregate
   inclusive Aggregate
   Inclusive P2MP P-tree arrangement as described in Section 6.</t>

   <t>In case of EVPN, <xref target="operations"/>.</t>

<t> In an EVPN network, to emulate traffic coming from a multihomed site, an
additional EVPN Ethernet Auto-Discovery Sub-TLV A-D sub-TLV in the Target FEC stack Stack TLV
and an ESI Split Horizon Group MPLS label as the bottom label, 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 <xref
target="p2mp-ptree"/> for operations using P2MP P-trees.</t>
      </section>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN Ethernet Auto-Discovery Sub-TLV"> (A-D) Sub-TLV</name>
        <t>The fields in the EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields A-D sub-TLV are based on the
   EVPN Ethernet Auto-Discovery A-D route advertisement defined in <xref target="RFC7432"/>
   Section 7.1. target="RFC7432" sectionFormat="of" section="7.1"/>.  The EVPN Ethernet AD Sub-TLV A-D sub-TLV only applies to only EVPN.</t>

   <t>The EVPN Ethernet AD Sub-TLV A-D sub-TLV has the format shown in Figure 3. <xref target="fig3"/>.
      The fields of this Sub-TLV sub-TLV should be set according to the
          following that
          following, which is consistent with <xref target="RFC7432"/>:</t>
    <t><list style="symbols">
      <t>The target="RFC7432" format="default"/>:</t>
        <ul spacing="normal">
          <li>The Route Distinguisher (RD) field is a 10-octet field and is set to the RD
         of the MAC-VRF on the Peer peer PE. Please see Section 4.3.2 below <xref target="adroute"/> for the case when a
         per-ES AD A-D route is announced with different RDs</t>
      <t>The RDs.</li>
          <li>The Ethernet TAG Tag ID field can be 0, MAX-ET MAX-ET, or a valid VLAN ID as described in
         Section 4.3.1 below.</t>
      <t>The
         <xref target="etagvalue"/>.</li>
          <li>The Ethernet Segment Identifier field is a 10-octet field and is set to 0 for
        singlehomed
        a single-homed ES or to a valid ESI ID for a multihomed ES.</t>
      <t>The ES.</li>
          <li>The Must Be Zero field is set to 0. The receiving PE should ignore the
         Must Be Zero field. </t>
    </list></t> </li>
        </ul>

	<figure align="left">
          <preamble/> anchor="fig3" title="EVPN Ethernet A-D Sub-TLV Format">
        <artwork align="left"><![CDATA[ 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format

           ]]></artwork>
        </figure>
]]></artwork></figure>
        <section title="Ethernet TAG Value">
      <t> anchor="etagvalue" numbered="true" toc="default">
          <name>Ethernet Tag Value</name>
          <t>The EVPN Ethernet AD Sub-TLV A-D sub-TLV can be sent in the context of per-Ethernet Segment (ES) per-ES or per-EVI.
When an operator performs a connectivity check for the BUM L2 service,
         an Echo Request packet sent, MAY is sent and <bcp14>MAY</bcp14> contain the EVPN Ethernet AD Sub-TLV A-D sub-TLV to emulate traffic
         coming from a multihomed site.  In this case, the EVPN Ethernet AD Sub-TLV A-D sub-TLV is
         added in the per-ES context. When an Echo Request packet is sent for the connectivity
         check for EVPN Aliasing state, the context for the EVPN Ethernet AD
         Sub-TLV A-D
         sub-TLV is per-EVI.</t>

         <t>Ethernet
          <t>The Ethernet Tag field value in the EVPN Ethernet AD Sub-TLV, MUST A-D sub-TLV <bcp14>MUST</bcp14> be set according
         to the context:</t>

        <t><list style="symbols">
          <t>For
          <ul spacing="normal">
            <li>For the per-ES context, the Ethernet Tag field in the sub-TLV MUST <bcp14>MUST</bcp14> be set to
         the reserved MAX-ET value <xref target="RFC7432"/></t>
          <t>For target="RFC7432" format="default"/>.</li>
            <li>For the per-EVI context, the Ethernet Tag field in the sub-TLV MUST <bcp14>MUST</bcp14> be set to
         the non-reserved value</t>
        </list></t> value.</li>
          </ul>
        </section>
        <section title="Per-ES anchor="adroute" numbered="true" toc="default">
          <name>Per-ES EVPN Auto-Discovery Route with different RDs">
     <t>Section 8.2 of <xref target="RFC7432"/> Different RDs</name>
          <t><xref target="RFC7432" sectionFormat="of" section="8.2"/> specifies that a per-ES EVPN AD A-D route for
        a given multihomed ES, ES may be advertised more than once with different RD values
        because many EVIs may be associated with the same ES and Route Targets for all these
        EVIs may not fit in a single BGP Update message.  In this case, the RD value used
        in the EVPN Ethernet AD Sub-TLV, MUST A-D sub-TLV <bcp14>MUST</bcp14> be the RD value received for the EVI in the
        per-ES EVPN AD Route.</t> A-D route.</t>
        </section>
        <section title="EVPN VPWS"> numbered="true" toc="default">
          <name>EVPN VPWS</name>
          <t>LSP Ping can also be used to detect data plane failures for the EVPN Virtual Private Wire
        Service (VPWS) VPWS described in <xref target="RFC8214"/>. target="RFC8214" format="default"/>.
        The Echo Request packet carries the EVPN Ethernet AD Sub-TLV A-D sub-TLV with fields populated from
        the EVPN Ethernet AD per EVI A-D per-EVI route announced by the egress PE for the EVPN VPWS under test.
        The Echo Request is sent by the ingress
        PE using the EVPN MPLS label associated with the EVPN Ethernet AD A-D route announced by the
        egress PE and the MPLS transport label(s) to reach the egress PE.</t>
          <t>The egress PE process processes the Echo Request packet and perform performs
          checks for the EVPN Ethernet AD
        Sub-TLV A-D sub-TLV present in the Target FEC
          Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of"
          section="4.4"/> and respond responds according to <xref target="RFC8029"/> processing rule.
        Egress rules in <xref
          target="RFC8029" format="default"/>.  The egress PE can identify
          that the Echo Request is for the EVPN VPWS instance as EVI
          (identified by the RD) for EVPN VPWS is different from that EVI assigned
          for EVPN. The egress PE will use the information from the EVPN
          Ethernet AD
        Sub-TLV A-D sub-TLV in the Target FEC Stack TLV and validate the
          VLAN state for the EVPN VPWS under test.  For the success case, the
          egress PE will reply with Return Code 3 - "Replying ("Replying router is an
          egress for the FEC at stack-depth".</t> stack-depth &lt;RSC&gt;").</t>
        </section>
      </section>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN IP Prefix Sub-TLV"> Sub-TLV</name>
        <t>The EVPN IP Prefix Sub-TLV sub-TLV identifies the IP Prefix prefix for an EVI under
   test at a peer PE.</t>
        <t>The EVPN IP Prefix Sub-TLV sub-TLV fields are derived from the IP Prefix Route route (RT-5)
          advertisement defined in <xref target="RFC9136"/>. target="RFC9136" format="default"/>. This sub-TLV only applies to
          only
          EVPN.</t>
        <t>The EVPN IP Prefix Sub-TLV sub-TLV has the format shown in Figure 4. <xref target="fig4"/>.  The
           total length (not shown) of this sub-TLV MUST <bcp14>MUST</bcp14> be either 32 bytes (if
           IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carried).
          The IP prefix and gateway IP address MUST <bcp14>MUST</bcp14> be from the same IP address
          family, as described in Section 3.1 of <xref target="RFC9136"/>.</t> target="RFC9136" sectionFormat="of" section="3.1"/>.</t>
        <t>The fields of the EVPN IP Prefix Sub-TLV sub-TLV should be set according to the
          following that
          following, which is consistent with <xref target="RFC9136"/>:</t>
     <t><list style="symbols">
      <t>The target="RFC9136" format="default"/>:</t>
        <ul spacing="normal">
          <li>The Route Distinguisher (RD) field is a 10-octet field and is set to the RD
         of the IP-VRF on the Peer PE.</t>
      <t>The peer PE.</li>
          <li>The Ethernet TAG Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle
         service <xref target="RFC7432"/>.</t>
      <t>The target="RFC7432" format="default"/>.</li>
         <li>The Ethernet Segment Identifier field is a 10-octet field and is set to
         a valid ESI ID if the ESI is used as an Overlay Index as per Section 3.1 of <xref target="RFC9136"/>.
         Otherwise target="RFC9136" sectionFormat="of" section="3.1"/>.
         Otherwise, the Ethernet Segment Identifier field is set to all 0s.</t>
      <t>The 0.</li>
          <li>The IP Prefix Len field specifies the number of bits in the IP Prefix field. It
        is set to a value between 0 and 32 for IPv4 or between 0 to 128 for IPv6.</t>
      <t>The IPv6.</li>
          <li>The IP prefix Prefix field is set to a 4-octet IPv4 address (with
         trailing 0 bits to make 32 bits in all) or a 16-octet IPv6 address
         (with trailing 0 bits to make 128 bits in all). The address family
         of this field is inferred from the sub-TLV length field, as
         discussed above.</t>
      <t> above.</li>
          <li> The Gateway (GW) IP Address field is set to a 4-octet IPv4 address
          or a 16-octet IPv6 address if it's used as an Overlay Index for the
         IP prefixes.  If the GW IP Address is not being used, it must be
         set to 0 as described in Section 3.1 of <xref target="RFC9136"/>. target="RFC9136" sectionFormat="of" section="3.1"/>. The address
         family of this field is inferred from the sub-TLV length field, as
         discussed above.</t>
        <t>The above.</li>
          <li>The Must Be Zero field is set to 0. The receiving PE should ignore the
         Must Be Zero field. </t>

  </list></t> </li>
        </ul>

	<figure align="left">
          <preamble/> anchor="fig4" title="EVPN IP Prefix Sub-TLV Format">
        <artwork align="left"><![CDATA[ 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) octets)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                GW IP Address (4 or 16 Octets) octets)                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: EVPN IP Prefix Sub-TLV format
]]></artwork>
        </figure>
]]></artwork></figure>
        <t>The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s)
   associated with the IP Prefix route announced by the egress PE and the MPLS
   transport label(s) to reach the egress PE.</t>
      </section>
    </section>
    <section title="Encapsulation numbered="true" toc="default">
      <name>Encapsulation of OAM Ping Packets"> Packets</name>
      <t>The MPLS Echo Request IP/UDP packets MUST <bcp14>MUST</bcp14> be encapsulated
         with the Transport and EVPN Label(s) label(s) followed by the Generic Associated
         Channel Label (GAL)
         GAL <xref target="RFC5586"/> target="RFC5586" format="default"/>, which is the bottom most bottommost label.
         The GAL is followed by a Generic Associated Channel Header G-ACh header carrying the
         IPv4(0x0021) or IPv6(0x0057) Channel Type. The code points for IPv4 and
         IPv6 channels are defined in Generic the "Generic Associated Channel (G-ACh) Parameters
         by IANA.</t> Parameters" IANA registry.</t>
    </section>
    <section title="Operations"> anchor="operations" numbered="true" toc="default">
      <name>Operations</name>
      <section title="Unicast Data-plane connectivity checks">
   <t>Figure 5 numbered="true" toc="default">
        <name>Unicast Data Plane Connectivity Checks</name>
        <t><xref target="fig5"/> is an example of a PBB-EVPN network. CE1 is dual-homed to
  PE1 and PE2. Assume, Assume that PE1 announced a MAC route with RD 192.0.2.1:00 and
  B-MAC 00-AA-00-BB-00-CC and with MPLS label 16001 for EVI 10. Similarly,
  PE2 announced a MAC route with RD 203.0.113.2:00 and B-MAC 00-AA-00-BB-00-CC
  and with MPLS label 16002.</t>
        <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
  request with the target Target FEC stack Stack TLV containing the EVPN MAC Sub-TLV MAC/IP sub-TLV in
  the Echo Request packet. The Echo Request packet is sent with the
  {Transport Label(s) label(s) to reach PE1, EVPN Label label = 16001, GAL} MPLS label
  stack and IP ACH Channel header. Once the Echo Request packet reaches PE1,
  PE1 will use the GAL and the IP ACH Channel header
  to determine that if the packet is an IPv4 or IPv6 OAM Packet. packet. The PE1 will process the
  packet and perform checks for the EVPN MAC Sub-TLV MAC/IP sub-TLV present in the
  Target FEC Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of" section="4.4"/> and
  respond according to <xref target="RFC8029"/> the processing rules.</t> rules in <xref target="RFC8029" format="default"/>.</t>

	<figure align="left">
          <preamble/> anchor="fig5" title="PBB-EVPN Network">
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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>
]]></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
  LSP Ping request with the target Target FEC stack Stack TLV containing the EVPN MAC
  Sub-TLV MAC/IP
  sub-TLV in the Echo Request packet. The Echo Request packet is sent
  with the {MPLS transport Label(s) Transport label(s) to reach PE2, EVPN Label label = 16002, GAL}
  MPLS label stack and IP ACH Channel header.</t>
        <t>LSP Ping operation operations for unicast data plane connectivity checks in EVPN, EVPN
  are similar to those described above for PBB-EVPN PBB-EVPN, except that the
  checks are for C-MAC addresses instead of B-MAC addresses.</t>
        <t> In EVPN network, networks, an operator can also perform a MAC state test using an aliasing
    label for the MAC to verify the MAC state on the egress multihoming PE that did
    not learn the MAC from the multihomed CE on a local ESI but has announced Ethernet
    AD
    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, locally get created
    from EVPN MAC/IP route advertisement from the multihoming PE that has
    learned the CE's MAC address locally.
        </t>
      </section>
      <section title="Inclusive numbered="true" toc="default">
        <name>Inclusive Multicast Data-plane Data Plane Connectivity Checks"> Checks</name>
        <section title="Ingress Replication"> numbered="true" toc="default">
          <name>Ingress Replication</name>
          <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
   type set to ingress replication replication, and downstream assigned inclusive
   multicast downstream-assigned Inclusive
   Multicast MPLS label 17001. Similarly, PE2 announced an Inclusive
   Multicast route for EVI 10, with RD 203.0.113.2:00, Ethernet Tag (ISID
   10), PMSI tunnel attribute Tunnel type set to ingress replication replication,
   and downstream assigned inclusive multicast downstream-assigned Inclusive Multicast MPLS label 17002.</t>
          <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.
   44dd.5500.</t>
          <t>When an operator at PE3 initiates a connectivity check for the
   inclusive multicast
   Inclusive Multicast on PE1, the operator initiates an LSP Ping
   request with the target Target FEC stack Stack TLV containing the EVPN Inclusive
   Multicast Sub-TLV sub-TLV in the Echo Request packet. The Echo Request
   packet is sent with the {Transport Label(s) label(s) to reach PE1, EVPN
   Incl.
   Inclusive Multicast Label label = 17001, GAL} MPLS label stack and IP ACH Channel header.
   Once the Echo Request packet reaches PE1,
   PE1 will use the GAL and the IP ACH Channel header
   to determine that if the packet is an IPv4 or IPv6 OAM Packet. packet.
   The packet will have the EVPN Inclusive multicast Multicast label.
   PE1 will process the packet and perform checks for the EVPN
   Inclusive Multicast Sub-TLV sub-TLV present in the Target FEC Stack TLV as
   described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of" section="4.4"/> and respond according to
   <xref target="RFC8029"/>
   the processing rules. rules in <xref target="RFC8029" format="default"/>. For the success case, PE1 will reply
   with Return Code 3 - "Replying ("Replying router is an egress for the FEC at stack-depth". stack-depth &lt;RSC&gt;"). </t>
          <t>Similarly, an operator at PE3, PE3 may initiate an LSP Ping to PE2 with
   the target Target FEC stack Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the
   Echo Request packet. The Echo Request packet is sent with
   the {transport Label(s) {Transport label(s) to reach PE2, EVPN Incl. Inclusive Multicast Label label =
   17002, GAL} MPLS label stack and IP ACH Channel header.
   Once the Echo Request packet reaches PE2,
   PE2 will use the GAL and the IP ACH Channel header
   to determine that if the packet is an IPv4 or IPv6 OAM Packet. packet. The processing on PE2 will be similar
   to the that on PE1 as described above and for above. For the success case, PE2 will
   reply with Return Code 3 - "Replying ("Replying
   router is an egress for the FEC at stack-depth" stack-depth &lt;RSC&gt;") as per <xref target="RFC8029"/>.</t> target="RFC8029" format="default"/>.</t>
          <t>In case of EVPN, in the an Echo Request packet, packet for EVPN, a combination of an EVPN
          Ethernet AD Sub-TLV A-D sub-TLV and the associated MPLS Split Horizon Label above label,
          immediately preceding the GAL in the MPLS label stack, may be added used
          to emulate traffic coming from a multihomed site.  The Split Horizon
          label is used by leaf PE(s) attached to the same multihomed site to not forward
          prevent forwarding of packets back to the multihomed site. If the
          behavior on a leaf PE is to not forward the packet to the multihomed
          site on the ESI identified by the EVPN Ethernet AD Sub-TLV A-D sub-TLV because
          of Split Horizon filtering, the PE will reply with a Return Code indicating that "Replying router is egress
   for the FEC at the stack depth. In addition, 37 (see <xref target="iana"/>) and drop the BUM packets are dropped on the ES corresponding to the ESI received in the EVPN
Ethernet AD Sub-TLV A-D sub-TLV because of the Split Horizon Group filtering" as described in Section 8.</t> filtering.</t>
        </section>
        <section title="Using anchor="p2mp-ptree" numbered="true" toc="default">
          <name>Using P2MP P-tree"> P-Tree</name>
          <t>Both inclusive P-Tree Inclusive P-tree and aggregate inclusive Aggregate Inclusive P-tree can be used in
  EVPN or PBB-EVPN networks.</t>
          <t>When using an inclusive Inclusive P-tree arrangement, p2mp p-tree the P2MP P-tree transport
  label itself is used to identify the L2 service associated with the
  Inclusive Multicast Route, this route. This L2 service could be a customer
  Bridge, Customer
  Bridge or a Provider Backbone Bridge.</t>
          <t>For an Inclusive P-tree arrangement, when an operator performs a
  connectivity check for the multicast L2 service, the operator
  initiates an LSP Ping request with the target Target FEC stack Stack TLV
  containing the EVPN Inclusive Multicast Sub-TLV sub-TLV in the Echo Request
  packet. The Echo Request packet is sent over P2MP LSP
  with the {P2MP P-tree Transport label, GAL}
  MPLS label stack and IP ACH Channel header.</t>
          <t>When using an Aggregate Inclusive P-tree, P-tree arrangement, a PE announces an upstream
  assigned upstream-assigned MPLS label along with the P-tree ID, so both the
  p2mp p-tree
  P2MP P-tree MPLS transport label and the upstream MPLS label can be
  used to identify the L2 service.</t>
          <t>For an Aggregate Inclusive P-tree arrangement, when an operator
  performs a connectivity check for the multicast L2 service, the
  operator initiates an LSP Ping request with the target Target FEC stack Stack TLV
  containing the EVPN Inclusive Multicast Sub-TLV sub-TLV in the Echo Request
  packet. The Echo Request packet is sent over P2MP LSP using the
  IP-ACH Control channel with the {P2MP P-tree Transport label,
  EVPN Upstream assigned upstream-assigned Multicast Label, label, GAL} MPLS label stack and
  IP ACH Channel header.</t>

  <t>The Leaf leaf PE(s) of the p2mp tree P2MP P-tree will process the packet and perform
  checks for the EVPN Inclusive Multicast Sub-TLV sub-TLV present in the
  Target FEC Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of" section="4.4"/> and
  respond according to <xref target="RFC8029"/> the processing rules. rules in <xref target="RFC8029" format="default"/>.
  For the success case, the Leaf leaf PE will reply with Return Code 3 -
  "Replying
  ("Replying router is an egress for the FEC at stack-depth".</t> stack-depth &lt;RSC&gt;").</t>
          <t>In case of EVPN, in the an Echo Request packet, packet for EVPN, a combination of an EVPN
          Ethernet AD Sub-TLV A-D sub-TLV and the associated MPLS Split Horizon Label above label,
          immediately preceding the GAL in the MPLS label stack, may be added used
          to emulate traffic coming from a multihomed site. In case of p2mp p-tree,  When using P2MP
          P-tree, the Split Horizon Label label is upstream assigned and is received
          by all the leaf PEs of the p2mp-ptree. P2MP P-tree. The Split Horizon label is
          used by leaf PE(s) attached to the same multihomed site not to forward so that
          packets will not be forwarded back to the multihomed site. If the
          behavior on a leaf PE is to not forward the packet to the multihomed
          site on the ESI in the EVPN Ethernet AD Sub-TLV A-D sub-TLV because of Split
          Horizon filtering, the PE will reply with a Return Code indicating that "Replying router is egress
  for the FEC at the stack depth. In addition, 37 (see <xref target="iana"/>) and drop the BUM packets are dropped on the ES
corresponding to the ESI received in the EVPN Ethernet AD Sub-TLV A-D sub-TLV
because of the Split Horizon Group filtering" as described in Section 8. filtering.

          If the leaf PE does not have the ESI identified in the
          EVPN Ethernet AD Sub-TLV, A-D sub-TLV, the PE can <bcp14>MAY</bcp14> reply with a Return Code indicating that "Replying router is egress for the FEC at the
  stack depth. In addition, 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 AD Sub-TLV".</t> A-D sub-TLV.</t>
        </section>
        <section title="Controlling numbered="true" toc="default">
          <name>Controlling Echo Responses when using When Using P2MP P-tree"> P-Tree</name>
          <t>The procedures described in [RFC6425] <xref target="RFC6425"/> for preventing congestion of
   Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a
   single egress node (Node (P2MP Responder Identifier TLV with either the
   IPv4 Node Address P2MP Responder Identifier TLV) sub-TLV or the IPv6 Node Address P2MP
   Responder sub-TLV) can
   be applied to LSP Ping in EVPN and PBB-EVPN when using P2MP P-trees
   for broadcast, multicast, and unknown unicast BUM traffic.</t>
        </section>
      </section>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN Aliasing Data-plane connectivity check"> Data Plane Connectivity Check</name>
        <t>Assume PE1 announced an Ethernet AD A-D per-EVI Route route with the ESI
   set to CE1 system ID and MPLS label 19001, and 19001. Additionally, assume PE2 announced an Ethernet AD A-D per-EVI Route route
   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
   aliasing aspect of the EVPN Ethernet AD A-D route on PE1, the operator
   initiates an LSP Ping request with the target Target FEC stack Stack TLV
   containing the EVPN Ethernet AD Sub-TLV A-D sub-TLV in the Echo Request packet. The
   Echo Request packet is sent with the {Transport label(s) to reach
   PE1, EVPN Ethernet AD Label A-D label 19001, GAL} MPLS label stack and
   IP ACH Channel header.</t>
        <t>When PE1 receives the packet packet, it will process the packet and perform
   checks for the EVPN Ethernet AD Sub-TLV A-D sub-TLV present in the Target FEC
   Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of" section="4.4"/> and respond
   according to <xref target="RFC8029"/> the processing rules.</t> rules in <xref target="RFC8029" format="default"/>.</t>
      </section>
      <section title="EVPN numbered="true" toc="default">
        <name>EVPN IP Prefix (RT-5) Data-plane connectivity check"> Data Plane Connectivity Check</name>
        <t>Assume PE1 in Figure 5, <xref target="fig5"/> announced an IP Prefix Route route (RT-5) with an IP prefix
   reachable behind CE1 and MPLS label 20001. When an operator on PE3 performs a
   connectivity check for the IP prefix on PE1, the operator
   initiates an LSP Ping request with the target Target FEC stack Stack TLV
   containing the EVPN IP Prefix Sub-TLV sub-TLV in the Echo Request packet. The
   Echo Request packet is sent with the {Transport label(s) to reach
   PE1, EVPN IP Prefix Label label 20001 } MPLS label stack.</t>
        <t>When PE1 receives the packet packet, it will process the packet and perform
   checks for the EVPN IP Prefix Sub-TLV sub-TLV present in the Target FEC
   Stack TLV as described in Section 4.4 in <xref target="RFC8029"/> target="RFC8029" sectionFormat="of" section="4.4"/> and respond
   according to <xref target="RFC8029"/> the processing rules.</t> rules in <xref target="RFC8029" format="default"/>.</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>  The proposal introduced in this  This document does not introduce any new
           security considerations beyond those that already apply to in
           <xref target="RFC7432"/>, target="RFC7432" format="default"/>,
           <xref target="RFC7623"/> target="RFC7623" format="default"/>, and
           <xref target="RFC6425"/>. target="RFC6425" format="default"/>.

          Furthermore, the security considerations
          discussed in <xref target="RFC8029"/> target="RFC8029" format="default"/> apply to this document and need to be
          considered. As described in <xref target="RFC8029"/>, target="RFC8029" format="default"/>, these security considerations
          are:
           <t><list style="symbols">
              <t>Denial-of-Service
      </t>
      <ul spacing="normal">
        <li>A Denial-of-Service (DoS) attack, attack by sending MPLS echo
                requests/replies Echo
                Requests/Replies to LSRs Label Switching Routers (LSRs) and thereby increasing their workload.</t>
              <t>Obfuscating workload.</li>
        <li>Obfuscating the state of the MPLS data-plane data plane liveness by spoofing,
                 hijacking, replaying, or otherwise tampering with MPLS echo Echo Requests
                 and replies.</t>
              <t>Obtaining Replies.</li>
        <li>Obtaining information about the network by through an unauthorized source
                using an LSP ping.</t>
           </list></t> Ping.</li>
      </ul>
      <t> There are mitigations described in <xref target="RFC8029"/>. target="RFC8029" format="default"/>.  The same mitigations
            can be applied to the LSP Ping procedures described in this draft and thus document; thus, this document
            doesn't require additional security considerations beyond the one ones described
            in <xref target="RFC8029"/>.</t> target="RFC8029" format="default"/>.</t>
      <t> The proposal This document does not introduce any new privacy concerns because these TLVs contain the same information that are present in data packets and EVPN routes.
      </t>
      </t>
    </section>
    <section title="IANA Considerations"> anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Sub-TLV Type"> numbered="true" toc="default">
        <name>Sub-TLV Type</name>
        <t>   This document defines four new Sub-TLV type sub-TLV types to be included in the Target
   FEC Stack TLV (TLV Type types 1, 16 16, and 21) <xref target="RFC9041"/> target="RFC9041" format="default"/> in Echo Request and Echo
   Reply messages in EVPN and PBB-EVPN network.</t> networks.</t>
        <t>IANA is requested to assign lowest 4 free values for has assigned the four Sub-TLVs listed below following values
        from the Standards "Standards Action" (0-16383) range, range in the "Sub-TLVs for TLV
        Types 1, 16, and 21" sub-registry, in subregistry within the "TLVs" registry in of the
        "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
        Ping Parameters" name space: space. </t>
   <t><list style="symbols">
          <t>EVPN MAC/IP Sub-TLV </t>
          <t>EVPN

<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 Sub-TLV </t>
          <t>EVPN Auto-Discovery Sub-TLV</t>
          <t>EVPN IP Prefix Sub-TLV </t>

        </list></t> 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>

      </section>
      <section title="Proposed new numbered="true" toc="default">
        <name>New Return Codes"> Codes</name>
        <t><xref target="RFC8029"/> target="RFC8029" format="default"/> defines values for the Return Code field of Echo Reply. Reply messages.
   This document proposes defines two new Return Codes, which SHOULD Codes that <bcp14>SHOULD</bcp14> be
   included in the Echo Reply message by a PE in response to
   an Echo Request message in EVPN and PBB-EVPN network. networks. </t>
        <t> IANA is requested to assign 2 lowest free values for has assigned the 2 Return Codes listed below from following values in the Return "Return Codes"
        registry in of the "Multiprotocol Label Switching (MPLS) Label Switched
        Paths (LSPs) Ping Parameters" name space:</t>

   <t><list style="symbols">

   <t>Replying space.</t>

<table anchor="iana2">
  <name></name>
  <thead>
    <tr>
      <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 AD Sub-TLV Auto-Discovery sub-TLV because of the Split Horizon Group filtering.</t>

   <t>Replying
      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 AD Sub-TLV.</t>
    </list></t> Auto-Discovery sub-TLV.</td>
      <td>RFC 9489</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6425.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9041.xml"/>
    </references>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Loa Andersson, Alexander Vainshtein,
         Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Eric Vyncke, Warren Kumari,
         Patrice Brissette and Weiguo Hao <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>
  </middle>

  <back>
    <references title="Normative References">

      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.4760"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.7623"?>
      <?rfc include="reference.RFC.8029"?>
      <?rfc include="reference.RFC.6425"?>
      <?rfc include="reference.RFC.5586"?>
      <?rfc include="reference.RFC.7432"?>
      <?rfc include="reference.RFC.9136"?>
      <?rfc include="reference.RFC.8214"?>
      <?rfc include="reference.RFC.9041"?>

    </references>
  </back>
</rfc>