Skip to main content

Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route
draft-wang-bess-evpn-ether-tag-id-usage-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Yubao Wang
Last updated 2021-08-06
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-bess-evpn-ether-tag-id-usage-00
BESS WG                                                          Y. Wang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                           6 August 2021
Expires: 7 February 2022

      Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route
               draft-wang-bess-evpn-ether-tag-id-usage-00

Abstract

   This draft discusses the issues with ESI Overlay Index.  Then it
   proposes an extension to [RFC7432] and
   [I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP
   aliasing for Layer 3 routes that is needed for L3-EVIs to build a
   complete IP ECMP.  It also extended two EVPN Service Interfaces for
   EVPN VPLS services.

Status of This Memo

   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 7 February 2022.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Wang                     Expires 7 February 2022                [Page 1]
Internet-Draft             ET-ID Usage Update                August 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Problem with EVPN Signalled L3VPNs  . . . . . . . . . . .   3
     2.2.  Problem with IP-aliasing of EVPN IRB  . . . . . . . . . .   5
     2.3.  Problem with Multipe VLAN-based Service Interface . . . .   6
     2.4.  Problem with N:1 VLAN-aware Service Interface . . . . . .   7
     2.5.  Problem with Bump-in-the-wire Use-Case  . . . . . . . . .   8
   3.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  ARP/ND Synching and IP Aliasing . . . . . . . . . . . . .  10
       3.1.1.  Constructing MAC/IP Advertisement Route . . . . . . .  10
       3.1.2.  Constructing IP-AD/EVI Route  . . . . . . . . . . . .  11
     3.2.  Constructing IP Prefix Advertisement Route  . . . . . . .  11
     3.3.  Forwarding Unicast Packets  . . . . . . . . . . . . . . .  12
     3.4.  Secenario-Specific Procedures . . . . . . . . . . . . . .  12
       3.4.1.  EVPN-IRB Specific Procedures  . . . . . . . . . . . .  12
       3.4.2.  On Fragmented VLAN-bundle Service Interface . . . . .  13
       3.4.3.  On N:1 VLAN-aware Service Interface . . . . . . . . .  13
       3.4.4.  Bump-in-the-wire Specific Procedures  . . . . . . . .  14
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   In [I-D.wang-bess-evpn-arp-nd-synch-without-irb], the ESI of IP-VRF
   ACs are advertised as Overlay index of IP forwarding.  But in IP-VRF
   context, the Ethernet A-D per EVI routes of the same ESI are more
   easier to conflict with each other, when they are imported into the
   same IP-VRF.  This document discribes three secenarios of such kind.
   Then it discribes the solutions of them.  These solutions all need an
   extension for the Ethernet Tag ID of the Ethernet A-D per EVI routes.
   But the Ethernet Tag ID of RT-2 routes don't need to be extended,
   Because they are extended by [I-D.ietf-bess-evpn-modes-interop]
   already.  Then this draft proposes two new Service Interfaces for
   EVPN VPLS services, they are Fragmented VLAN-bundl Service Interface
   and N:1 VLAN-aware Service Interface.  When different VLANs on the
   same ES of the same Broadcast Domain can fail independently, these
   service interfaces will be better than VLAN-bundle and VLAN-aware
   bundle service interface.

Wang                     Expires 7 February 2022                [Page 2]
Internet-Draft             ET-ID Usage Update                August 2021

1.1.  Terminology and Acronyms

   Most of the acronyms and terms used in this documents comes from
   [RFC7432], [I-D.wang-bess-evpn-arp-nd-synch-without-irb] and
   [I-D.sajassi-bess-evpn-ip-aliasing] except for the following:

   *  VRF AC: An Attachment Circuit (AC) that attaches a CE to an IP-VRF
      but is not an IRB interface.

   *  VRF Interface: An IRB interface or a VRF-AC or an IRC interface.
      Note that a VRF interface will be bound to the routing space of an
      IP-VRF.

   *  L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices
      participating in that EVPN which contains VRF ACs and maybe
      contains IRB interfaces or IRC interfaces.

   *  IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here
      is an IP-VRF.

   *  IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for
      one of its route targets is an IP-VRF.

   *  RMAC: Router's MAC, which is signaled in the Router's MAC extended
      community.

   *  ESI Overlay Index: ESI as overlay index.

   *  ET-ID: Ethernet Tag ID, it is also called ETI for short in this
      document.

   *  RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI.

   *  RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI
      as its overlay index.

2.  Problem Statement

2.1.  Problem with EVPN Signalled L3VPNs

Wang                     Expires 7 February 2022                [Page 3]
Internet-Draft             ET-ID Usage Update                August 2021

                                          PE1
        PNEC1                      +---------------+
        +--------------+           |  __(IF2.20)   |
        |              |       IF2 | /        \    |
        |      -------===============     (IP-VRF) +-------+
        |     /      / |   ESI23   | \__      /    |       |
        | .10/   .20/  |     +     |    (IF2.10)   |       |  PE3
        |   /      /   |     |     +---------------+   +---+----+
        | +---+ +---+  |     |                         |        |
   SN8+---+N1 | |N2 |  |     |                         |(IP-VRF)+-+H3
        | +---+ +---+  |     |            PE2          |        |
        |   \      \   |     |     +---------------+   +---+----+
        | .10\   .20\  |     +     |  __(IF3.10)   |       |
        |     \      \ |   ESI23   | /        \    |       |
        |      -------===============     (IP-VRF) +-------+
        |              |       IF3 | \__      /    |
        +--------------+           |    (IF3.20)   |
                                   +---------------+

                    Figure 1: RT-1 Confliction of L3EVIs

   There are three network-elements named N1/N2/N3 in the above network.
   N1/N2/N3 may be a host or an IP router.  When N1/N2/N3 is a host, it
   is also called H1/H2/H3 in this document.  When N1/N2/N3 is a router,
   it is also called R1/R2/R3 in this document.

   Consider a pair of multi-homed PEs PE1 and PE2.  Let there be two
   hosts N1 and N2 attached to them via a Physical Network-Element-
   Container PNEC1.  Consider another PE PE3 and a host N3 attached to
   it.  The N1 represent subnet SN1 and the N2 represents subnet SN2.

   Note that There are no MAC-VRF or IRB interface on PE1/PE2/PE3 in
   this case.  Thus the IP-VRFs are called as EVPN instance instead.
   Such EVPN instance can be called EVPN signalled L3VPN or L3EVI for
   short.  The anycast gateway IP address (10.0.0.1 of SN1) of N1 is
   configured on the sub-interfaces IF2.10 and IF3.10, where IF2.10 is a
   subinterface of IF2, IF3.10 is a subinterface of IF3.  The anycast
   gateway IP address (20.0.0.1 of SN1) of N2 is configured on the sub-
   interfaces IF2.20 and IF3.20, where IF2.20 is also a subinterface of
   IF2, IF3.20 is also a subinterface of IF3.  IF2.10, IF3.10, IF2.20
   and IF3.20 are all VRF Attachment Circuits of the same IP-VRF.

   Note that the PNEC1 multi-homing PE1 and PE2 via a LAG interface (by
   whom IF2 and IF3 is aggregated) which maybe load-balance traffic to
   these PEs.  That LAG interface is called as IF23 in this document.
   IF23 has two subinterfaces, they are IF23.10 and IF23.20.  IF23.10
   (10.0.0.2) is connected to N1, and IF23.20 (20.0.0.2) is connected to
   N2.

Wang                     Expires 7 February 2022                [Page 4]
Internet-Draft             ET-ID Usage Update                August 2021

   Note that IF23.10 (or IF23.20) is illustrated as two ".10"s (or
   ".20"s) in Figure 1, but these two ".10"s (or ".20"s) are of the same
   subinterface.

   IF2 and IF3 are configured with the same ESI ESI23, thus an Ethernet
   A-D per EVI route ETI_10_2 is advertsed for IF2.10, an Ethernet A-D
   per EVI route ETI_10_3 is advertsed for IF3.10, an Ethernet A-D per
   EVI route ETI_20_2 is advertsed for IF2.20, and an Ethernet A-D per
   EVI route ETI_20_3 is advertsed for IF3.20.

   When PE3 receives ETI_10_2 and ETI_20_2, it will pick up only one of
   them to be installed to the data plane.  Because that they have the
   same <RD,ESI,ET-ID> and nexthop.  We assume that the ETI_20_2 are
   picked out.  When PE3 receives ETI_10_3 and ETI_20_3, it will also
   pick up only one of them to be installed to the data plane.  Because
   that they also have the same <RD,ESI,ET-ID> and nexthop.  We assume
   that the ETI_20_3 are picked out.

   Although PE1 will advertise a RT-5 Route R5_SN8_1 (whose ESI is
   ESI23) to PE3, When H3 send data packet DP_3_8 to a host in SN8 after
   IF2.10 fails, PE3 may still send DP_3_8 to PE1 because that PE3 will
   load-balance traffics just fllowing ETI_20_2 and ETI_20_3.  That's a
   problem that will cause packet-drop or traffic-bypassing.

   The solution for this problem is decribed in Section 3.

2.2.  Problem with IP-aliasing of EVPN IRB

                                          PE1
         PNEC1                     +---------------+
        +--------------+           |  __(BD-20)    |
        |              |       IF2 | /      \IRB21 |
        |      -------===============   (IP-VRF)   +-------+
        |     /      / |   ESI23   | \__    /IRB11 |       |
        | .20/   .10/  |     +     |    (BD-10)    |       |  PE3
        |   /      /   |     |     +---------------+   +---+----+
        | +---+ +---+  |     |                         |        |
   H1+----+N1 | |N2 |  |     |                         |(IP-VRF)+-+H3
        | +---+ +---+  |     |            PE2          |        |
        |   \      \   |     |     +---------------+   +---+----+
        | .20\   .10\  |     +     |  __(BD-10)    |       |
        |     \      \ |   ESI23   | /      \IRB12 |       |
        |      -------===============   (IP-VRF)   +-------+
        |              |       IF3 | \__    /IRB22 |
        +--------------+           |    (BD-20)    |
                                   +---------------+

                   Figure 2: RT-1 Confliction of EVPN IRB

Wang                     Expires 7 February 2022                [Page 5]
Internet-Draft             ET-ID Usage Update                August 2021

   This network is similar to Figure 1 with a few notable exceptions as
   below.

   IF2.10, IF2.20, IF3.10 and IF3.20 are ACs of MAC-VRFs, not ACs of IP-
   VRFs.  IF2.10 and IF3.10 are ACs of MAC-VRF BD-10, IF2.20 and IF3.20
   are ACs of MAC-VRF BD-20.  As a result of that, the previous IP
   address of IF2.10, IF2.20, IF3.10 and IF3.20 are now configured to
   IRB11,IRB21, IRB12 and IRB22 correspondingly.

   Note that IRB11 and IRB12 are IRB interfaces of BD-10 where BD-10 is
   a Broadcast Domain of VLAN-based Service Interface.  IRB21 and IRB22
   are IRB interfaces of BD-20 where BD-20 is a Broadcast Domain of
   VLAN-based Service Interface.

   According to [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per EVI
   routes R1_210, R1_220, R1_310, R1_320 for IF2.10, IF2.20, IF3.10 and
   IF3.20 will all have zero Ethernet Tag IDs.

   When PE3 receives R1_210 and R1_220, it will pick up only one of them
   to be installed to the data plane.  We assume that the R1_220 is
   picked out.  When PE3 receives R1_310 and R1_320, it will pick up
   only one of them to be installed to the data plane.  We assume that
   the R1_320 is picked out.

   Although PE1 will advertise a RT-2 Route R2_N1 (whose ESI is ESI23)
   to PE3, When H3 send data packet DP_3_N1 to N1 after IF2.10 fails,
   PE3 may still send DP_3_N1 to PE1 because that PE3 will load-balance
   traffics just fllowing R1_220 and R1_320.  That's a problem that will
   cause packet-drop or traffic-bypassing.

   The solution for this problem is decribed in Section 3.4.1.

2.3.  Problem with Multipe VLAN-based Service Interface

Wang                     Expires 7 February 2022                [Page 6]
Internet-Draft             ET-ID Usage Update                August 2021

                                          PE1
          PNEC1                    +---------------+
        +--------------+           |  __(IF2.20)   |
        |              |       IF2 | /        \    |
        |      -------===============     (BD-100) +-------+
        |     /      / |   ESI23   | \__      /    |       |
        | .20/   .10/  |     +     |    (IF2.10)   |       |  PE3
        |   /      /   |     |     +---------------+   +---+----+
        | +---+ +---+  |     |                         |        |
        | |N1 | |N2 |  |     |                         |(BD-100)+-+H3
        | +---+ +---+  |     |            PE2          |        |
        |   \      \   |     |     +---------------+   +---+----+
        | .20\   .10\  |     +     |  __(IF3.10)   |       |
        |     \      \ |   ESI23   | /        \    |       |
        |      -------===============     (BD-100) +-------+
        |              |       IF3 | \__      /    |
        +--------------+           |    (IF3.20)   |
                                   +---------------+

            Figure 3: RT-1 Confliction of Multiple VLAN-based SI

   This network is similar to Figure 1 with a few notable exceptions as
   below.

   We want the IP addresses of IF23.10, IF23.20 and H3 are of the same
   subnet (say SN100).  As a result of that, IF2.10, IF2.20, IF3.10 and
   IF3.20 are ACs of the same Bridge-domain BD-100, not ACs of any IP-
   VRF.  Thus none of the four ACs will have an IP address.

   According to VLAN-based or VLAN-bundl Service Interface per
   [RFC7432], the Ethernet A-D per EVI routes for IF2.10 and IF2.20 will
   be the same (say R1_100_2), the Ethernet A-D per EVI routes for
   IF3.10 and IF3.20 will be the same (say R1_100_3).  Both R1_100_2 and
   R1_100_3 will have a zero Ethernet Tag ID.

   So when the CFM of subinterface IF2.10 fails, if R1_100_2 is
   withdrawn, the forwarding of N2's packets (data packets which are
   destined to N2) will be in the wrong, but if R1_100_2 is not
   withdrawn, the forwarding of N1's packets will be affected.  That's
   the problem.

   The solution for this problem is decribed in Section 3.4.2.

2.4.  Problem with N:1 VLAN-aware Service Interface

   This network is similar to Section 2.3 with a few notable exceptions
   as below.

Wang                     Expires 7 February 2022                [Page 7]
Internet-Draft             ET-ID Usage Update                August 2021

   The BD-100 is one of the Broadcast Domains of an EVI of VLAN-aware
   bundle service interface.  Although that EVI is of VLAN-aware bundle
   Service Interface and the VLANs of IF2.10 and IF2.20 are different,
   IF2.10 and IF2.20 can't be attached to different BDs of that EVI.
   Because that we still want the IP addresses of IF23.10, IF23.20 and
   H3 are of the same subnet (say SN100), like what we have expected in
   Section 2.3.

   So we assign the same normalized ET-ID (say ET-ID 100) to IF2.10,
   IF2.20, IF3.10 and IF3.20.  As a result of that, the Ethernet A-D per
   EVI routes for IF2.10 and IF2.20 will be the same (say R1_100_2b),
   the Ethernet A-D per EVI routes for IF3.10 and IF3.20 will be the
   same (say R1_100_3b).  Both R1_100_2b and R1_100_3b will have a ET-ID
   100.

   So when the CFM of subinterface IF2.10 fails, if R1_100_2b is
   withdrawn, the forwarding of N2's packets (those packets destinating
   to N2) will be in the wrong, but if R1_100_2b is not withdrawn, the
   forwarding of N1's packets will be affected.  That's the problem.

   Note that this problem will not be resolved even if R1_100_2b can
   carry two AC-ID Extended Communities (one per AC).

   The solution for this problem is decribed in Section 3.4.3.

