<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?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-wang-bess-l3-accessible-evpn-06"
     ipr="trust200902">
  <front>
    <title abbrev="L3 Accessible EVPN">Layer-3 Accessible EVPN
    Services</title>

    <author fullname="Wei Wang" initials="W" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

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

        <email>weiwang94@foxmail.com</email>
      </address>
    </author>

    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

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

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Haibo Wang" initials="H" surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Building, No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>100095</code>

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

        <phone/>

        <facsimile/>

        <email>rainsword.wang@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="20" month="March" year="2024"/>

    <area>RTG Area</area>

    <workgroup>BESS Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This draft describes layer-3 accessible EVPN service interfaces, and
      proposes a new solution which can span layer-3 network. This solution
      allows each PE in EVPN network to maintain only one MAC-VRF.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t><xref target="RFC7432"/>defines three service interfaces for layer-2
      accessible EVPN: VLAN-Based Service Interface, VLAN-Bundle Service
      Interface and VLAN-Aware Bundle Service Interface. These three types of
      service interfaces can realize the isolation of layer-2 traffic of
      customers in different ways, as shown in Figure 1.</t>

      <figure>
        <artwork><![CDATA[             1:1           1:1
     +------+   +---------+   +------+
     |VID 11+---+  EVI 1  +---+VID 12|
     +------+   +---------+   +------+
     |VID 21+---+  EVI 2  +---+VID 22|
     +------+   +---------+   +------+
     |VID 31+---+  EVI 3  +---+VID 32|
     +------+   +---------+   +------+
     |VID 41+---+  EVI 4  +---+VID 42|
     +------+   +---------+   +------+

        VLAN-based Service Interface



            N:1                1:N
  +------+        +---------+        +------+
  |VID 11---------+         +--------+VID 12|
  +------+        +         +        +------+
  |VID 21+--------+         +--------+VID 22|
  +------+        +  EVI 1  +        +------+
  |VID 31+--------+         +--------+VID 32|
  +------+        +         +        +------+
  |VID 41+--------+         +--------+VID 42|
  +------+        +---------+        +------+

       VLAN-bundle Service Interface


         N:1                        1:N
            +----------------------+
  +------+  |+--------------------+|  +------+
  |VID 11+--++ Broadcast Domain 1 ++--+VID 12|
  +------+  |+--------------------+|  +------+
  |VID 21+--++ Broadcast Domain 2 ++--+VID 22|
  +------+  |+--------------------+|  +------+
  |VID 31+--++ Broadcast Domain 3 ++--+VID 32|
  +------+  |+--------------------+|  +------+
  |VID 41+--++ Broadcast Domain 4 ++--+VID 42|
  +------+  |+--------------------+|  +------+
            |                      |
            |        EVI 1         |
            +----------------------+

      VLAN-Aware Bundle Service Interface


           Figure 1: EVPN Service Interfaces Overview
]]></artwork>
      </figure>

      <t>For VLAN-based service interface, there is a one to one mapping
      between VID and EVI. Each EVI has a single broadcast domain so that
      traffic from different customers can be isolated.</t>

      <t>For VLAN-bundle service interface, there is a N to one mapping
      between VID and EVI. Each EVI has a single broadcast domain, but the MAC
      address MUST be unique that can be used for customer traffic
      isolation.</t>

      <t>For VLAN-aware bundle service interface, there is a N to one mapping
      between VID and EVI. Each EVI has multiple broadcast domains while the
      MAC address can overlap. One broadcast domain corresponds to one VID,
      which can be used to customer traffic isolation.</t>

      <t>In the scenarios corresponding to these service interfaces, CE-PE
      should be placed in the same Layer-2 network. In most of provider
      network, CE-PE need to cross a Layer-3 network, then the above service
      interfaces should be extended to adapt to the layer-3 network.</t>

      <t>In practical network operations, some users may require the
      L2--L3--L2 network connection method, as shown in Figure 2.</t>

      <t><figure>
          <artwork align="center"><![CDATA[                                +---+
                                |CE3|
                                +-+-+
                                  |
                           +------+------+
                           |             |
                           |     MAN     |
                           +------+------+
                                  |
                               +--+-+
               +-----+   +-----+ PE |------+     +-----+
               |     | +-+-+   +----+    +-+-+   |     |
  C-A---+---+  |     |                           |     |  +---+--C-A
        |CE1+--+ MAN +-+PE |  Backbone   |PE +---+ MAN +--+CE2|
  C-B---+---+  |     |                           |     |  +---+--C-B
               |     | +-+-+             +-+-+   |     |
               |     |                           |     |
               +-----+   +-----------------+     +-----+


                 Figure 2: LSI-aware bundle service interface scenario
]]></artwork>
        </figure>Assuming that the customer is a cross-regional bank, CE3
      represents its headquarter site, while CE1 and CE2 are branch sites of
      the bank located in different cities. In this structure, the
      headquarters serves as the core of the network, responsible for the
      management and control of the overall network; while the branches serve
      as edge nodes of the network, responsible for collecting local business
      data and uploading it to the headquarters. Each site needs to connect to
      the backbone network through the metropolitan area network of its city
      for communication. To ensure data security, communication between branch
      sites needs to be routed through the headquarters site first, and
      end-to-end L2 communication is adopted between the branch sites and the
      headquarters site. The backbone is an EVPN domain, and MANs are L3
      domains. The packets should be transmitted from CE to PE through
      VxLAN/IPSec tunnel. Due to the EVI cannot be transmitted in this
      scenario, we need an EVPN solution that can span the L3 network.</t>

      <t>In this draft, we describe three layer-3 accessible interfaces for
      EVPN, the above problem can be solved by using these L3 accessible
      interfaces.</t>

      <t/>
    </section>

    <section title="Conventions used in this document">
      <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 <xref target="RFC2119"/>
      .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this draft:<list style="symbols">
          <t>CE: Client Edge</t>

          <t>EVPN: BGP/MPLS Ethernet VPN, defined in <xref
          target="RFC7432"/></t>

          <t>IPSec: Internet Protocol Security, defined in <xref
          target="RFC4301"/></t>

          <t>PE: Provider Edge</t>

          <t>SPI: Security Parameters Index, defined in <xref
          target="RFC4301"/></t>

          <t>VNI: VXLAN Network Identifier (or VXLAN Segment ID), defined in
          <xref target="RFC7348"/></t>

          <t>VxLAN: Virtual eXtensible Local Area Network, defined in <xref
          target="RFC7348"/></t>
        </list></t>

      <t/>
    </section>

    <section title="Service Interfaces in layer-3 accessible EVPN">
      <t>In most of provider network, CE-PE need to cross a Layer-3 network.
      With this scenario, service interfaces defined in <xref
      target="RFC7432"/> should be extended to adapt to the layer-3 network.
      To achieve the traffic isolation, tunnel encapsulation technologies can
      be used.</t>

      <t>We define Logical Session Identifier(LSI) to distinguish the packets
      from different tunnels, which is related to VNI/SPI. The length of LSI
      is 16 bits.</t>

      <t>The layer-3 accessible interfaces for EVPN are shown in Figure 3,
      refer to <xref target="RFC7432"/></t>

      <t><figure>
          <artwork><![CDATA[                1:1           1:1
       +------+   +----------+   +------+
       |LSI 11+---+ MAC-VRF1 +---+LSI 12|
       +------+   +----------+   +------+
       |LSI 21+---+ MAC-VRF2 +---+LSI 22|
       +------+   +----------+   +------+
       |LSI 31+---+ MAC-VRF3 +---+LSI 32|
       +------+   +----------+   +------+
       |LSI 41+---+ MAC-VRF4 +---+LSI 42|
       +------+   +----------+   +------+

           LSI-based Service Interface



              N:1                1:N
    +------+        +----------+        +------+
    |LSI 11---------+          +--------+LSI 12|
    +------+        +          +        +------+
    |LSI 21+--------+          +--------+LSI 22|
    +------+        + MAC-VRF1 +        +------+
    |LSI 31+--------+          +--------+LSI 32|
    +------+        +          +        +------+
    |LSI 41+--------+          +--------+LSI 42|
    +------+        +----------+        +------+

          LSI-bundle Service Interface


           N:1                        1:N
              +----------------------+
    +------+  |+---------------------+|  +------+
    |LSI 11+--++   Logical Plane 1   ++--+LSI 12|
    +------+  |+---------------------+|  +------+
    |LSI 21+--++   Logical Plane 2   ++--+LSI 22|
    +------+  |+---------------------+|  +------+
    |LSI 31+--++   Logical Plane 3   ++--+LSI 32|
    +------+  |+---------------------+|  +------+
    |LSI 41+--++   Logical Plane 4   ++--+LSI 42|
    +------+  |+---------------------+|  +------+
              |                       |
              |       MAC-VRF 1       |
              +-----------------------+

         LSI-Aware Bundle Service Interface



           Figure 3: Layer-3 accessible EVPN Service Interfaces Overview
]]></artwork>
        </figure>For LSI-based service interface, there is a one to one
      mapping between LSI and MAC-VRF. Each MAC-VRF has a single logical plane
      so that traffic from different customers can be isolated.</t>

      <t>For LSI-bundle service interface, there is a N to one mapping between
      LSI and MAC-VRF. Each MAC-VRF has a single logical plane, but the MAC
      address MUST be unique that can be used for customer traffic
      isolation.</t>

      <t>For LSI-aware bundle service interface, there is a N to one mapping
      between LSI and MAC-VRF. Each MAC-VRF has multiple logical planes while
      the MAC address can overlap. One logical plane corresponds to one LSI,
      which can be used to customer traffic isolation.</t>
    </section>

    <section title="Solutions of LSI-aware bundle service interface">
      <t>For the scenario shown in Figure 2, where Backbone is EVPN domain,
      and the MANs are Layer-3 network. There is a 1:1 mapping between LSI and
      VNI, LSIs are used for traffic isolation. If customers need end-to-end
      L2 data transmission, the use of LSI is similar to VLAN ID.</t>

      <t>If each VNI has its own MAC-VRF, each PE and CE maintain an MAC-VRF
      for each deployment. The packets should be transmitted from CE to PE
      through VxLAN/IPSec tunnel. The EVI cannot be transmitted during this
      process, because it cannot be carried in VxLAN or IPSec header.</t>

      <t>This problem can be solved by using LSI information to identify
      different customer routes / traffic. As described above, LSI can be
      generated by VNI/SPI, and there is a one to one mapping between LSI and
      VNI/SPI. PEs should maintain the mapping table of LSI and VNI/SPI, so
      that they can distinguish different customer routes / traffic. LSI
      information can be transmitted by using Ethernet Tag ID or a newly
      defined ESI type.</t>
    </section>

    <section title="Protocol Extensions">
      <section title="Forwarding Plane">
        <section title="Extensions to VxLAN">
          <t>When the forwarding plane uses VxLAN tunnel technologies, we
          should extend the VxLAN GPE header to carry the LSI information, the
          extentions to the VxLAN GPE header is shown in Figure 4:<figure>
              <artwork align="center"><![CDATA[  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|S|Ver|I|P|B|O|               LSI             |Next Protocol  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                VXLAN Network Identifier (VNI) |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4: The extentions to VxLAN GPE header
]]></artwork>
            </figure></t>

          <t>We define a S bit. If S is set to 1, it means the field after O
          bit contains LSI information.</t>

          <t/>
        </section>
      </section>

      <section title="Control Plane">
        <t>We proposed two methods to advertise LSI information in control
        plane:</t>

        <t><list style="symbols">
            <t>Reusing the Ethernet Tag ID field. This method requires the
            update of <xref target="I-D.ietf-bess-evpn-prefix-advertisement"/>
            (Etherenet Tag ID is set to 0 for route type 5), and may arise
            some confuse with the original definition of Ethernet Tag ID.</t>

            <t>Using the newly defined ESI type as shown in Figure 5. This
            method can preserve the original purpose of ESI definition
            (multi-homing).</t>
          </list></t>

        <t><figure>
            <artwork align="center"><![CDATA[  +---+---+---+---+---+---+---+---+---+---+
  | T | Reserved  | CE Identifier |  LSI  |
  +---+---+---+---+---+---+---+---+---+---+


        Figure 5: The format of new ESI type
]]></artwork>
          </figure></t>

        <t>Where:</t>

        <t><list style="symbols">
            <t>T (1 octet): specify the ESI Type. The recommended value is
            0x06.</t>

            <t>CE Identifier (3 octets): the route ID/IPv4 address of CE.</t>

            <t>LSI (2 octets): the LSI information.</t>
          </list></t>

        <t>Since the length of LSI is 16 bits, while the length of Ethernet
        Tag ID and ESI are 80 bits and 32 bits, respectively. We can only use
        the lower 16 bits of Ethernet Tag ID / ESI field to carry LSI
        information, the other bits MUST set to 0.</t>

        <t/>
      </section>
    </section>

    <section title="Modification of MAC address storage mode on PE">
      <t>LSI-aware bundle service interface also changes the storage mode of
      MAC address on PE, as shown in Figure 6.</t>

      <figure align="center">
        <artwork><![CDATA[ +------------------------------+           
 |MAC-VRF                       |            
 |                              |           
 |  BD-A (LSI <-> VNI/SPI)      |           
 |     MAC 1                    |           
 |     ......                   |           
 |                              |           
 |  BD-B (LSI <-> VNISPI)       |           
 |     MAC 100                  |           
 |     ......                   |           
 +------------------------------+           
   LSI-Aware Bundle Service             
         Interface(L2)                  

     Figure 6: Modification of MAC/IP address storage mode on PE
]]></artwork>
      </figure>

      <t/>

      <t>For end-to-end layer-2 data transmission, the storage mode of MAC
      address in MAC-VRF is similar to VLAN-aware bundle service, the only
      change is that different bridge domains are distinguished by LSI.</t>
    </section>

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

    <section title="IANA Considerations">
      <t>This draft extends the VxLAN GPE header, S bit of Flag and LSI field
      are added:</t>

      <t><figure>
          <artwork align="center"><![CDATA[  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|S|Ver|I|P|B|O|               LSI             |Next Protocol  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                VXLAN Network Identifier (VNI) |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>

      <t>This draft also define a new ESI type:</t>

      <t><figure>
          <artwork align="center"><![CDATA[  +---+---+---+---+---+---+---+---+---+---+
  | T | Reserved  | CE Identifier |  LSI  |
  +---+---+---+---+---+---+---+---+---+---+
]]></artwork>
        </figure></t>
    </section>
  </middle>

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-bess-mvpn-evpn-aggregation-label'?>

      <?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?>
    </references>
  </back>
</rfc>
