<?xml version="1.0" encoding="UTF-8"?>
<rfc category="std" docName="draft-zl-bess-evpn-srv6-oam-00" submissionType="IETF"
ipr="trust200902" consensus="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xi="http://www.w3.org/2001/XInclude">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="EVPN SRv6 OAM">
    OAM for EVPN over SRv6</title>
    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Xiaoqiu Zhang" initials="X."
            surname="Zhang">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <country>China</country>
        </postal>
        <email>zhangxiaoqiu@chinamobile.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	
    <author fullname="Changwang Lin" initials="C."
            surname="Lin" role="editor">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2025" />
    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>BESS Workgroup</workgroup>

    <keyword>OAM</keyword>
    <keyword>EVPN</keyword>
    <keyword>SRv6</keyword>

<abstract>
<t>
	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.
</t>

</abstract>

  </front>

  <middle>

<section anchor="Introduction" title="Introduction">
<t>
  <xref target="RFC9489"/> describes Operation, Administration, and Maintenance (OAM) mechanisms
  for detecting data plane failures using Label Switched Path (LSP) Ping <xref target="RFC8029"/>
  in MPLS networks deploying Ethernet VPN (EVPN).
</t>
<t>
  Segment Routing over IPv6 (SRv6) network is a new programmable network architecture
  based on IPv6 <xref target="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 <xref target="RFC8986"/>.
</t>
<t>
  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.
</t>
<t>
  This document defines procedures to detect data plane failures based on LSP Ping in SRv6-based EVPN networks.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>
  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 <xref target="RFC2119"/> <xref
  target="RFC8174"/> when, and only when, they appear in all
  capitals, as shown here.
</t>
</section>
<section anchor="Encapsulation" title="Encapsulation of OAM Ping Packets">
<t>
  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 <xref target="RFC9489"/>.
</t>
  <section anchor="Message Format-1" title="Format with Two-Layer Ethernet Header">
    <t>
      This section defines an encapsulation format including two-layer Ethernet Header, as illustrated in Figure 1.
    </t>
    <t><figure>
      <artwork align="center" name="Figure 1"><![CDATA[
+---------------------------------------+
|       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]]></artwork>
    </figure></t>
    <t>
      The External Ethernet Header: as defined in Section 3 of <xref target="RFC2464"/>,
      encapsulates the Destination and Source MAC addresses of intermediate forwarding devices.
    </t>
    <t>
      The External IPv6 Header: as defined in Section 3 of <xref target="RFC8200"/>,
      mainly encapsulates the Destination and Source IPv6 addresses of intermediate forwarding devices.
    </t>
    <t>
      The Segment Routing Header: as defined in Section 2 of <xref target="RFC8754"/>,
      primarily encapsulates the forwarding path information via a segment list in SRv6 network.
    </t>
    <t>
      The Internal Ethernet Header: as defined in Section 3 of <xref target="RFC2464"/>,
      encapsulates the Destination MAC address using a Virtual MAC address.
    </t>
    <t>
      The Internal IPv6 Header: as defined in Section 3 of <xref target="RFC8200"/>,
      mainly encapsulates the Destination IPv6 address using Loopback address.
    </t>
    <t>
      The UDP Header: as defined in <xref target="RFC768"/>, mainly encapsulates the Destination and Source Port.
      The Destination Port MUST be set to 3503 (assigned by IANA for MPLS echo requests).
    </t>
    <t>
      The MPLS Echo Request/Reply: as defined in Section 3 of <xref target="RFC8029"/>,
      encapsulates the core information of OAM Ping Packet.
      The information contained in this field is consistent with Section 4 of <xref target="RFC9489"/>.
    </t>
  </section>
  <section anchor="Message Format-2" title="Format with One-Layer Ethernet Header">
    <t>
      This section defines an encapsulation format including one-layer Ethernet Header, as illustrated in Figure 2.
    </t>
    <t><figure>
      <artwork align="center" name="Figure 2"><![CDATA[
+---------------------------------------+
|       Ethernet Header                 |
+---------------------------------------+
|       IPv6 Header                     |
+---------------------------------------+
|       Segment Routing Header          |
+---------------------------------------+
|       UDP Header                      |
+---------------------------------------+
|       MPLS Echo Request/Reply         |
+---------------------------------------+

   Figure 2: One-Layer Ethernet Format]]></artwork>
    </figure></t>
    <t>
      The Ethernet Header: as defined in Section 3 of <xref target="RFC2464"/>,
      encapsulates the Destination and Source MAC addresses of intermediate forwarding devices.
    </t>
    <t>
      The IPv6 Header: as defined in Section 3 of <xref target="RFC8200"/>,
      mainly encapsulates the Destination and Source IPv6 addresses of intermediate forwarding devices.
    </t>
    <t>
      The Segment Routing Header: as defined in Section 2 of <xref target="RFC8754"/>,
      primarily encapsulates the forwarding path information via a segment list in SRv6 network.
    </t>
    <t>
      The UDP Header: as defined in <xref target="RFC768"/>, mainly encapsulates the Destination and Source Port.
      The Destination Port MUST be set to 3503 (assigned by IANA for MPLS echo requests).
    </t>
    <t>
      The MPLS Echo Request/Reply: as defined in Section 3 of <xref target="RFC8029"/>,
      encapsulates the core information of OAM Ping Packet.
      The information contained in this field is consistent with Section 4 of <xref target="RFC9489"/>.
    </t>
  </section>
</section>

<section anchor="Security Considerations" title="Security Considerations">
<t>
	TBD
</t>
</section>

<section anchor="IANA Considerations" title="IANA Considerations">
<t>
  This document does not require an IANA allocation.
</t>
</section>

<!-- <section anchor="Acknowledgements" title="Acknowledgements">
<t>
	The author would like to thank xxx for his valuable input.
</t>
</section> -->

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  <references title="References">
    <references title="Normative References">
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.768.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9489.xml"/>
    </references>
  </references>
  </back>
</rfc>
