<?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-09"
     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="7" month="July" year="2025"/>

    <area>RTG Area</area>

    <workgroup>BESS Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This draft describes layer-3 accessible EVPN service interfaces,
      which aim is to connect the layer 2 customers to one EVPN backbone, via
      the layer 3 network, and keep the traffic isolation among different
      layer 2 customers. It proposes to extend the VxLAN packet format to
      transfer the customer's Virtual Network Identifier(VNI) information, and
      also the related control plane extension.</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.</t>

      <t>But, 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. Figure 2 shows the typical topology within the
      operator's network.</t>

      <t><figure>
          <artwork align="center"><![CDATA[                             C-A    C-B
                              |      |
                            +---+  +---+   
                            |CE1|  |CE2|
                            +-+-+  +-+-+
                              |      |
                           +--+------+---+
                           |     MAN     |
                           +------+------+
                                  |
                               +--+-+
               +-----+   +-----+ PE1|------+     +-----+
               |     |   |     +----+      |     |     |
        +---+  |     | +-+-+             +-+-+   |     |  +---+
  C-A---|CE3+--+ MAN +-+PE2|  Backbone   |PE3+---+ MAN +--+CE5|--C-A
        +---+  |     | +-+-+             +-+-+   |     |  +---+
        +---+  |     |   |                 |     |     |  +---+
  C-B---|CE4+--+     |   |                 |     |     +--|CE6|--C-B
        +---+  |     |   |                 |     |     |  +---+
               +-----+   +-----------------+     +-----+

             Figure 2: LSI-aware bundle service interface scenario
]]></artwork>
        </figure>Assuming that the customer is a cross-regional enterprise,
      CEs represents the devices that connect its branches into the nearby
      Metro Area Network(MAN), which is one layer 3 network, and is connected
      each other via the service provider's backbone network.</t>

      <t>The customer wants to connect its branch sites together via the
      service provider's backbone network. The service provider deploy one
      EVPN instance for this customer within its backbone network, but can't
      connect each of these branches via the traditional layer 2 access EVPN
      interfaces <xref target="RFC7432"/>, because the MAN is one layer 3
      network, and there is no user's VLAN information that can be used to
      isolate the traffic of its different divisions.</t>

      <t>This scenario may involve the following situations:<list
          style="symbols">
          <t>point-to-point communication (e.g. the communication between C-A
          connected to CE3 and C-A connected to CE5.)</t>

          <t>point-to-multipoint communication (e.g. C-A connected to CE-3
          needs to communicate with both C-A connected to CE5 and C-A
          connected to CE-1 simultaneously.)</t>

          <t>multipoint-to-multipoint communication (e.g. mutual communication
          among the three C-As in Figure 2.)</t>
        </list></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>
    </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>Layer-3 accessible interface for EVPN: The interface, which is
          tunnelled over one layer 3 network, can be used to access the EVPN
          service, and keep the traffic within the EVPN forwarding plane
          isolated among different customer domains.</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
      customer's packets from different tunnels, which is VNI when the tunnel
      is VxLAN. The length of LSI is 16 bits.</t>

      <t>The concepts of 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 LSI-Aware Bundle service interface, the PE should maintain one
      MAC-VRF that be sub-divided into different logical plane. Similar with
      the VLAN-Aware Bundle service, it needs the forwarding plane of the
      customer's packet to carry the customer's LSI information, and also the
      control plane extension to transfer the required the LSI information of
      the communication peer.</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 header<xref target="RFC7348"/> to carry the
          LSI information, the extentions to the VxLAN 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|R|R|I|R|R|R|   Reserved    |              LSI              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          VXLAN Network Identifier (VNI)       |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4: The extentions to VxLAN header
]]></artwork>
            </figure>We define one flag &ldquo;S&rdquo; from the reserved bits
          of the current VxLAN header, to indicate the last 16 bits of first
          4-bytes indicates the value of &ldquo;LSI&rdquo;</t>

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

      <section title="Control Plane">
        <t>Using the newly defined ESI type shown in Figure 5. This method can
        preserve the original purpose of ESI definition (multi-homing).</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>
      </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)          |           
 |     MAC 1                    |           
 |     ......                   |           
 |                              |           
 |  BD-B (LSI <-> VNI)          |           
 |     MAC 100                  |           
 |     ......                   |           
 +------------------------------+           
   LSI-Aware Bundle Service             
         Interface                  

     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="Gap analysis">
      <t>This section specifies the differences among L3 accessible EVPN with
      EVPN<xref target="RFC7432"> (</xref>), EVPN-VPWS (<xref
      target="RFC8214"/>) and EVPN-Etree.</t>

      <section title="Differences with EVPN">
        <t><xref target="RFC7432"/> defines three types of Layer-2 access EVPN
        interfaces (VLAN-Based, VLAN-Bundle, VLAN-Aware Bundle), which are
        applicable to the scenarios where customers directly access the
        provider's PE through Layer-2 links (such as an enterprise network
        connecting to the PE via a dedicated line).</t>

        <t>The L3 accessible EVPN is designed for the scenarios where CE-PE
        needs to cross a Layer-3 network (such as a customer branch accessing
        the backbone network PE through an IP Metropolitan Area Network /
        MAN), it proposes three types of Layer-3 accessible interfaces
        (LSI-Based, LSI-Bundle, LSI-Aware Bundle). These interfaces support
        accessing EVPN through Layer-3 tunnels (such as VxLAN) and solve the
        problem of traffic isolation across Layer-3 networks.</t>
      </section>

      <section title="Differences with EVPN-VPWS">
        <t><xref target="RFC8214"/> defines the EVPN Virtual Private Wide Area
        Network Service (VPWS), which provides point-to-point (P2P) Layer-2
        dedicated line connections. The core is to advertise Ethernet A-D
        routes through BGP to establish dedicated line forwarding tunnels,
        without dealing with the traffic isolation problem of multiple
        customers on the same PE.</t>

        <t>L3 accessible EVPN focuses on the traffic isolation when multiple
        customers access the same PE through a Layer 3 network. It achieves
        logical isolation of Layer-2 traffic of different customers through
        LSI/MAC-VRF mapping (similar to the multi-tenant scenario). In
        contrast, VPWS focuses more on the establishment of dedicated line
        connections and does not handle multi-tenant isolation.</t>
      </section>

      <section title="Differences with EVPN-ETree">
        <t><xref target="RFC8317"/> defines the EVPN-ETree service, which
        supports point-to-multipoint tree-shaped multicast topologies (such as
        video conferencing, content distribution). It optimizes multicast
        traffic forwarding through E-Tree routes to reduce duplicate traffic,
        with the core being multicast efficiency optimization.</t>

        <t>L3 accessible EVPN aims at the isolation of traffic from multiple
        customers in unicast scenarios (such as different branches of an
        enterprise accessing the same EVPN instance through a Layer-3
        network). It divides logical planes through the mapping of LSI and
        MAC-VRF to ensure that the traffic of different customers does not
        communicate with each other, which has nothing to do with
        multicast.</t>

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

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

    <section title="IANA Considerations">
      <t>This document creates a 1-bit registry called "S bit". New
      registrations will be made through the "RFC Required" procedure defined
      in <xref target="RFC8126"/>. Initial registrations are as follows: The
      second bit on the left side of the VXLAN header is defined as the "S
      bit," and the reserved field occupying bits 17 to 32 is defined as "LSI"
      field. When S bit is set to 1, the "LSI" field carries the value of LSI;
      otherwise, the value of "LSI" field should not be see as the value of
      LSI.</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|R|R|I|R|R|R|   Reserved    |              LSI              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          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>

    <section title="Acknowledgements">
      <t>Thanks Jeffrey Zhang for its review and discussion to improve this
      document.</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.RFC.8126"
?>

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

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

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

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

      <?rfc ?>
    </references>
  </back>
</rfc>