2.5.  Problem with Bump-in-the-wire Use-Case

Wang                     Expires 7 February 2022                [Page 8]
Internet-Draft             ET-ID Usage Update                August 2021

             TS2                          PE1
       +--------------+           +---------------+
       |              |           |               |
   SN7-----(N2-M4)__  |           |  __(BD-20)    |
       |            \ |       IF2 | /             |
       |             ===============              +-------+
       |          __/ |   ESI23   | \__           |       |
    +----- (N1-M2)    |     +     |    (BD-10)    |       |  PE3
    |  |              |     |     |               |   +---+-----+
    |  +--------------+     |     +---------------+   | (BD-10) |
    |                       |                         |   \IRB1 |
   SN1                      |                         |(IP-VRF) +-+H3
    |        TS3            |             PE2         |   /IBR3 |
    |  +--------------+     |     +---------------+   | (BD-20) |
    |  |              |     |     |               |   +---+-----+
    +----- (N1-M3)__  |     +     |  __(BD-10)    |       |
       |            \ |   ESI23   | /             |       |
       |             ===============              +-------+
       |          __/ |       IF3 | \__           |
   SN7-----(N2-M5)    |           |    (BD-20)    |
       |              |           |               |
       +--------------+           +---------------+

               Figure 4: RT-1 Confliction of Bump-in-the-wire

   This network is similar to Figure 7 (section 4.3) of
   [I-D.ietf-bess-evpn-prefix-advertisement] with a few notable
   exceptions as below.

   The PE1 here is the NVE2 there, the PE2 here is the NVE3 there, the
   PE3 here is the DGW1 there.  The N1 here is the Virtual Appliance
   there.  The IRB1 here is the IRB1 there.  The ESI23 here is the ESI23
   there.  The SN1 here is the SN1 there.

   But here we have another Virtual Appliance N2, which are attached to
   another Broadcast Domain BD-20.  Both BD-10 and BD-20 are integrated
   into the same IP-VRF by PE3 (DGW1).  But the subnet SN1 can only be
   reached through BD-10, while the subnet SN7 can only be reached
   through BD-20.

