RFC 9489

Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)

📅 published November 2023, from ietf

RFC 9489: Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) 💖

okay bestie, this one is RFC 9489 from the IETF, and it's a Standards Track doc 👑 It was dated November 2023 and written by P. Jain, A. Sajassi, and S. Salam (all from Cisco), plus S. Boutros (Ciena) and G. Mirsky (Ericsson). The ISSN is 2070-1721 if you're keeping receipts 🧾 The title block doesn't list anything it obsoletes or updates, so this RFC isn't replacing or patching any other RFC 🌸

Abstract ✨

LSP Ping is the OG health check for MPLS networks 💅 It's a widely deployed Operations, Administration, and Maintenance (OAM) mechanism, and this doc explains how to use it to catch data plane failures in MPLS-based Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) networks 🫶

Status of This Memo 📜

Bestie, this is an Internet Standards Track document, so it's the real deal 👑

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🎀

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9489 🔗

Copyright (c) 2023 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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🙈

Table of Contents 🗂️

1.  Introduction
2.  Specification of Requirements
3.  Terminology
4.  Target FEC Stack Sub-TLVs
  4.1.  EVPN MAC/IP Sub-TLV
  4.2.  EVPN Inclusive Multicast Sub-TLV
  4.3.  EVPN Ethernet Auto-Discovery (A-D) Sub-TLV
    4.3.1.  Ethernet Tag Value
    4.3.2.  Per-ES EVPN Auto-Discovery Route with Different RDs
    4.3.3.  EVPN VPWS
  4.4.  EVPN IP Prefix Sub-TLV
5.  Encapsulation of OAM Ping Packets
6.  Operations
  6.1.  Unicast Data Plane Connectivity Checks
  6.2.  Inclusive Multicast Data Plane Connectivity Checks
    6.2.1.  Ingress Replication
    6.2.2.  Using P2MP P-Tree
    6.2.3.  Controlling Echo Responses When Using P2MP P-Tree
  6.3.  EVPN Aliasing Data Plane Connectivity Check
  6.4.  EVPN IP Prefix (RT-5) Data Plane Connectivity Check
7.  Security Considerations
8.  IANA Considerations
  8.1.  Sub-TLV Type
  8.2.  New Return Codes
9.  Normative References
Acknowledgments
Authors' Addresses

1. Introduction 🎀

[RFC7432] is the one that describes MPLS-based EVPN technology 🦋 An EVPN has one or more Customer Edge devices (CEs) hooked up to one or more Provider Edge devices (PEs). The PEs give Layer 2 (L2) EVPN between the CE(s) over the MPLS core. In EVPN networks, the PEs advertise the Media Access Control (MAC) addresses they learn from their local CE(s), along with the MPLS label, to remote PE(s) in the control plane. They do that with multiprotocol BGP [RFC4760]. EVPN also lets CE(s) multihome to multiple PEs and balances traffic to and from those multihomed CE(s) ✨

[RFC7623] covers Provider Backbone Bridging EVPN. PBB-EVPN keeps Customer MAC (C-MAC) learning in the data plane, and only advertises Backbone MAC (B-MAC) addresses in the control plane using BGP 💜

Procedures for simple, efficient ways to detect data plane failures with LSP Ping in MPLS networks are already well defined in [RFC8029] and [RFC6425] 🌸 The core idea is to send an MPLS Echo Request packet along the same data path as the data packets in the same Forwarding Equivalent Class (FEC). The Echo Request carries the FEC being verified in the Target FEC Stack TLV [RFC8029]. Once the Echo Request reaches the end of the MPLS path, it's sent up to the control plane of the egress PE. The Echo Request has enough info to verify that the data plane is correct and to check the data plane against the control plane 🔍 The egress PE then sends the validation results back in an Echo Reply packet to the originating PE of the Echo Request 💅

This document defines how to detect data plane failures with LSP Ping in MPLS networks running EVPN and PBB-EVPN 🧚 It defines four new sub-TLVs for the Target FEC Stack TLV, and their whole purpose is identifying the FEC on the egress PE 🫶

2. Specification of Requirements 🔑

Okay, the key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In this document they're read as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they show up in all capitals, just like here 🙌

3. Terminology 📖

