[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-jain-bess-evpn-lsp-ping)  00 01         Standards Track
          02 03 04 05 06 07 08                                          
BESS Workgroup                                              P. Jain, Ed.
Internet-Draft                                                A. Sajassi
Intended status: Standards Track                                S. Salam
Expires: January 8, 2023                             Cisco Systems, Inc.
                                                              S. Boutros
                                                                   Ciena
                                                               G. Mirsky
                                                                Ericsson
                                                            July 7, 2022


               LSP-Ping Mechanisms for EVPN and PBB-EVPN
                    draft-ietf-bess-evpn-lsp-ping-08

Abstract

   LSP Ping is a widely deployed Operation, Administration, and
   Maintenance mechanism in MPLS networks.  This document describes
   mechanisms for detecting data plane failures using LSP Ping in MPLS
   based EVPN and PBB-EVPN networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 8, 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Jain, et al.             Expires January 8, 2023                [Page 1]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Proposed Target FEC Stack Sub-TLVs  . . . . . . . . . . . . .   4
     4.1.  EVPN MAC/IP Sub-TLV . . . . . . . . . . . . . . . . . . .   4
     4.2.  EVPN Inclusive Multicast Sub-TLV  . . . . . . . . . . . .   5
     4.3.  EVPN Ethernet Auto-Discovery Sub-TLV  . . . . . . . . . .   6
     4.4.  EVPN IP Prefix Sub-TLV  . . . . . . . . . . . . . . . . .   8
   5.  Encapsulation of OAM Ping Packets . . . . . . . . . . . . . .   8
   6.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Unicast Data-plane connectivity checks  . . . . . . . . .   9
     6.2.  Inclusive Multicast Data-plane Connectivity Checks  . . .  10
       6.2.1.  Ingress Replication . . . . . . . . . . . . . . . . .  10
       6.2.2.  Using P2MP P-tree . . . . . . . . . . . . . . . . . .  11
       6.2.3.  Controlling Echo Responses when using P2MP P-tree . .  12
     6.3.  EVPN Aliasing Data-plane connectivity check . . . . . . .  13
     6.4.  EVPN IP Prefix (RT-5) Data-plane connectivity check . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Sub-TLV Type  . . . . . . . . . . . . . . . . . . . . . .  13
     8.2.  Proposed new Return Codes . . . . . . . . . . . . . . . .  14
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   [RFC7432] describes MPLS based Ethernet VPN (EVPN) technology.  An
   EVPN comprises CE(s) connected to PE(s).  The PEs provide layer 2
   EVPN among the CE(s) over the MPLS core infrastructure.  In EVPN
   networks, PEs advertise the MAC addresses learned from the locally
   connected CE(s), along with MPLS Label, to remote PE(s) in the
   control plane using multi-protocol BGP.  EVPN enables multihoming of
   CE(s) connected to multiple PEs and load balancing of traffic to and
   from multihomed CE(s).

   [RFC7623] describes the use of Provider Backbone Bridging [802.1ah]
   with EVPN.  PBB-EVPN maintains the Customer MAC (C-MAC) learning in
   data plane and only advertises Provider Backbone MAC (B-MAC)
   addresses in control plane using BGP.




Jain, et al.             Expires January 8, 2023                [Page 2]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   Procedures for simple and efficient mechanisms to detect data plane
   failures using LSP Ping in MPLS network are well defined in [RFC8029]
   and [RFC6425].  The basic idea for the LSP Ping mechanism is to send
   a MPLS Echo Request packet along the same data path as data packets
   belonging to the same Forwarding Equivalent Classs (FEC).  The Echo
   Request packet carries the FEC being verified in the Target FEC Stack
   TLV.  Once the Echo Request packet reaches the end of the MPLS path,
   it is sent to the control plane of the egress PE.  Echo Request
   packet contains sufficient infiormation to verify correctness of data
   plane operations and validate data plane against the control plan.
   Egress PE sends the results of the validation in Echo Reply packet to
   the originating PE of the Echo Request packet.

   This document defines procedures to detect data plane failures using
   LSP Ping in MPLS networks deploying EVPN and PBB-EVPN.  This document
   defines four new Sub-TLVs for Target FEC Stack TLV with the purpose
   of identifying the FEC on the Egress PE.

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   AD: Auto Discovery

   B-MAC: Backbone MAC Address

   BUM: Broadcast, Unknown Unicast or Multicast

   CE: Customer Edge Device

   C-MAC: Customer MAC Address

   DF: Designated Forwarder

   ES: Ethernet Segment

   ESI: Ethernet Segment Identifier

   EVI: EVPN Instance Identifier that globally identifies the EVPN
   Instance

   EVPN: Ethernet Virtual Private Network