Wang                     Expires 7 February 2022                [Page 9]
Internet-Draft             ET-ID Usage Update                August 2021

   As the result of that, the DGW1(PE3) will receive a RT-5 route R5_X
   (IPL=24, IP=SN1, ESI=ESI23, from NVE2/PE1) and two RT1 routes
   R1_BD10<RD=BD-10, ESI23, 0> and R1_BD20<RD=BD-20, ESI23, 0> from
   NVE2(PE1).  These two RT1 routes both can be imported into the same
   IP-VRF instance.  Which RT-1 route will R5_X's ESI overlay index be
   resolved to?  The R1_BD10 or the R1_BD20 ?  If R1_BD10 is picked out,
   then it can't reach SN1 (especially when R5_X is advertised for SN1).
   If R1_BD20 is picked out, then it can't reach SN7 (especially when
   R5_X is advertised for SN7).  That's the Problem.

   Note that both BD-10 and BD-20 are EVIs of VLAN-based Service
   Interfaces.

   Note that similar problem will occurs when Bump-in-the-wire Use-Case
   are integrated into the same IP-VRF with an EVPN IRB instance on the
   same ESI.

   The solution for this problem is decribed in Section 3.4.4.

3.  Solutions

   Note that the PEs follow
   [I-D.wang-bess-evpn-arp-nd-synch-without-irb] to achieve the ESI load
   balance except for the following explicit discription.