Here's the glossary, so everyone's on the same page 💖

  • A-D: Auto-Discovery
  • B-MAC: Backbone MAC
  • BUM: Broadcast, Unknown Unicast, and Multicast
  • CE: Customer Edge device
  • C-MAC: Customer MAC
  • 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
  • FEC: Forwarding Equivalent Class
  • G-ACh: Generic Associated Channel
  • GAL: G-ACh Label
  • MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on a PE
  • ND: Neighbor Discovery
  • OAM: Operations, Administration, and Maintenance
  • P2MP: Point-to-Multipoint
  • PBB-EVPN: Provider Backbone Bridging EVPN
  • PE: Provider Edge device
  • VPWS: Virtual Private Wire Service

4. Target FEC Stack Sub-TLVs 🌈

Section 4 is where the four new Target FEC Stack sub-TLVs live 💜 They get included in the MPLS Echo Request packet, and those Echo Requests are used for data plane connectivity checks in EVPN and PBB-EVPN networks ✨ The Target FEC Stack sub-TLVs MAY be used to validate that an identifier for a given EVPN is programmed at the target node 🫧

4.1. EVPN MAC/IP Sub-TLV 💖

okay bestie, this sub-TLV is the one that names the target MAC, the MAC/IP binding for ARP/ND, or the IP address for an EVI under test at an egress PE 🎀. It rides along in the Echo Request that an EVPN/PBB-EVPN PE sends to a peer PE ✨

The fields are basically borrowed from the MAC/IP Advertisement route in Section 7.2 of [RFC7432] 💅, and they look like Figure 1 below. The fields should be set like this, which is consistent with [RFC7432] and [RFC7623] 🦋:

  • The Ethernet Tag ID field can be 0 or a valid VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of this field is always 0 as per Section 5.2 of [RFC7623].
  • The Ethernet Segment Identifier field is a 10-octet field. For EVPN, it is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES. For PBB-EVPN, the Ethernet Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load balancing) or to MAX-ESI (for multihomed segments with per-flow load balancing) as described in Section 5.2 of [RFC7623].
  • The MAC Addr Len field specifies the MAC length in bits. Only 48-bit MAC addresses are supported, as this document follows the MAC address length supported by [RFC7432].
  • The MAC Address field is set to the 6-octet MAC address.
  • 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 set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
  • The Must Be Zero fields are set to 0. The receiving PE should ignore the Must Be Zero fields.
    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/IP Sub-TLV Format

The MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) associated with the MAC/IP Advertisement route announced by the egress PE, plus the MPLS transport label(s) to reach the egress PE 🚀.

In EVPN, the MAC/IP Advertisement route is a multitasker 🧚 and gets used for the following cases:

  • This route with only a MAC address and MPLS Label1 is used for populating MAC-VRF and performing MAC forwarding.
  • 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.
  • 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 and IP forwarding in the case of symmetric Integrated Routing and Bridging (IRB).

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 the EVPN MPLS label of the packet, determine which of the three cases above this Echo Request is for 🔍. When the egress PE receives the EVPN MAC/IP sub-TLV containing only the MAC address, the egress PE validates the MAC state and forwarding. When the egress PE receives the EVPN MAC/IP sub-TLV containing both MAC and IP addresses and the EVPN label points to a MAC-VRF, 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 (e.g., the egress PE receiving the EVPN MAC/IP sub-TLV containing only the MAC address but with the EVPN label pointing to an IP-VRF) should be considered invalid, and the egress PE should send an Echo Reply with the appropriate Return Code to the ingress PE 🙈.

Mixing up the label and the sub-TLV contents is how you get an invalid combo, so double-check which one you're sending, bestie 💀.

4.2. EVPN Inclusive Multicast Sub-TLV 🌈

The fields of the EVPN Inclusive Multicast sub-TLV are based on the EVPN Inclusive Multicast Tag route defined in Section 7.3 of [RFC7432] 🦋. 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 🫶.

The EVPN Inclusive Multicast sub-TLV has the format shown in Figure 2. The fields of this sub-TLV should be set according to the following, which is consistent with [RFC7432] and [RFC7623] 💜:

  • The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE.
  • For EVPN, the Ethernet Tag ID field can be set to 0 or a valid VLAN ID for EVPN VLAN-aware bundle service [RFC7432]. For PBB-EVPN, the value of this field is set to the Service Instance Identifier (I-SID) value as per Section 5.3 of [RFC7623].
  • The IP Addr Len field specifies the length of the Originating Router's IP Addr field in bits and is set to either 32 for IPv4 addresses or 128 for IPv6 addresses.
  • The Originating Router's IP Addr field is set to the IPv4 or IPv6 address of the peer PE.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Route Distinguisher                        |
   |                        (8 octets)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Ethernet Tag ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP Addr Len |                                                 |
   +-+-+-+-+-+-+-+                                                 |
   ~               Originating Router's IP Addr                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: EVPN Inclusive Multicast Sub-TLV Format