Jain, et al.             Expires January 8, 2023                [Page 3]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   FEC: Forwarding Equivalent Classs

   G-ACh: Generic Associated Channel

   GAL: G-ACh Label

   OAM: Operations, Administration, and Maintenance

   P2MP: Point-to-Multipoint

   PBB: Provider Backbone Bridge

   PE: Provider Edge Device

4.  Proposed Target FEC Stack Sub-TLVs

   This document introduces four new Target FEC Stack Sub-TLVs that are
   included in the LSP Ping Echo Request packet.  The Echo Request
   packets are used for connectivity check in data plane in EVPN and
   PBB-EVPN networks.  The target FEC stack Sub-TLVs MAY be used to
   validate that an indentifier for a given EVPN is programmed at the
   target node.  These Target FEC Stack Sub-TLVs are described next.

4.1.  EVPN MAC/IP Sub-TLV

   The EVPN MAC/IP Sub-TLV identifies the MAC or ARP/ND for an EVPN
   Instance Identifier (EVI) under test at a peer PE.

   The EVPN MAC/IP Sub-TLV fields are derived from the MAC/IP
   Advertisement route defined in [RFC7432] Section 7.2 and have the
   format as shown in Figure 1.  This Sub-TLV is included in the Echo
   Request sent by a PBB-EVPN/EVPN PE to a Peer PE.  IP Address field in
   this Sub-TLV is optional.

   For PBB-EVPN, Ethernet Tag ID and Ethernet Segment Identifier fields
   of this Sub-TLV is set per section 5.2 of [RFC7623].















Jain, et al.             Expires January 8, 2023                [Page 4]


Internet-Draft              MPLS OAM for EVPN                  July 2022


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Route Distinguisher                        |
       |                        (8 octets)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Ethernet Tag ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Ethernet Segment Identifier                     |
       |                     (10 octets)                               |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               | Must Be Zero  |  MAC Addr Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                MAC Address                                    |
       +                 (6 Octets)    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               | Must Be Zero  |  IP Addr Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                IP Address (0, 4 or 16 Octets)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 1: EVPN MAC Sub-TLV format

   The LSP Echo Request is sent using the EVPN MPLS label(s) associated
   with the MAC/IP Advertisement route announced by a remote PE and the
   MPLS transport label(s) to reach the remote PE.  When remote PE
   processes the received LSP Echo Request packet, the remote PE
   validates the MAC state if the MAC/IP Sub-TLV contains only MAC
   address.  If the MAC/IP Sub-TLV contains both MAC and IP address, the
   PE validates the ARP/ND state.

4.2.  EVPN Inclusive Multicast Sub-TLV

   The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN
   Inclusive Multicast route defined in [RFC7432] Section 7.3.

   The EVPN Inclusive Multicast Sub-TLV has the format as shown in
   Figure 2.  This TLV is included in the Echo request sent to the EVPN
   peer PE by the originator of request to verify the multicast
   connectivity state on the peer PE(s) in EVPN and PBB-EVPN networks.











Jain, et al.             Expires January 8, 2023                [Page 5]