3.1.  ARP/ND Synching and IP Aliasing

3.1.1.  Constructing MAC/IP Advertisement Route

   This draft introduces a new usage/construction of MAC/IP
   Advertisement route to enable Aliasing for IP addresses in L3EVI use-
   cases.  The usage/construction of this route remains similar to that
   described in RFC 7432 with a few notable exceptions as below.

   *  The Route-Distinguisher should be set to the corresponding L3EVI
      context.

   *  The Ethernet Tag ID should be set to the VLANs of the VRF-AC from
      where that MAC/IP is learnt.

   *  The ESI SHOULD be set to the ESI of the VRF interface from which
      the ARP entry is learnt.

      Note that the <ESI,ET-ID> is used to install remote synched ARP
      entries to corresponding VRF interfaces on PE1/PE2.  But on PE3,
      the <ESI,ET-ID> is used to load balance traffics.

Wang                     Expires 7 February 2022               [Page 10]
Internet-Draft             ET-ID Usage Update                August 2021

   *  The MAC/IP Advertisement SHOULD carry one or more IP VRF Route-
      Target (RT) attributes.

   *  The MPLS Label1 should be set to the same pre-configured value for
      all local ARP entries.  It is just used to be compatible with
      existing RRs.

   *  The MPLS Label2 should be set to the local label of the IP-VRF in
      MPLS or VXLAN EVPN.  But it should be set to implicit-null in SRv6
      EVPN.

   *  The RMAC Extended Community attribute SHOULD be carried in VXLAN
      EVPN.

