<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-fu-bess-evpn-vpws-seamless-00"
     ipr="trust200902">
  <front>
    <title abbrev="L2VPN VPWS Seamless with EVPN VPWS over SRv6">L2VPN VPWS
    Seamless with EVPN VPWS over SRv6</title>

    <author fullname="Zheng Fu" initials="Z." surname="Fu">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>No.101 Software Avenue, Yuhuatai District</street>

          <city>Nanjing</city>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>fuzheng7@huawei.com</email>
      </address>
    </author>

    <author fullname="Tong Zhu" initials="T," surname="Zhu">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>No.101 Software Avenue, Yuhuatai District.</street>

          <city>Nanjing</city>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>zhu.tong@huawei.com</email>
      </address>
    </author>

    <author fullname="HuaJun Ren" initials="H." surname="Ren">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>No.101 Software Avenue, Yuhuatai District</street>

          <city>Nanjing</city>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>renhuajun@huawei.com</email>
      </address>
    </author>

    <date day="11" month="July" year="2022"/>

    <abstract>
      <t>This document provides a solution for migrating L2VPN virtual private
      wire service(VPWS) to Ethernet VPN Virtual Private wire service
      (EVPN-VPWS) over SRv6. The service provider may want to migrate L2VPN
      VPWS to EVPN-VPWS, and deploy EVPN-VPWS over SRv6 network. When
      co-existing of EVPN-VPWS over SRv6 network and a legacy L2VPN VPWS over
      MPLS/IP network, the next hop of the EVPN Ethernet-AD per EVI route is
      different from the nexthop of VPWS AD routes or the source of LDP-LM
      message of the legacy L2VPN VPWS. As a result, whether the pseudowire of
      the EVPN VPWS and legacy L2VPN VPWS is same cannot be identified by the
      next hop of the EVPN Ethernet-AD per EVI route and VPWS AD routes or LDM
      messages. This document provides a solution to identify whether the
      pseudowire of EVPN VPWS is same with the pseudowire of L2VPN VPWS, which
      allows migrating VPWS to EVPN-VPWS under the same vpn instance but over
      different network.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in [RFC2119].</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>In a scenario where a legacy L2VPN VPWS migrate to an EVPN VPWS <xref
      target="RFC8214"/>Over SRv6, in figure1, the Compsite PE1 <xref
      target="I-D.brissette-bess-evpn-vpws-seamless"/>sends LDP-LM
      message<xref target="RFC4761"/>/VPWS AD routes <xref
      target="RFC4762"/>and EVPN Ethernet-AD per EVI route at the same time.
      When the Compsite PE2 receives the LDP-LM message/VPWS AD routes and
      EVPN Ethernet-AD EVI routes, PE2 use the EVPN Ethernet-AD per EVI route
      highly proirity. </t>

      <t>In an EVPN VPWS over MPLS scenario, sevice provider could configure
      the next hop of the EVPN Ethernet-AD per EVI route to be the same as the
      source address of the LDP-LM message/VPWS AD route to identify the
      source. However, in the EVPN VPWS over SRv6 scenario, the next hop of
      the EVPN Ethernet-AD per EVI is an IPv6 address, which is different from
      the source address of the LDP-LM message/VPWS AD route.The <xref
      target="I-D.brissette-bess-evpn-vpws-seamless"/> does not describe the
      corresponding solution. Therefore, a solution needs to be provided to
      identify that LDP-LM message/VPWS AD route and EVPN Ethernet-AD per EVI
      routes come from the same device. </t>

      <t><figure>
          <artwork><![CDATA[                                                                    
  +--------+   +----------+                     +---------+         
  |  CE1   |   |          |                     |         |  +----+ 
  |        |---- PE1      \-------MPLS/IP PW-----   PE2   ---| CE2| 
  +--------+   |          |                     |         |  +----+ 
               +----------+-----SRv6 EVPN VPWS +---------+          
                L2VPN VPWS                     L2VPN VPWS           
                EVPN VPWS                       EVPN VPWS           
                                                                    
                    Figure 1
                                                                     
]]></artwork>
        </figure></t>
    </section>

    <section 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 BCP14
      [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
      shown here.</t>

      <t>"PE": Provider edge device. It is a unique access point for users to
      access the carrier network.</t>

      <t>"AC": A physical or logical link. It is used to connect a user edge
      device and a PE device.</t>
    </section>

    <section title="L2VPN VPWS Origin IP Extended Community">
      <t>This documents defines a new extended community, to be included with
      per-EVI Ethernet A-D routes.</t>

      <t>The L2VPN VPWS Origin IP extended community defined here is defined
      as follows:</t>

      <t><figure>
          <artwork align="center"><![CDATA[        0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type=0x06     | Sub-Type=0x0? |L2VPN VPWS Origin Ip     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~     L2VPN VPWS Origin Ip      |           reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                   Figure 1: L2VPN VPWS Origin IP Extended Community
]]></artwork>
        </figure></t>

      <t>When L2VPN VPWS and EVPN-VPWS SRv6 are in the same VPN instance, PE1
      advertises the EVPN Ethernet-AD per EVI route and LDP-LM message/VPWS AD
      route. The source address of pseudowire which the L2VPN VPWS estabishs
      can be obtained by EVPN VPWS instance. Thus the EVPN Ethernet-AD per EVI
      routet carries the L2VPN VPWS Origin IP extended community attribute.
      After receiving the LDP-LM message/VPWS AD route and EVPN Ethernet-AD
      per EVI route, PE2 compares the L2VPN VPWS Origin IP attribute in the
      EVPN Ethernet-AD per EVI route with the source IP address of the LDP-LM
      message/VPWS AD route. If the result is same, LDP-LM message/VPWS AD
      route and EVPN Ethernet-AD per EVI route are from the same device.</t>
    </section>

    <section title="Control plane processing">
      <t>In Figure 1, PE1 and PE2 procedures are as follow:</t>

      <t>1. In compsite PE1, L2VPN VPWS and EVPN VPWS SRv6 are in the same VPN
      instance, the EVPN VPWS instance obtains the source address of the L2VPN
      VPWS. And PE1 MUST send EVPN Ethernet-AD per EVI route with the L2VPN
      VPWS Origin IP extended community attribute.</t>

      <t>2. The compsite PE2 receives the LDP-LM message/VPWS AD route from
      PE1, it set up a L2VPN VPWS PW to that PE.</t>

      <t>3. The compsite PE2 receives the EVPN Ethernet-AD per EVI route with
      L2VPN VPWS Origin IP extended commuinty attribute, PE2 gets the value of
      the L2VPN VPWS Origin IP extended community attribute from EVPN
      Ethernet-AD per EVI route, PE2 check the value of the L2VPN VPWS Origin
      IP extended community whether is same with the source IP address from
      the received LDP-LM message/VPWS AD route or not. If the result is same,
      which means EVPN Ethernet-AD per EVI route from the same PE, PE2 may
      bring the L2VPN PW operationally down, and should select EVPN
      Ethernet-AD per EVI route high proirity, and set the pseudowire up which
      is estabished by EVPN VPWS.</t>
    </section>

    <section title="IANA considerations">
      <t>TBD</t>
    </section>

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

  <back>
    <references title="References">
      <?rfc include="reference.RFC.8214"
?>

      <?rfc include="reference.RFC.4762"?>

      <?rfc include="reference.RFC.4761"?>

      <?rfc include="reference.I-D.brissette-bess-evpn-vpws-seamless"?>
    </references>
  </back>
</rfc>