BUM traffic can be sent using ingress replication or a P2MP P-tree in EVPN and PBB-EVPN networks 🌊. When using ingress replication, the Echo Request is sent using a label stack of [Transport label, Inclusive Multicast label] to each egress PE participating in EVPN or PBB-EVPN. The Inclusive Multicast label is the downstream-assigned label announced by the egress PE to which the Echo Request is being sent. The Inclusive Multicast label is the inner label in the MPLS label stack.

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

In an EVPN network, to emulate traffic coming from a multihomed site, an additional EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV and an ESI Split Horizon Group MPLS label as the bottom label are also included in the Echo Request packet 🍓. When using P2MP P-tree, the ESI Split Horizon Group MPLS label is upstream assigned. Please see Section 6.2.2 for operations using P2MP P-trees 💅.

4.3. EVPN Ethernet Auto-Discovery (A-D) Sub-TLV ✨

The fields in the EVPN Ethernet A-D sub-TLV are based on the EVPN Ethernet A-D route advertisement defined in Section 7.1 of [RFC7432] 🌸. The EVPN Ethernet A-D sub-TLV only applies to EVPN 🙌.

The EVPN Ethernet A-D sub-TLV has the format shown in Figure 3. The fields of this sub-TLV should be set according to the following, which is consistent with [RFC7432] 🦋:

  • The Route Distinguisher (RD) field is a 10-octet field and is set to the RD of the MAC-VRF on the peer PE. Please see Section 4.3.2 for the case when a per-ES A-D route is announced with different RDs.
  • The Ethernet Tag ID field can be 0, MAX-ET, or a valid VLAN ID as described in Section 4.3.1.
  • The Ethernet Segment Identifier field is a 10-octet field and is set to 0 for a single-homed ES or to a valid ESI ID for a multihomed ES.
  • The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field.
    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 A-D Sub-TLV Format

4.3.1. Ethernet Tag Value 🏷️

The EVPN Ethernet A-D sub-TLV can be sent in the context of per-ES or per-EVI 💖. When an operator performs a connectivity check for the BUM L2 service, an Echo Request packet is sent and MAY contain the EVPN Ethernet A-D sub-TLV to emulate traffic coming from a multihomed site. In this case, the EVPN Ethernet A-D sub-TLV is added in the per-ES context. When an Echo Request packet is sent for the connectivity check for EVPN Aliasing state, the context for the EVPN Ethernet A-D sub-TLV is per-EVI 🔥.

The Ethernet Tag field value in the EVPN Ethernet A-D sub-TLV MUST be set according to the context:

  • For the per-ES context, the Ethernet Tag field in the sub-TLV MUST be set to the reserved MAX-ET value [RFC7432] 👑.
  • For the per-EVI context, the Ethernet Tag field in the sub-TLV MUST be set to the non-reserved value 🌟.

4. Target FEC Stack Sub-TLVs (continued) ✨

4.3.2. Per-ES EVPN Auto-Discovery Route with Different RDs

okay so, [RFC7432] Section 8.2 says a per-ES EVPN A-D route for a multihomed ES can get advertised more than once with different RD values 🫶. Why? Lots of EVIs can be hooked up to the same ES, and all their Route Targets might not fit in one BGP Update message 😭. When that happens, the RD in the EVPN Ethernet A-D sub-TLV MUST be the RD that was received for the EVI in the per-ES EVPN A-D route. Make sure you match the right RD, bestie 💅🌸

4.3.3. EVPN VPWS

LSP Ping can also catch data plane failures for the EVPN VPWS described in [RFC8214] 🦋. The Echo Request carries the EVPN Ethernet A-D sub-TLV, and its fields are filled in from the EVPN Ethernet A-D per-EVI route the egress PE announced for the VPWS being tested. The ingress PE sends the Echo Request using the EVPN MPLS label tied to that A-D route, plus the MPLS transport label(s) that get it to the egress PE 🧚