3.1.2.  Constructing IP-AD/EVI Route

   The usage/construction of this route is similar to the IP-AD per EVI
   route described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few
   notable exceptions as below.

   *  The Ethernet Tag ID (ET-ID) should be set to the VLANs of the VRF-
      AC for which it is advertised.

3.2.  Constructing IP Prefix Advertisement Route

   When an IP Prefix Advertisement is advertised, The Ethernet Tag ID is
   recommanded to be carried along with it, if it is not clear that
   whether there will be conflictions among IP A-D per EVI routes in the
   future.

   Note that the Ethernet Tag ID here is not used to isolate IP address
   spaces.  It is just used to resolve its ESI overlay index to a proper
   IP A-D per EVI route.

   The AC-ID extended community can't be considered as a substitute of
   the ET-ID.  Because that the AC-ID is not the key of IP A-D per EVI
   routes, but the ET-ID is.

   Arguably, non-reserved Ethernet Tag ID in the RT-5 route, could be
   assumed that it is already in
   [I-D.ietf-bess-evpn-prefix-advertisement], because that when the
   BD-10 of the Bump-in-the-wire use-case is of an EVI of VLAN-aware
   bundl service interface, non-reserved ethernet tag ID will be carried
   along with Ethernet A-D per EVI routes, hence non-reserved Ethernet
   Tag ID should be carried along with IP Prefix Advertisement Routes
   too.  Otherwise those Ethernet A-D per EVI routes can not be referred
   by these IP Prefix Advertisement Routes.