Internet-Draft              MPLS OAM for EVPN                  July 2022


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Route Distinguisher                        |
       |                        (8 octets)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Ethernet Tag ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Addr Len |                                                 |
       +-+-+-+-+-+-+-+                                                 |
       ~               Originating Router's IP Addr                    ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 2: EVPN Inclusive Multicast Sub-TLV format


   Broadcast, unknown unicast or multicast (BUM) traffic can be sent
   using ingress replication or P2MP P-tree in EVPN and PBB-EVPN
   network.  In case of ingress replication, the Echo Request is sent
   using a label stack of [Transport label, Inclusive Multicast label]
   to each remote PE participating in EVPN or PBB-EVPN.  The inclusive
   multicast label is the downstream assigned label announced by the
   remote PE to which the Echo Request is being sent.  The Inclusive
   Multicast label is the inner label in the MPLS label stack.

   When using P2MP P-tree in EVPN or PBB-EVPN, the Echo Request is sent
   using P2MP P-tree transport label for inclusive P-tree arrangement or
   using a label stack of [P2MP P-tree transport label, upstream
   assigned EVPN Inclusive Multicast label] for the aggregate inclusive
   P2MP P-tree arrangement as described in Section 6.

   In case of EVPN, to emulate traffic coming from a 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.

4.3.  EVPN Ethernet Auto-Discovery Sub-TLV

   The EVPN Ethernet Auto-Discovery (AD) Sub-TLV fields are based on the
   EVPN Ethernet Auto-Discovery route advertisement defined in [RFC7432]
   Section 7.1.  EVPN Ethernet AD Sub-TLV applies to only EVPN.

   The EVPN Ethernet AD Sub-TLV has the format shown in Figure 3.




Jain, et al.             Expires January 8, 2023                [Page 6]


Internet-Draft              MPLS OAM for EVPN                  July 2022


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Route Distinguisher                        |
       |                        (8 octets)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Ethernet Tag ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Ethernet Segment Identifier                     |
       |                     (10 octets)                               |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |      Must Be Zero             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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


   EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet
   Segememnt (ES) or per-EVI.  When an operator performs a connectivity
   check for the BUM L2 service, Echo Request packet sent, MAY contain
   EVPN Ethernet AD Sub-TLV to emulate traffic coming from a multihomed
   site.  In this case, the EVPN Ethernet AD Sub-TLV is added in per-ES
   context.  When Echo Request packet is sent for the connectivity check
   for EVPN Aliasing state, the context for the EVPN Ethernet AD Sub-TLV
   is per-EVI.

   Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, MUST be set
   according to the context:

   o  For per-ES context, the Ethernet Tag field in the sub-TLV MUST be
      set to the reserved MAX-ET value [RFC7432]

   o  For per-EVI context, the Ethernet Tag field in the sub-TLV MUST be
      set to the non-reserved value

   Section 8.2 of [RFC7432] specifies that a per-ES EVPN AD route for a
   given multihomed ES, may be advertised more than once with different
   RD values because many EVIs may be associated with the same ES and
   Route Targets for all these EVIs may not fit in a single BGP Update
   message.  In this case, the RD value used in the EVPN Ethernet AD
   Sub-TLV, MUST be the RD value received for the EVI in the per-ES EVPN
   AD Route.








Jain, et al.             Expires January 8, 2023                [Page 7]


Internet-Draft              MPLS OAM for EVPN                  July 2022


4.4.  EVPN IP Prefix Sub-TLV

   The EVPN IP Prefix Sub-TLV identifies the IP Prefix for an EVI under
   test at a peer PE.

   The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix
   Route (RT-5) advertisement defined in [RFC9136] and applies to only
   EVPN.  This Sub-TLV has the format as shown in Figure 4.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Route Distinguisher                        |
       |                        (8 octets)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Ethernet Tag ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Ethernet Segment Identifier                     |
       |                     (10 octets)                               |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               | Must Be Zero  | IP Prefix Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                 IP Prefix  (4 or 16 Octets)                   ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                GW IP Address (4 or 16 Octets)                 ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 4: EVPN IP Prefix Sub-TLV format

   The LSP Echo Request is sent using the EVPN MPLS label(s) associated
   with the IP Prefix route announced by a remote PE and the MPLS
   transport label(s) to reach the remote PE.