The egress PE handles the Echo Request and does the checks for the EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV, as laid out in Section 4.4 of [RFC8029], then replies using the processing rules in [RFC8029] 👑. It can tell the Echo Request is for the EVPN VPWS instance because the EVI (identified by the RD) for EVPN VPWS is different from the EVI assigned for EVPN ✨. It uses the info from the EVPN Ethernet A-D sub-TLV to validate the VLAN state for the VPWS under test. If everything checks out, the egress PE replies with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") 💖

4.4. EVPN IP Prefix Sub-TLV

the EVPN IP Prefix sub-TLV tells you which IP prefix belongs to the EVI under test at a peer PE 🎀

These fields come from the IP Prefix route (RT-5) advertisement defined in [RFC9136]. This sub-TLV only applies to EVPN, so don't try it anywhere else 🙈

The EVPN IP Prefix sub-TLV looks like Figure 4. Its total length (not shown) MUST 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 be from the same IP address family, per Section 3.1 of [RFC9136] 🔥

Here's how the fields should be set, which lines up with [RFC9136] 💅:

  • The Route Distinguisher (RD) field is 10 octets and is set to the RD of the IP-VRF on the peer PE 💜.
  • The Ethernet Tag ID field can be 0 or a valid VLAN ID for the EVPN VLAN-aware bundle service [RFC7432] 🌈.
  • The Ethernet Segment Identifier field is 10 octets. It's set to a valid ESI ID if the ESI is used as an Overlay Index, per Section 3.1 of [RFC9136]. Otherwise, it's set to 0 🦋.
  • The IP Prefix Len field tells you how many bits are in the IP Prefix field. It's set to a value from 0 to 32 for IPv4, or from 0 to 128 for IPv6 ⭐.
  • The IP Prefix field is set to a 4-octet IPv4 address (padded with trailing 0 bits to make 32 bits total) or a 16-octet IPv6 address (padded with trailing 0 bits to make 128 bits total). The address family is inferred from the sub-TLV length field, as discussed above 🍓.
  • The GW (Gateway) 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 isn't being used, it must be set to 0, as described in Section 3.1 of [RFC9136]. The address family is inferred from the sub-TLV length field, as discussed above 🌸.
  • The Must Be Zero field is set to 0. The receiving PE should ignore the Must Be Zero field 🧚.
    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 MPLS Echo Request is sent by the ingress PE using the EVPN MPLS label(s) tied to the IP Prefix route the egress PE announced, plus the MPLS transport label(s) that reach the egress PE 🚀

5. Encapsulation of OAM Ping Packets

the MPLS Echo Request IP/UDP packets MUST be wrapped with the Transport and EVPN label(s), followed by the GAL [RFC5586], which is the bottommost label 🎀. The GAL is followed by a G-ACh header carrying the IPv4(0x0021) or IPv6(0x0057) Channel Type ✨. The code points for IPv4 and IPv6 channels are defined in the "Generic Associated Channel (G-ACh) Parameters" IANA registry 🌈

6. Operations

6.1. Unicast Data Plane Connectivity Checks

Figure 5 shows an example PBB-EVPN network 🦋. CE1 is dual-homed to PE1 and PE2. Say PE1 announced a MAC route with RD 192.0.2.1:00, B-MAC 00-AA-00-BB-00-CC, and MPLS label 16001 for EVI 10. PE2 announced a MAC route with RD 203.0.113.2:00, B-MAC 00-AA-00-BB-00-CC, and MPLS label 16002 💅

Now on PE3, when an operator checks connectivity for B-MAC 00-AA-00-BB-00-CC on PE1, they start an LSP Ping request. The Target FEC Stack TLV holds the EVPN MAC/IP sub-TLV in the Echo Request packet 👑. The Echo Request goes out with the {Transport label(s) to reach PE1, EVPN label = 16001, GAL} MPLS label stack and an IP ACH Channel header 🫶. Once it reaches PE1, PE1 uses the GAL and the IP ACH Channel header to figure out whether it's an IPv4 or IPv6 OAM packet. PE1 then processes the packet, checks the EVPN MAC/IP sub-TLV in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029], and responds using the processing rules in [RFC8029] 😭

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

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

                         Figure 5: PBB-EVPN Network