Wang                     Expires 7 February 2022               [Page 11]
Internet-Draft             ET-ID Usage Update                August 2021

3.3.  Forwarding Unicast Packets

   When PE3 forward a data packet DP_2021 according to an IP Prefix
   advertisement route R5_2021 whose overlay index is an ESI, If the ET-
   ID of R5_2021 is a non-reserved ET-ID, DP_2021 should not be
   forwarded according to an ethernet A-D per EVI route R1_2021, unless
   the ET-ID and ESI of R1_2021 are both the same as that of R5_2021.

   Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the IP-AD per EVI
   route carries a "Router's MAC" extended community in case the RMAC is
   not the same among different PEs.  In these cases, the inner
   destination MAC of the corresponding data packets from PE3 to PE1/PE2
   must use the RMAC in IP-AD/EVI route instead, even if there is a RMAC
   in RT-2E route.

   Note that this is a data-plane update of
   [I-D.ietf-bess-evpn-prefix-advertisement] for both EVPN signalled
   L3VPN and [I-D.sajassi-bess-evpn-ip-aliasing].  According to
   [I-D.ietf-bess-evpn-prefix-advertisement] section 4.3 or
   [I-D.ietf-bess-evpn-inter-subnet-forwarding] section 3.2.3, the inner
   destination MAC will follow the RMAC of RT-5E Route or RT-2E Route.

3.4.  Secenario-Specific Procedures

