| Internet-Draft | EVPN SRv6 OAM | October 2025 |
| Zhang & Lin | Expires 23 April 2026 | [Page] |
RFC 9489 describes Operation, Administration, and Maintenance (OAM) mechanisms for detecting data plane failures using Label Switched Path (LSP) Ping in MPLS-based Ethernet VPN (EVPN) networks. However, there is no effective OAM mechanism for detecting data plane failures in SRv6-based EVPN networks. This document proposals OAM mechanisms for SRv6-based EVPN networks.¶
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 23 April 2026.¶
Copyright (c) 2025 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 to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC9489] describes Operation, Administration, and Maintenance (OAM) mechanisms for detecting data plane failures using Label Switched Path (LSP) Ping [RFC8029] in MPLS networks deploying Ethernet VPN (EVPN).¶
Segment Routing over IPv6 (SRv6) network is a new programmable network architecture based on IPv6 [RFC8402]. It carries path instructions through native IPv6 headers which is followed by the Segment Routing Header (SRH) to implement software-defined traffic scheduling and service chain processing [RFC8986].¶
The SRv6 network also could deploy EVPN, which is applied to scenarios such as enterprise private lines, data center interconnection, and 5G bearer networks. However, there is no effective OAM mechanism for detecting data plane failures in SRv6-based EVPN networks.¶
This document defines procedures to detect data plane failures based on LSP Ping in SRv6-based EVPN networks.¶
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.¶
This section defines two Encapsulation Formats using the MPLS Echo Request packet for OAM Ping Packets in SRv6 networks deploying EVPN. The OAM Ping procedure is similar to that described in [RFC9489].¶
This section defines an encapsulation format including two-layer Ethernet Header, as illustrated in Figure 1.¶
+---------------------------------------+ | External Ethernet Header | +---------------------------------------+ | External IPv6 Header | +---------------------------------------+ | Segment Routing Header | +---------------------------------------+ | Internal Ethernet Header | +---------------------------------------+ | Internal IPv6 Header | +---------------------------------------+ | UDP Header | +---------------------------------------+ | MPLS Echo Request/Reply | +---------------------------------------+ Figure 1: Two-Layer Ethernet Format¶
The External Ethernet Header: as defined in Section 3 of [RFC2464], encapsulates the Destination and Source MAC addresses of intermediate forwarding devices.¶
The External IPv6 Header: as defined in Section 3 of [RFC8200], mainly encapsulates the Destination and Source IPv6 addresses of intermediate forwarding devices.¶
The Segment Routing Header: as defined in Section 2 of [RFC8754], primarily encapsulates the forwarding path information via a segment list in SRv6 network.¶
The Internal Ethernet Header: as defined in Section 3 of [RFC2464], encapsulates the Destination MAC address using a Virtual MAC address.¶
The Internal IPv6 Header: as defined in Section 3 of [RFC8200], mainly encapsulates the Destination IPv6 address using Loopback address.¶
The UDP Header: as defined in [RFC768], mainly encapsulates the Destination and Source Port. The Destination Port MUST be set to 3503 (assigned by IANA for MPLS echo requests).¶
The MPLS Echo Request/Reply: as defined in Section 3 of [RFC8029], encapsulates the core information of OAM Ping Packet. The information contained in this field is consistent with Section 4 of [RFC9489].¶
This section defines an encapsulation format including one-layer Ethernet Header, as illustrated in Figure 2.¶
+---------------------------------------+ | Ethernet Header | +---------------------------------------+ | IPv6 Header | +---------------------------------------+ | Segment Routing Header | +---------------------------------------+ | UDP Header | +---------------------------------------+ | MPLS Echo Request/Reply | +---------------------------------------+ Figure 2: One-Layer Ethernet Format¶
The Ethernet Header: as defined in Section 3 of [RFC2464], encapsulates the Destination and Source MAC addresses of intermediate forwarding devices.¶
The IPv6 Header: as defined in Section 3 of [RFC8200], mainly encapsulates the Destination and Source IPv6 addresses of intermediate forwarding devices.¶
The Segment Routing Header: as defined in Section 2 of [RFC8754], primarily encapsulates the forwarding path information via a segment list in SRv6 network.¶
The UDP Header: as defined in [RFC768], mainly encapsulates the Destination and Source Port. The Destination Port MUST be set to 3503 (assigned by IANA for MPLS echo requests).¶
The MPLS Echo Request/Reply: as defined in Section 3 of [RFC8029], encapsulates the core information of OAM Ping Packet. The information contained in this field is consistent with Section 4 of [RFC9489].¶
This document does not require an IANA allocation.¶