5.  Encapsulation of OAM Ping Packets

   The LSP Ping Echo request IP/UDP packets MUST be encapsulated with
   the Transport and EVPN Label(s) followed by the Generic Associated
   Channel Label (GAL) [RFC5586] which is the bottom most label.  The
   GAL is followed by a Generic Associated Channel Header carrying
   IPv4(0x0021) or IPv6(0x0057) Channel Type.  The code points for ipv4
   and ipv6 channels are defiend in Generic Associated Channel (G-ACh)
   Parameters by IANA.








Jain, et al.             Expires January 8, 2023                [Page 8]


Internet-Draft              MPLS OAM for EVPN                  July 2022


6.  Operations

6.1.  Unicast Data-plane connectivity checks

   Figure 5 is an example of a PBB-EVPN network.  CE1 is dual-homed to
   PE1 and PE2.  Assume, PE1 announced a MAC route with RD 1.1.1.1:00
   and B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10.
   Similarly, PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC
   00aa.00bb.00cc and with MPLS label 16002.

   On PE3, when an operator performs a connectivity check for the B-MAC
   address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping
   request with the target FEC stack TLV containing EVPN MAC Sub-TLV in
   the Echo Request packet.  The Echo Request packet is sent with the
   {Transport Label(s) to reach PE1, EVPN Label = 16001, GAL} MPLS label
   stack and IP ACH Channel header.  Once the Echo Request packet
   reaches PE1, PE1 will use the GAL and the IP ACH Channel header to
   determine that the packet is IPv4 OAM Packet.  The PE1 will process
   the packet and perform checks for the EVPN MAC Sub-TLV present in the
   Target FEC Stack TLV as described in Section 4.4 in [RFC8029] and
   respond according to [RFC8029] processing rules.



                           +-----------------+
                           |                 |
                           |                 |
         +----+ AC1  +-----+                 +-----+     +----+
         | CE1|------|     |                 | PE3 |-----| CE2|
         +----+\     | PE1 |     IP/MPLS     |     |     +----+
                \    +-----+     Network     +-----+
                 \         |                 |
               AC2\  +-----+                 |
                   \ |     |                 |
                    \| PE2 |                 |
                     +-----+                 |
                           |                 |
                           +-----------------+

           <-802.1Q->  <------PBB over MPLS------>  <-802.1Q->

                          Figure 5: PBB-EVPN network



   Similarly, on PE3, when an operator performs a connectivity check for
   the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an
   LSP Ping request with the target FEC stack TLV containing EVPN MAC



Jain, et al.             Expires January 8, 2023                [Page 9]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   Sub-TLV in the Echo Request packet.  The Echo Request packet is sent
   with the {MPLS transport Label(s) to reach PE2, EVPN Label = 16002,
   GAL} MPLS label stack and IP ACH Channel header.

   LSP Ping operation for unicast data plane connectivity checks in
   EVPN, are similar to those described above for PBB-EVPN except that
   the checks are for C-MAC addresses instead of B-MAC addresses.

   In EVPN network, an operator can also perform MAC state test using
   aliasing label for the MAC to verify the MAC state on the remote
   multihoming PE that did not learn the MAC from the multihomed CE on a
   local ESI but has announced Ethernet AD per-EVI and per-ESI routes
   for the ESI.  This is due to the fact that MAC state on multihoming
   PEs that did not learn the MAC locally, get created from EVPN MAC/IP
   route advertisement from the multihoming PE that has learned the CE's
   MAC address locally.

6.2.  Inclusive Multicast Data-plane Connectivity Checks