3.4.1.  EVPN-IRB Specific Procedures

   PE1 may advertise two IP A-D per EVI routes for subinterface IF2.10,
   one (say R1_210b) is for BD-10, the other (that R1_210) is for IP-
   VRF.  The Ethernet Tag ID of R1_210b is zero per [RFC7432], but the
   Ethernet Tag ID of R1_210 is set to the VLANs of IF2.10 according to
   this draft.

   When PE1 advertise a RT-5 Route for a prefix behind BD-10, the
   Ethernet Tag ID of that RT-5 Route is determined by the out-interface
   (IF2.10) of the MAC of that prefix's overlay nexthop (10.0.0.2).

   Note that R1_210b will not be imported into the IP-VRF.

   PE1 may advertise two RT-2 routes for N1's MAC/IP, one (say R2_N1b)
   is for BD-10, the other (that R2_N1) is for the IP-VRF.  The Ethernet
   Tag ID of R2_N1b is zero per [RFC7432], but the Ethernet Tag ID of
   R2_N1 is set to the VLANs of IF2.10 according to this draft.

   The MAC-VRFs and IP-VRFs in this solution will have their own copy of
   EVPN routes, This issue can be improved using the mechanisms of
   Section 3.4.2, if interoperation between VLAN-based service interface
   and VLAN-aware service interface per
   [I-D.ietf-bess-evpn-modes-interop] is provisioned in this network.

Wang                     Expires 7 February 2022               [Page 12]
Internet-Draft             ET-ID Usage Update                August 2021

3.4.2.  On Fragmented VLAN-bundle Service Interface

   PE1 will advertise different Ethernet A-D per EVI routes for IF2.10
   and IF2.20, the Ethernet Tag ID of them will be the VLANs of
   corresponding AC (IF2.10 or IF2.20).

   Note that the MAC/IPs on IF2.10 and IF2.20 will be advertised along
   with such ET-IDs too.

   When PE3 receives such Ethernet A-D per EVI routes and RT-2 routes,
   it SHOULD process them following [I-D.ietf-bess-evpn-modes-interop]'s
   section 3.1.2.  As a result of that, although PE3 works in VLAN-based
   or VLAN-baundle Service Interface, Such MAC/IPs will be istalled in
   BD-100 and they will be resolved to those Ethernet A-D per EVI routes
   under the help of such ET-IDs.

   Such Service Interface is called as Fragmented VLAN-bundl Service
   Interface or Multiple VLAN-based Service Interface.  Because that the
   VLAN-range are fragmented into multiple separate VLANs.

3.4.3.  On N:1 VLAN-aware Service Interface

   PE1 will advertise different Ethernet A-D per EVI routes for IF2.10
   and IF2.20, the Ethernet Tag ID of them will be the VLANs (10 or 20)
   of corresponding AC (IF2.10 or IF2.20), not the normalized ET-ID
   (100).

   Note that the MAC/IPs on IF2.10 and IF2.20 will not be advertised
   along with such ET-IDs too, They will be advertised along with the
   normalized ET-ID and the corresponding AC-ID extended community per
   [I-D.sajassi-bess-evpn-ac-aware-bundling].

   When PE3 receives these two Ethernet A-D per EVI routes, it installs
   them separately.  Whe PE3 receives the RT-2 route for N1's address,
   that route carries the AC-ID 10 of IF2.10, PE3 will resolve it to the
   Ethernet A-D per EVI routes (in all-active mode) whose ET-ID are 10
   (not the normalized ET-ID 100).  Whe PE3 receives the RT-2 route for
   N2's address, that route carries the AC-ID 20 of IF2.20, PE3 will
   resolve it to the Ethernet A-D per EVI routes (in all-active mode)
   whose ET-ID are 20 (not the normalized ET-ID 100).

   Note that [I-D.sajassi-bess-evpn-ac-aware-bundling] requires the
   Presence of Attachment Circuit ID Extended Community MUST be ignored
   by non multihoming PEs.  It requires the remote PE (non-multihome PE,
   e.g.  PE3) MUST process MAC route as defined in [RFC7432].  That is
   updated in this section, they are different use-cases.