Same vibe on PE3 when the operator checks B-MAC 00-AA-00-BB-00-CC on PE2 🌸. They start an LSP Ping request, the Target FEC Stack TLV holds the EVPN MAC/IP sub-TLV in the Echo Request packet, and the Echo Request goes out with the {MPLS Transport label(s) to reach PE2, EVPN label = 16002, GAL} MPLS label stack and an IP ACH Channel header 🧚

LSP Ping for unicast data plane connectivity checks in EVPN works like the PBB-EVPN version above, except the checks are for C-MAC addresses instead of B-MAC addresses 💖

In EVPN networks, an operator can also run a MAC state test with an aliasing label for the MAC 🔥. This verifies the MAC state on an egress multihoming PE that didn't learn the MAC from the multihomed CE on a local ESI, but has announced Ethernet A-D per-EVI and per-ESI routes for that ESI. Why does this work? MAC state on multihoming PEs that didn't learn the MAC locally gets created from the EVPN MAC/IP route advertisement sent by the multihoming PE that did learn the CE's MAC address locally 🌈

6.2. Inclusive Multicast Data Plane Connectivity Checks

6.2.1. Ingress Replication ✨

Okay bestie, picture this 🎀 PE1 announces 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, and downstream-assigned Inclusive Multicast MPLS label 17001. PE2 does the same for EVI 10 with RD 203.0.113.2:00, Ethernet Tag (ISID 10), PMSI tunnel type set to ingress replication, and downstream-assigned Inclusive Multicast MPLS label 17002. 💖

Now, CE1 is dual-homed to PE1 and PE2, so let's say PE1 is the DF for ISID 10 on the port for the ESI 11aa.22bb.33cc.44dd.5500. The DF is the main character here 👑

When an operator at PE3 wants to check the Inclusive Multicast on PE1, they send an LSP Ping request with a Target FEC Stack TLV that holds the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. That Echo Request goes out with the {Transport label(s) to reach PE1, EVPN Inclusive Multicast label = 17001, GAL} MPLS label stack and an IP ACH Channel header. Once it lands on PE1, PE1 uses the GAL and the IP ACH Channel header to figure out whether it's an IPv4 or IPv6 OAM packet. The packet carries the EVPN Inclusive Multicast label, so PE1 processes it and runs the checks for the EVPN Inclusive Multicast sub-TLV in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029], then responds according to the processing rules in [RFC8029]. In the success case, PE1 replies with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>"). Slay 💅

PE3's operator can also ping PE2 the same way, with the EVPN Inclusive Multicast sub-TLV in the Target FEC Stack TLV of the Echo Request. This time the stack is {Transport label(s) to reach PE2, EVPN Inclusive Multicast label = 17002, GAL} plus the IP ACH Channel header. PE2 uses the GAL and the IP ACH Channel header to tell if it's an IPv4 or IPv6 OAM packet, and it handles things pretty much like PE1 does. In the success case, PE2 replies with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") as per [RFC8029]. 🦋

Here's a fun bit 🙈 In an EVPN Echo Request, you can combine an EVPN Ethernet A-D sub-TLV with the matching MPLS Split Horizon label, which sits right before the GAL in the MPLS label stack. This combo can be used to pretend the traffic is coming from a multihomed site. The Split Horizon label is what leaf PEs attached to that same multihomed site use so they don't send packets back into that site. If a leaf PE decides NOT to forward the packet to the multihomed site on the ESI from the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, it replies with Return Code 37 (see Section 8) and drops the BUM packets on the ES that matches the ESI from that A-D sub-TLV, because of the Split Horizon Group filtering. 🍓

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. Both options are on the table, babe 💜

With an Inclusive P-tree setup, the P2MP P-tree transport label is the thing that identifies the L2 service tied to the Inclusive Multicast route. That L2 service could be a Customer Bridge or a Provider Backbone Bridge. ✨

For an Inclusive P-tree, when an operator wants to check connectivity for the multicast L2 service, they send an LSP Ping request with a Target FEC Stack TLV containing the EVPN Inclusive Multicast sub-TLV in the Echo Request packet. The Echo Request goes over the P2MP LSP with the {P2MP P-tree Transport label, GAL} MPLS label stack and an IP ACH Channel header. 🌈

With an Aggregate Inclusive P-tree, a PE announces an upstream-assigned MPLS label along with the P-tree ID. That means both the P2MP P-tree MPLS transport label and the upstream MPLS label can be used together to identify the L2 service. Two labels, one vibe 🫶