6.2.1.  Ingress Replication

   Assume PE1 announced an Inclusive Multicast route for EVI 10, with RD
   1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel type
   set to ingress replication and downstream assigned inclusive
   multicast MPLS label 17001.  Similarly, PE2 announced an Inclusive
   Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID
   10), PMSI tunnel attribute Tunnel type set to ingress replication and
   downstream assigned inclusive multicast MPLS label 17002.

   Given CE1 is dual-homed to PE1 and PE2, assume that PE1 is the DF for
   ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc.
   44dd.5500.

   When an operator at PE3 initiates a connectivity check for the
   inclusive multicast on PE1, the operator initiates an LSP Ping
   request with the target FEC stack TLV containing EVPN Inclusive
   Multicast Sub-TLV in the Echo Request packet.  The Echo Request
   packet is sent with the {Transport Label(s) to reach PE1, EVPN Incl.
   Multicast Label = 17001, GAL} MPLS label stack and IP ACH Channel
   header.  Once the Echo Request packet reaches PE1, PE1 will use the
   GAL and the IP ACH Channel header to determine that the packet is
   IPv4 OAM Packet.  The packet will have EVPN Inclusive multicast
   label.  PE1 will process the packet and perform checks for the EVPN
   Inclusive Multicast Sub-TLV present in the Target FEC Stack TLV as
   described in Section 4.4 in [RFC8029] and respond according to
   [RFC8029] processing rules.  For the success case, PE1 will reply
   with Return Code 3 - "Replying router is an egress for the FEC at
   stack-depth".



Jain, et al.             Expires January 8, 2023               [Page 10]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   Similarly, an operator at PE3, may initiate an LSP Ping to PE2 with
   the target FEC stack TLV containing EVPN Inclusive Multicast sub-TLV
   in the Echo Request packet.  The Echo Request packet is sent with the
   {transport Label(s) to reach PE2, EVPN Incl.  Multicast Label =
   17002, GAL} MPLS label stack and IP ACH Channel header.  Once the
   Echo Request packet reaches PE2, PE2 will use the GAL and the IP ACH
   Channel header to determine that the packet is IPv4 OAM Packet.  The
   processing on PE2 will be similar to the that on PE1 as described
   above and for the success case, PE2 will reply with Return Code 3 -
   "Replying router is an egress for the FEC at stack-depth" as per
   [RFC8029].

   In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-
   TLV and the associated MPLS Split Horizon Label above the GAL in the
   MPLS label stack, may be added to emulate traffic coming from a
   multihomed site.  The Split Horizon label is used by leaf PE(s)
   attached to the same multihomed site to not forward packets back to
   the multihomed site.  If the behavior on a leaf PE is to not forward
   the packet to the multihomed site on the ESI identified by EVPN
   Ethernet AD Sub-TLV because of Split Horizon filtering, the PE will
   reply with a Return Code indicating that "Replying router is egress
   for the FEC at the stack depth.  In addition, the BUM packets are
   dropped on the ES corresponding to the ESI received in EVPN Ethernet
   AD Sub-TLV because of the Split Horizon Group filtering" as described
   in Section 8.

6.2.2.  Using P2MP P-tree

   Both inclusive P-Tree and aggregate inclusive P-tree can be used in
   EVPN or PBB-EVPN networks.

   When using an inclusive P-tree arrangement, p2mp p-tree transport
   label itself is used to identify the L2 service associated with the
   Inclusive Multicast Route, this L2 service could be a customer
   Bridge, or a Provider Backbone Bridge.

   For an Inclusive P-tree arrangement, when an operator performs a
   connectivity check for the multicast L2 service, the operator
   initiates an LSP Ping request with the target FEC stack TLV
   containing EVPN Inclusive Multicast Sub-TLV in the Echo Request
   packet.  The Echo Request packet is sent over P2MP LSP with the {P2MP
   P-tree label, GAL} MPLS label stack and IP ACH Channel header.

   When using Aggregate Inclusive P-tree, a PE announces an upstream
   assigned MPLS label along with the P-tree ID, so both the p2mp p-tree
   MPLS transport label and the upstream MPLS label can be used to
   identify the L2 service.