Wang                     Expires 7 February 2022               [Page 13]
Internet-Draft             ET-ID Usage Update                August 2021

   Such Service Interface is called as N:1 VLAN-aware Service Interface.
   Because that N ACs of the same ES are normalized to the same ET-ID.

3.4.4.  Bump-in-the-wire Specific Procedures

   The advertisement of Ethernet A-D per EVI routes and RT-2 routes are
   similar to Section 3.4.2.

   The RT-5 routes (for the prefixes behind each BD) should be
   advertised along with the Ethernet Tag ID (the same as it is
   advertised in Ethernet A-D per EVI route) of the outgoing AC per each
   prefix's VA MAC.

4.  IANA Considerations

   no IANA Considerations.

5.  Security Considerations

   TBD.

6.  References

6.1.  Normative References

   [I-D.ietf-bess-evpn-modes-interop]
              Krattiger, L., Sajassi, A., Thoria, S., Rabadan, J., and
              J. Drake, "EVPN Interoperability Modes", Work in Progress,
              Internet-Draft, draft-ietf-bess-evpn-modes-interop-00, 31
              May 2021, <https://datatracker.ietf.org/doc/html/draft-
              ietf-bess-evpn-modes-interop-00>.

   [I-D.ietf-bess-srv6-services]
              Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R.,
              Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based
              Overlay Services", Work in Progress, Internet-Draft,
              draft-ietf-bess-srv6-services-07, 11 April 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              srv6-services-07>.

   [I-D.sajassi-bess-evpn-ip-aliasing]
              Sajassi, A., Badoni, G., Warade, P., Pasupula, S., Drake,
              J., and J. Rabadan, "EVPN Support for L3 Fast Convergence
              and Aliasing/Backup Path", Work in Progress, Internet-
              Draft, draft-sajassi-bess-evpn-ip-aliasing-02, 8 June
              2021, <https://datatracker.ietf.org/doc/html/draft-
              sajassi-bess-evpn-ip-aliasing-02>.

Wang                     Expires 7 February 2022               [Page 14]
Internet-Draft             ET-ID Usage Update                August 2021

   [I-D.sajassi-bess-evpn-ac-aware-bundling]
              Sajassi, A., Brissette, P., Mishra, M. P., Thoria, S.,
              Rabadan, J., and J. Drake, "AC-Aware Bundling Service
              Interface in EVPN", Work in Progress, Internet-Draft,
              draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July
              2021, <https://datatracker.ietf.org/doc/html/draft-
              sajassi-bess-evpn-ac-aware-bundling-04>.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-prefix-
              advertisement-11, 18 May 2018,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-prefix-advertisement-11>.

   [I-D.ietf-bess-evpn-inter-subnet-forwarding]
              Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
              Rabadan, "Integrated Routing and Bridging in EVPN", Work
              in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-
              subnet-forwarding-15, 26 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-inter-subnet-forwarding-15>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

6.2.  Informative References

   [I-D.wang-bess-evpn-arp-nd-synch-without-irb]
              Wang, Y. and Z. Zhang, "ARP/ND Synching And IP Aliasing
              without IRB", Work in Progress, Internet-Draft, draft-
              wang-bess-evpn-arp-nd-synch-without-irb-06, 4 July 2020,
              <https://datatracker.ietf.org/doc/html/draft-wang-bess-
              evpn-arp-nd-synch-without-irb-06>.

Wang                     Expires 7 February 2022               [Page 15]
Internet-Draft             ET-ID Usage Update                August 2021

   [I-D.wz-bess-evpn-vpws-as-vrf-ac]
              Wang, Y. and Z. Zhang, "EVPN VPWS as VRF Attachment
              Circuit", Work in Progress, Internet-Draft, draft-wz-bess-
              evpn-vpws-as-vrf-ac-01, 28 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-wz-bess-evpn-
              vpws-as-vrf-ac-01>.

Author's Address

   Yubao Wang
   ZTE Corporation
   No.68 of Zijinghua Road, Yuhuatai Distinct
   Nanjing
   China

   Email: wang.yubao2@zte.com.cn

Wang                     Expires 7 February 2022               [Page 16]