For an Aggregate Inclusive P-tree, the operator sends an LSP Ping request again with the EVPN Inclusive Multicast sub-TLV in the Target FEC Stack TLV of the Echo Request packet. This time the Echo Request goes over the P2MP LSP using the IP-ACH Control channel, with the {P2MP P-tree Transport label, EVPN upstream-assigned Multicast label, GAL} MPLS label stack and an IP ACH Channel header. 🔥

The leaf PEs of the P2MP P-tree process the packet and run the checks for the EVPN Inclusive Multicast sub-TLV in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029], then respond according to the processing rules in [RFC8029]. In the success case, the leaf PE replies with Return Code 3 ("Replying router is an egress for the FEC at stack-depth <RSC>"). 👑

Back to the Split Horizon combo, because it gets a little extra with P2MP P-trees 🙈 In an EVPN Echo Request, the EVPN Ethernet A-D sub-TLV plus the associated MPLS Split Horizon label (right before the GAL) can emulate traffic from a multihomed site. When you're using a P2MP P-tree, the Split Horizon label is upstream assigned, and every leaf PE of the P2MP P-tree receives it. Leaf PEs attached to the same multihomed site use that label so packets don't get forwarded back into the site. If a leaf PE decides NOT to forward the packet to the multihomed site on the ESI in the EVPN Ethernet A-D sub-TLV because of Split Horizon filtering, it replies with Return Code 37 (see Section 8) and drops the BUM packets on the ES that matches the ESI received in the EVPN Ethernet A-D sub-TLV, because of the Split Horizon Group filtering. If a leaf PE doesn't have the ESI from the EVPN Ethernet A-D sub-TLV at all, the PE MAY reply with Return Code 38 (see Section 8), and the BUM packets get forwarded because there's no ES matching that ESI. Ngl, that last case is kind of iconic 💀

6.2.3. Controlling Echo Responses When Using P2MP P-Tree 🦋

Okay, so the procedures in [RFC6425] are how you keep Echo Responses from getting congested (that's the Echo Jitter TLV) and how you limit the Echo Reply to a single egress node (that's the P2MP Responder Identifier TLV, using either the IPv4 Node Address P2MP Responder sub-TLV or the IPv6 Node Address P2MP Responder sub-TLV). Those can both be applied to LSP Ping in EVPN and PBB-EVPN when P2MP P-trees are carrying BUM traffic. Calm and organised, just like we like it 🌸

6.3. EVPN Aliasing Data Plane Connectivity Check 💅

Let's say PE1 announced an Ethernet A-D per-EVI route with the ESI set to the CE1 system ID and MPLS label 19001. PE2 also announced an Ethernet A-D per-EVI route with the ESI set to the CE1 system ID, but with MPLS label 19002. Two PEs, same CE, very aliasing 🎀

At PE3, when an operator wants to check the aliasing side of the EVPN Ethernet A-D route on PE1, they send an LSP Ping request with a Target FEC Stack TLV containing the EVPN Ethernet A-D sub-TLV in the Echo Request packet. The Echo Request goes out with the {Transport label(s) to reach PE1, EVPN Ethernet A-D label 19001, GAL} MPLS label stack and an IP ACH Channel header. 💖

When PE1 gets the packet, it processes it and runs the checks for the EVPN Ethernet A-D sub-TLV in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029], then responds according to the processing rules in [RFC8029]. ✨

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 wants to check that IP prefix on PE1, they send an LSP Ping request with a Target FEC Stack TLV containing the EVPN IP Prefix sub-TLV in the Echo Request packet. The Echo Request goes out with the {Transport label(s) to reach PE1, EVPN IP Prefix label 20001 } MPLS label stack. 🧚

When PE1 receives the packet, it processes it and runs the checks for the EVPN IP Prefix sub-TLV in the Target FEC Stack TLV as described in Section 4.4 of [RFC8029], then responds according to the processing rules in [RFC8029]. Done and dusted 👑

7. Security Considerations 🔥

This document doesn't introduce any new security considerations beyond the ones that already apply in [RFC7432], [RFC7623], and [RFC6425]. The security considerations in [RFC8029] apply to this document too, and they need to be thought through. As [RFC8029] describes, those security considerations are:

  • A Denial-of-Service (DoS) attack by sending MPLS Echo Requests/Replies to Label Switching Routers (LSRs) and thereby increasing their workload. 💀
  • Obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS Echo Requests and Replies. 😭
  • Obtaining information about the network through an unauthorized source using an LSP Ping. 🙈