Jain, et al.             Expires January 8, 2023               [Page 11]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   For an Aggregate Inclusive P-tree arrangement, when an operator
   performs a connectivity check for the multicast L2 service, the
   operator initiates an LSP Ping request with the target FEC stack TLV
   containing EVPN Inclusive Multicast Sub-TLV in the Echo Request
   packet.  The Echo Request packet is sent over P2MP LSP using the IP-
   ACH Control channel with the {P2MP P-tree label, EVPN Upstream
   assigned Multicast Label, GAL} MPLS label stack and IP ACH Channel
   header.

   The Leaf PE(s) of the p2mp tree will process the packet and perform
   checks for the EVPN Inclusive Multicast Sub-TLV present in the Target
   FEC Stack TLV as described in Section 4.4 in [RFC8029] and respond
   according to [RFC8029] processing rules.  For the success case, the
   Leaf PE will reply with Return Code 3 - "Replying router is an egress
   for the FEC at stack-depth".

   In case of EVPN, in the Echo Request packet, an EVPN Ethernet AD Sub-
   TLV and the associated MPLS Split Horizon Label above the GAL in MPLS
   label stack, may be added to emulate traffic coming from a multihomed
   site.  In case of p2mp p-tree, the Split Horizon Label is upstream
   assigned and is received by all the leaf PEs of the p2mp-ptree.  The
   Split Horizon label is used by leaf PE(s) attached to the same
   multihomed site not to forward packets back to the multihomed site.
   If the behavior on a leaf PE is to not forward the packet to the
   multihomed site on the ESI in EVPN Ethernet AD Sub-TLV because of
   Split Horizon filtering, the PE will reply with a Return Code
   indicating that "Replying router is egress for the FEC at the stack
   depth.  In addition, the BUM packets are dropped on the ES
   corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because
   of the Split Horizon Group filtering" as described in Section 8.  If
   the leaf PE does not have the ESI identified in the EVPN Ethernet AD
   Sub-TLV, the PE can reply with a Return Code indicating that
   "Replying router is egress for the FEC at the stack depth.  In
   addition, the BUM packets are forwarded because there is no ES
   corresponding to the ESI received in EVPN Ethernet AD Sub-TLV".

6.2.3.  Controlling Echo Responses when using P2MP P-tree

   The procedures described in [RFC6425] for preventing congestion of
   Echo Responses (Echo Jitter TLV) and limiting the Echo Reply to a
   single egress node (Node Address P2MP Responder Identifier TLV) can
   be applied to LSP Ping in PBB EVPN and EVPN when using P2MP P-trees
   for broadcast, multicast, and unknown unicast traffic.








Jain, et al.             Expires January 8, 2023               [Page 12]


Internet-Draft              MPLS OAM for EVPN                  July 2022


6.3.  EVPN Aliasing Data-plane connectivity check

   Assume PE1 announced an Ethernet AD per-EVI Route with the ESI set to
   CE1 system ID and MPLS label 19001, and PE2 an Ethernet AD per-EVI
   Route with the ESI set to CE1 system ID and MPLS label 19002.

   At PE3, when an operator performs a connectivity check for the
   aliasing aspect of the EVPN Ethernet AD route on PE1, the operator
   initiates an LSP Ping request with the target FEC stack TLV
   containing EVPN Ethernet AD Sub-TLV in the Echo Request packet.  The
   Echo Request packet is sent with the {Transport label(s) to reach
   PE1, EVPN Ethernet AD Label 19001, GAL} MPLS label stack and IP ACH
   Channel header.

   When PE1 receives the packet it will process the packet and perform
   checks for the EVPN Ethernet AD Sub-TLV present in the Target FEC
   Stack TLV as described in Section 4.4 in [RFC8029] and respond
   according to [RFC8029] processing rules.