There are mitigations described in [RFC8029]. The same mitigations can be applied to the LSP Ping procedures described in this document, so this document doesn't require additional security considerations beyond the ones described in [RFC8029]. Mitigations are giving protection energy 🛡️💜

This document doesn't introduce any new privacy concerns, because these TLVs contain the same information that's present in data packets and EVPN routes. Nothing new to leak, periodt 🫶

8. IANA Considerations 🎀

8.1. Sub-TLV Type 🦋

This document defines four new sub-TLV types to be included in the Target FEC Stack TLV (TLV types 1, 16, and 21) [RFC9041] in Echo Request and Echo Reply messages in EVPN and PBB-EVPN networks. Four new sub-TLVs, four new vibes ✨

IANA has assigned the following values from the "Standards Action" (0-16383) range in the "Sub-TLVs for TLV Types 1, 16, and 21" subregistry within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space. 🌸

          +==========+==============================+===========+
          | Sub-Type | Sub-TLV Name                 | Reference |
          +==========+==============================+===========+
          | 42       | EVPN MAC/IP                  | RFC 9489  |
          +----------+------------------------------+-----------+
          | 43       | EVPN Inclusive Multicast     | RFC 9489  |
          +----------+------------------------------+-----------+
          | 44       | EVPN Ethernet Auto-Discovery | RFC 9489  |
          +----------+------------------------------+-----------+
          | 45       | EVPN IP Prefix               | RFC 9489  |
          +----------+------------------------------+-----------+

                                  Table 1

8.2. New Return Codes 🎀

okay so [RFC8029] already has the list of Return Code values for Echo Replies 💅 this doc adds two brand new ones, and a PE SHOULD be including one of them in the Echo Reply message whenever it's answering an Echo Request in EVPN and PBB-EVPN networks 🔥

IANA has assigned the following values in the "Return Codes" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space 🦋

+=======+=============================================+===========+
| Value | Meaning                                     | Reference |
+=======+=============================================+===========+
| 37    | Replying router is egress for the FEC at    | RFC 9489  |
|       | the stack depth.  In addition, the BUM      |           |
|       | packets are dropped on the ES corresponding |           |
|       | to the ESI received in the EVPN Ethernet    |           |
|       | Auto-Discovery sub-TLV because of the Split |           |
|       | Horizon Group filtering.                    |           |
+-------+---------------------------------------------+-----------+
| 38    | Replying router is egress for the FEC at    | RFC 9489  |
|       | the stack depth.  In addition, the BUM      |           |
|       | packets are forwarded because there is no   |           |
|       | ES corresponding to the ESI received in the |           |
|       | EVPN Ethernet Auto-Discovery sub-TLV.       |           |
+-------+---------------------------------------------+-----------+

Table 2 ✨

  • 37 means the replying router is the egress for the FEC at the stack depth, AND the BUM packets are dropped on the ES for the ESI from the EVPN Ethernet Auto-Discovery sub-TLV because of Split Horizon Group filtering 🙈
  • 38 means the replying router is the egress for the FEC at the stack depth, AND the BUM packets are forwarded because there's no ES for that ESI 💀

9. Normative References 📚

these are the references the spec leans on hardest, so here they all are, every detail included 🫶

Acknowledgments 🌸

the authors want to thank Loa Andersson, Alexander Vainshtein, Ron Sdayoor, Jim Guichard, Lars Eggert, John Scudder, Éric Vyncke, Warren Kumari, Patrice Brissette, and Weiguo Hao for their valuable comments 🫶💖

Authors' Addresses 🦋

  • Parag Jain
    • Cisco
    • Canada
    • Email: paragj@cisco.com
  • Ali Sajassi
    • Cisco
    • United States of America
    • Email: sajassi@cisco.com
  • Samer Salam
    • Cisco
    • Canada
    • Email: ssalam@cisco.com
  • Sami Boutros
    • Ciena
    • United States of America
    • Email: sboutros@ciena.com
  • Greg Mirsky
    • Ericsson
    • United States of America
    • Email: gregimirsky@gmail.com

the end, bestie 🌈✨👑

📦 where this page comes from