6.4.  EVPN IP Prefix (RT-5) Data-plane connectivity check

   Assume PE1 in Figure 5, announced an IP Prefix Route (RT-5) with an
   IP prefix reachable behind CE1 and MPLS label 20001.  When an
   operator on PE3 performs a connectivity check for the IP prefix on
   PE1, the operator initiates an LSP Ping request with the target FEC
   stack TLV containing EVPN IP Prefix Sub-TLV in the Echo Request
   packet.  The Echo Request packet is sent with the {Transport label(s)
   to reach PE1, EVPN IP Prefix Label 20001 } MPLS label stack.

   When PE1 receives the packet it will process the packet and perform
   checks for the EVPN IP Prefix Sub-TLV present in the Target FEC Stack
   TLV as described in Section 4.4 in [RFC8029] and respond according to
   [RFC8029] processing rules.

7.  Security Considerations

   The proposal introduced in this document does not introduce any new
   security considerations beyond that already apply to [RFC7432],
   [RFC7623] and [RFC6425].

8.  IANA Considerations

8.1.  Sub-TLV Type

   This document defines four new Sub-TLV type to be included in Target
   FEC Stack TLV (TLV Type 1, 16 and 21) [RFC8029] in Echo Request and
   Echo Reply messages in EVPN and PBB-EVPN network.




Jain, et al.             Expires January 8, 2023               [Page 13]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   IANA is requested to assign lowest 4 free values for the four Sub-
   TLVs listed below from the Standards Track" (0-16383) range, in the
   "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry, in the "TLVs"
   registry in the "Multiprotocol Label Switching (MPLS) Label Switched
   Paths (LSPs) Ping Parameters" name space:

   o  EVPN MAC/IP Sub-TLV

   o  EVPN Inclusive Multicast Sub-TLV

   o  EVPN Auto-Discovery Sub-TLV

   o  EVPN IP Prefix Sub-TLV

8.2.  Proposed new Return Codes

   [RFC8029] defines values for the Return Code field of Echo Reply.
   This document proposes two new Return Codes, which SHOULD be included
   in the Echo Reply message by a PE in response to Echo Request message
   in EVPN and PBB-EVPN network.

   IANA is requested to assign 2 lowest free values for the 2 Retuen
   Codes listed below from the Return Codes" registry in the
   "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters" name space:

   o  Replying router is egress for the FEC at the stack depth.  In
      addition, the BUM packets are dropped on the ES corresponding to
      the ESI received in EVPN Ethernet AD Sub-TLV because of the Split
      Horizon Group filtering.

   o  Replying router is egress for the FEC at the stack depth.  In
      addition, the BUM packets are forwarded because there is no ES
      corresponding to the ESI received in EVPN Ethernet AD Sub-TLV.

9.  Acknowledgments

   The authors would like to thank Loa Andersson, Alexander Vainshtein,
   Ron Sdayoor, Patrice Brissette and Weiguo Hao for their valuable
   comments.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Jain, et al.             Expires January 8, 2023               [Page 14]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

   [RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
              Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
              Failures in Point-to-Multipoint MPLS - Extensions to LSP
              Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
              <https://www.rfc-editor.org/info/rfc6425>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
              Henderickx, "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
              September 2015, <https://www.rfc-editor.org/info/rfc7623>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9136]  Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
              A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
              (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
              <https://www.rfc-editor.org/info/rfc9136>.

Authors' Addresses

   Parag Jain (editor)
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, ON  K2K 3E8
   Canada

   Email: paragj@cisco.com






Jain, et al.             Expires January 8, 2023               [Page 15]


Internet-Draft              MPLS OAM for EVPN                  July 2022


   Ali Sajassi
   Cisco Systems, Inc.
   USA

   Email: sajassi@cisco.com


   Samer Salam
   Cisco Systems, Inc.
   595 Burrard Street, Suite 2123
   Vancouver, BC  V7X 1J1
   Canada

   Email: ssalam@cisco.com


   Sami Boutros
   Ciena
   USA

   Email: sboutros@ciena.com


   Greg Mirsky
   Ericsson
   USA

   Email: gregimirsky@gmail.com























Jain, et al.             Expires January 8, 2023               [Page 16]