BESS WG                                                          Y. Wang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                        20 November 2021
Expires: 24 May 2022


             Smooth Evolution of Existing EVPN IRB Network
              draft-wang-bess-evpn-irb-smooth-evolution-00

Abstract

   EVPN IRB has been deployed following [RFC9135]'s early draft for a
   long time.  This draft discusses how can these existing deployments
   smoothly evolved into an IP-aliasing
   ([I-D.sajassi-bess-evpn-ip-aliasing]) enhanced EVPN symmetric IRB
   scenario, especially when two of an IP-VRF's BDs (whose IRB
   interfaces are attached to the same IP-VRF) have been attched to a
   common ES before that network evolution.  In such case, when these
   two BDs are evolved into IP-aliasing enhanced EVPN symmetric IRB as
   per [I-D.sajassi-bess-evpn-ip-aliasing] or distributed Bump-in-the-
   wire as per [I-D.wang-bess-evpn-distributed-bump-in-the-wire], the IP
   A-D per EVI routes of these two BDs may conflict with each other in
   the context of the IP-VRF instance.

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 24 May 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Wang                       Expires 24 May 2022                  [Page 1]


Internet-Draft             EVPN IRB Evolution              November 2021


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Muti-IRB Use Case vs Mono-IRB Use Case  . . . . . . . . .   5
     2.2.  Problem with IP-aliasing-enabled Multi-IRB Use Case . . .   6
       2.2.1.  When IP-aliasing is enabled for a multi-IRB Use
               Case  . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.2.  When an IP-aliasing-enabled mono-IRB evolves into
               multi-IRB . . . . . . . . . . . . . . . . . . . . . .   7
       2.2.3.  When distributed Bump-in-the-wire is enabled for a
               multi-IRB use case  . . . . . . . . . . . . . . . . .   7
   3.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Determining the Aliasing Pathes for RT-2R . . . . . . . .   8
     3.2.  ACI-specific Overlay Index Extended Community . . . . . .   9
     3.3.  ARP/ND Synching and IP Aliasing . . . . . . . . . . . . .   9
       3.3.1.  Constructing MAC/IP Advertisement Route . . . . . . .   9
       3.3.2.  Constructing IP A-D per EVI Route . . . . . . . . . .  10
     3.4.  Secenario-Specific Procedures . . . . . . . . . . . . . .  10
       3.4.1.  EVPN-IRB Specific Procedures  . . . . . . . . . . . .  10
       3.4.2.  Bump-in-the-wire Specific Procedures  . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   In Section 3.1 of [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per
   EVI routes are defined in order to provide the IP aliasing
   capabilities for EVPN symmetric IRB.  In Section 2.1 we discussed the
   multi-IRB use case and why the original IP A-D per EVI routes can not
   be used when we want the overlay network of that use case to be
   smoothly evoluted to an IP-aliasing-enhanced EVPN symmetric IRB
   network.  Then we discussed how the smooth evolution can be provided
   using the SOI-specific ethernet auto-discovery mode of



Wang                       Expires 24 May 2022                  [Page 2]


Internet-Draft             EVPN IRB Evolution              November 2021


   [I-D.wang-bess-evpn-distributed-bump-in-the-wire].

   This draft improves the network evolution of a style of overlay
   network with EVPN IRB deployments, where two BDs behind different IRB
   interfaces of the same IP-VRF have been attched to a common ES before
   that network evolution.  This style of EVPN IRB use case are called
   as multi-IRB use case in this draft.  That overlay network is a
   existing symmetric EVPN IRB service.  Before the evolution, it will
   be a normal symmetric EVPN IRB per [RFC9135], But after the
   evolution, it should be assigned with the IP aliasing capabilities as
   per [I-D.sajassi-bess-evpn-ip-aliasing].  But the IP A-D per EVI
   route of [I-D.sajassi-bess-evpn-ip-aliasing] can't satisfy the
   network management requirements of smooth resolution.  This draft
   discribes a smooth evolution mechanism using the SOI-specific
   ethernet auto-discovery mode of
   [I-D.wang-bess-evpn-distributed-bump-in-the-wire].

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.

   * Ethernet A-D per EVI -  An Ethernet Auto-Discovery route per
         EVI whose EVI is an MAC-VRF as per [RFC7432] and [RFC9135].
         The route-targets of an Ethernet A-D per EVI route are
         determined by the MAC-VRF for which they are advertised.

   * IP A-D per EVI -  An ethernet Auto-Discovery route per EVI
         whose EVI is an IP-VRF.  Note that the Ethernet Tag ID of an IP
         A-D per EVI route MUST be zero as per
         [I-D.sajassi-bess-evpn-ip-aliasing].

   * IP A-D per 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



Wang                       Expires 24 May 2022                  [Page 3]


Internet-Draft             EVPN IRB Evolution              November 2021


         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-2R -  When a MAC/IP Advertisement Route whose ESI is not
         zero is used for IP-VRF forwarding, it is called as a RT-2R in
         this draft.  When it is used for MAC-VRF forwarding, it is not
         called as a RT-2R in this draft.

   * ETI-Agnostic BD -  A Broadcast Domain (BD) whose data packets
         can be received along with any Ethernet Tag ID (ETI).  Note
         that a broadcast domain of an L2 EVI of VLAN-aware bundle
         service interface is a good example of an ETI-Specific BD.

   * ETI-Specific BD -  A Broadcast Domain (BD) whose data packets
         are expected to be received along with a normalized Ethernet
         Tag ID (ETI).  Note that a broadcast domain of an L2 EVI of
         VLAN-bundle or VLAN-based service interface is a good example
         of an ETI-Agnostic BD.

   * BDI-Specific EADR -  When the <ESI, BD> uses BDI-Specific
         Ethernet Auto-discovery mode, the only Ethernet A-D per EVI
         route of that <ESI, BD> is called as a BDI-Specific EADR in
         this draft.  When the AC-type is N:1 mapping, and only a single
         Ethernet A-D per EVI route is advertised for that <ESI, BD>, we
         say that the <ESI, BD> uses BDI-Specific Ethernet Auto-
         discovery mode, and that Ethernet A-D per EVI route is called
         as a BDI-Specific EADR (Ethernet A-D per EVI Route) in this
         draft.

   * SOI-Specific EADR -  When the <ESI, BD> uses SOI-specific
         ethernet auto-discovery mode, the Ethernet A-D per EVI routes
         of that <ESI, BD> are called as SOI-Specific EADRs in this
         draft.  When the AC-type is N:1 mapping, and individual
         Ethernet A-D per EVI routes are advertised per each VLAN of
         that <ESI, BD>, we say that the <ESI, BD> uses SOI-Specific
         Ethernet Auto-discovery mode, and each of such Ethernet A-D per
         EVI route is called as a SOI-Specific EADR (Ethernet A-D per
         EVI Route) in this draft.

2.  Problem Statement







Wang                       Expires 24 May 2022                  [Page 4]


Internet-Draft             EVPN IRB Evolution              November 2021


2.1.  Muti-IRB Use Case vs Mono-IRB Use Case

   The detailed explanation of this network's physical links are
   described in Appendix A of [I-D.wang-bess-evpn-ether-tag-id-usage].
   But the network's EVCs (Ethernet Virtual Connections, which are
   typically established per <Port, VLAN> basis) is illustrated in the
   following sections per each Service Interface.

   The BD-10 here is the VPNx of Appendix A of
   [I-D.wang-bess-evpn-ether-tag-id-usage], and the BD-20 is the VPNy of
   Appendix A of [I-D.wang-bess-evpn-ether-tag-id-usage].

    PNEC1                         PE1
  +------------+           +----------------+ EAD_PE1_20
  |            |           |  __(BD-20)     | ------------>
  | H4      "  |        P1 | /      \ IRB21 |
  | |       #================   (IP-VRF)    +-----------------+
  | N1______"  |   ESI21   | \__    / IRB11 |                 |
  |    10.2 "  |     +     |    (BD-10)     |                 |  PE3
  |         "  |     |     +----------------+             +---+----+
  |         "  |     |                                    |        |
  |         "  |     |                                    |(IP-VRF)+-+H3
  |         "  |     |            PE2                     |        |
  | N2______"  |     |     +----------------+ EAD_PE2_10  +---+----+
  |    20.2 "  |     +     |  __(BD-10)     | ------------>   |
  |         "  |   ESI21   | /      \ IRB12 |                 |
  |         #================   (IP-VRF)    +-----------------+
  |         "  |        P2 | \__    / IRB22 |
  |            |           |    (BD-20)     |
  +------------+           +----------------+

               Figure 1: Ethernet A-D per EVI of Multi-IRB

   BD-10 and BD-20 are both BDs (broadcast domains) whose IRB interfaces
   are attached to the same IP-VRF.  The anycast IP address of IRB11 and
   IRB12 is 10.9, and the anycast IP address of IRB21 and IRB22 is 20.9.
   BD-10 and BD-20 are integrated into the same IP-VRF by IRB11, IRB12,
   IRB21 and IRB22.  As a result of that, N1, IRB11 and IRB12 are of
   subnet SN1, and N2, IRB21 and IRB22 are of subnet SN2.

   Multi-IRB Use Case -  Above network are called as a multi-IRB use
         case for <ESI21,that IP-VRF> in this draft.  Because two IRB
         interfaces of ES21's BDs (which are both attached to ESI21)
         have been attched to a common IP-VRF.

   Mono-IRB Use Case -  Now imagine that the BD-20 of above network





Wang                       Expires 24 May 2022                  [Page 5]


Internet-Draft             EVPN IRB Evolution              November 2021


         has not been deployed, so there is only one of ESI21's BDs in
         the IP-VRF's context.  In such case, we can say that this is a
         mono-IRB use case for <ESI21,that IP-VRF>.

         Note that when an IP-aliasing-enabled mono-IRB use case for
         <ESI21,that IP-VRF> is evolved into a multi-IRB use case for
         <ESI21,that IP-VRF>, there may be some issues to be deal with.
         that's why

   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 also a Broadcast Domain of
   VLAN-based Service Interface.

2.2.  Problem with IP-aliasing-enabled Multi-IRB Use Case

2.2.1.  When IP-aliasing is enabled for a multi-IRB Use Case

    PNEC1                         PE1
  +------------+           +----------------+ IPAD_PE1_20
  |            |           |  __(BD-20)     | ------------>
  | H4      "  |        P1 | /      \ IRB21 |
  | |       #================   (IP-VRF)    +-----------------+
  | N1______"  |   ESI21   | \__    / IRB11 |                 |
  |    10.2 "  |     +     |    (BD-10)     |                 |  PE3
  |         "  |     |     +----------------+             +---+----+
  |         "  |     |                                    |        |
  |         "  |     |                                    |(IP-VRF)+-+H3
  |         "  |     |            PE2                     |        |
  | N2______"  |     |     +----------------+ IPAD_PE2_10 +---+----+
  |    20.2 "  |     +     |  __(BD-10)     | ------------>   |
  |         "  |   ESI21   | /      \ IRB12 |                 |
  |         #================   (IP-VRF)    +-----------------+
  |         "  |        P2 | \__    / IRB22 |
  |            |           |    (BD-20)     |
  +------------+           +----------------+

             Figure 2: IP-aliasing Enabled Multi-IRB Use Case

   As an existing network, the attachment circuits are not configured
   with any virtual ESes.  Now this network want to be enhanced with IP-
   aliasing features of [I-D.sajassi-bess-evpn-ip-aliasing].

   According to [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per EVI
   routes R1_110, R1_120, R1_210, R1_220 for P1.1, P1.2, P2.1 and P2.2
   will all have zero Ethernet Tag IDs.





Wang                       Expires 24 May 2022                  [Page 6]


Internet-Draft             EVPN IRB Evolution              November 2021


   When PE3 receives R1_110 and R1_120, it will pick up only one of them
   to be installed to the data plane.  We assume that the R1_120 is
   picked out.  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.

   Although PE1 will advertise a RT-2 Route R2_N1 (whose ESI is ESI21,
   IP is 10.2) to PE3, When H3 send data packet DP_H3_N1 to N1 after
   P1.1 fails, PE3 may still send DP_H3_N1 to PE1 because that PE3 will
   load-balance traffics just fllowing R1_120 and R1_220.  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.2.2.  When an IP-aliasing-enabled mono-IRB evolves into multi-IRB

   Before IP-aliasing is enabled, it is safe for a mono-IRB use case to
   evolve into a multi-IRB use case.  But after IP-aliasing is enabled,
   it may be dangerous for a mono-IRB use case to evolve into a multi-
   IRB use case, if not all L2 ACs are configured as separated virtual
   ESIs before that evolution.  Because the RT-1 per EVI confliction
   which is described in the above section.

   When it is still a mono-IRB use case, there is no motivation for it
   to be deployed with all its L2 ACs being previously configured as
   separated vESIs.  Because that virtual ESIs are not so efficient in
   the following aspects:

   *  Increased RT-4 routes.

   *  Mass-withdraw capability is disabled.

   *  Service Carving is complicated

   *  ES management and configuration are complicated.

   Because of these reasons, per-AC virtual ESIs is not widely used in
   normal mono-IRB use case or normal multi-IRB use case as per
   Section 5 of [RFC9135].

2.2.3.  When distributed Bump-in-the-wire is enabled for a multi-IRB use
        case

   When distributed Bump-in-the-wire is enabled for a multi-IRB use
   case, the similar problem will occur with that multi-IRB use case.
   This is discussed in Section 2.2 of
   [I-D.wang-bess-evpn-distributed-bump-in-the-wire].




Wang                       Expires 24 May 2022                  [Page 7]


Internet-Draft             EVPN IRB Evolution              November 2021


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.  Determining the Aliasing Pathes for RT-2R

   When PE3 forward a data packet DP_2021 according to an RT-2R route
   RT2R_2021 whose SOI extended community is not absent, If the SOI of
   RT2R_2021 is a non-reserved ET-ID, DP_2021 should not be forwarded
   according to an ethernet A-D per EVI route IPAD_2021, unless the ET-
   ID of IPAD_2021 are the same as the SOI of RT2R_2021, and the ESI of
   IPAD_2021 are the same as the ESI of RT2R_2021.

   Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the IP A-D 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 A-D per EVI route instead, even if there is a
   RMAC in RT-2R route.

   When selecting corresponding IP A-D per EVI routes for a RT-2R route,
   the SOI Extended Community (if it exists) of the RT-2R route MUST be
   used.

   * Using SOI to select SOI-Specific EADRs -  In this case, the IP A-D
     per EVI routes corresponding to that RT-2R route should be selected
     in the context of the IP-VRF.

     There may be multiple Ethernet A-D per EVI routes which all can
     match the RT-2R's ESI.  In such case, The Ethernet A-D per EVI
     routes whose ET-ID are the same as the RT-2R's SOI should be
     selected.

     Note that when the RT-2R's SOI is Y, the ET-IDs of the selected
     Ethernet A-D per EVI routes (of that RT-2R) should be all Y.

     Note that when the RT-2R's ET-ID is not 0, and an SOI is advertised
     along with the RT-2R, the IP A-D per EVI routes of that RT-2R
     should be selected according to the <ESI,SOI>, not according to the
     <ESI, ET-ID=0>.

   Note that In EVPN IRB use case, the non-zero ET-ID of a RT-2R (when
   it is used in IP-VRF context) is not used to select the corresponding
   IP A-D per EVI routes (whose ET-ID will always be zero according to
   Section 2.1 of [I-D.sajassi-bess-evpn-ip-aliasing]) of that RT-2R
   route.



Wang                       Expires 24 May 2022                  [Page 8]


Internet-Draft             EVPN IRB Evolution              November 2021


3.2.  ACI-specific Overlay Index Extended Community

   A new EVPN BGP Extended Community called Supplementary Overlay Index
   is introduced [I-D.wang-bess-evpn-distributed-bump-in-the-wire].
   This new extended community is used together with ACI-specific
   ethernet auto-discovery specified in
   [I-D.wang-bess-evpn-distributed-bump-in-the-wire].

   In this draft it is used to make a deployed multi-IRB to be smoothly
   evoluted to ip-aliasing features.

3.3.  ARP/ND Synching and IP Aliasing

3.3.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 symmetric
   EVPN IRB use-cases.  The usage/construction of this route remains
   similar to that described in [I-D.sajassi-bess-evpn-ip-aliasing] with
   a few notable exceptions as below.

   *  The Ethernet Tag ID should be set to 0 according to
      [I-D.sajassi-bess-evpn-ip-aliasing].

   *  The value of SOI Extended Communinty should be set to the SOI of
      the L2 AC over which the ARP entry of the RT-2R is learnt.

      Note that when the SOI Extended Communinty is carried along with a
      RT-2R route, the <ESI, SOI> will be used to select IP A-D per EVI
      routes by PE3, and the selected IP A-D per EVI routes are used to
      determine the aliasing pathes of this RT-2 route.  But if the SOI
      Extended Communinty is absent, the aliasing pathes of this RT-2R
      route will be determined by <ESI, ET-ID=0> as per
      [I-D.sajassi-bess-evpn-ip-aliasing].

   *  In EVPN IRB, The ESI SHOULD be set to the ESI of the L2 AC from
      which the ARP entry is snooped as per
      [I-D.sajassi-bess-evpn-ip-aliasing].

      Note that on PE3, the <ESI,SOI> is only used to load balance
      traffics.

   *  The RMAC Extended Community attribute SHOULD be carried in VXLAN
      EVPN.  This follows [RFC9135].







Wang                       Expires 24 May 2022                  [Page 9]


Internet-Draft             EVPN IRB Evolution              November 2021


3.3.2.  Constructing IP A-D per EVI Route

   The usage/construction of this route is similar to the IP A-D 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 SOI of the L2 AC
      for which it is advertised.

   Note that the normal Ethernet A-D per EVI routes for BDs are not
   influenced.  And the SOI Extended Community will be advertised along
   with the RT-2R routes which are learnt over that L2 AC.

3.4.  Secenario-Specific Procedures

3.4.1.  EVPN-IRB Specific Procedures

   PE1 may advertise two Ethernet A-D per EVI routes for subinterface
   P1.1, one (say R1_110b) is for BD-10 (which is of VLAN-based service
   interface), the other (that R1_110) is for IP-VRF.  The Ethernet Tag
   ID of R1_110b is zero per [RFC7432], but the Ethernet Tag ID of
   R1_110 is set to the VLANs of P1.1 according to this draft.

   When PE1 advertise a RT-2R Route for a host (10.0.0.2) behind BD-10,
   the Ethernet Tag ID of that RT-2R Route is determined by the out-
   interface (P1.1) of the MAC of that host's ARP entry.  If the MAC is
   learnt from an ETI-specific BD, the ET-ID of the RT-2R route should
   be set to the BD-ID is that ETI-Specific BD.  But the ET-ID of the
   RT-2R route is not used to select the corresponding IP A-D per EVI
   routes.

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

3.4.2.  Bump-in-the-wire Specific Procedures

   It is discussed in Section 3.2 of
   [I-D.wang-bess-evpn-distributed-bump-in-the-wire].

4.  IANA Considerations

   TBD.

5.  Security Considerations

   TBD.

6.  References




Wang                       Expires 24 May 2022                 [Page 10]


Internet-Draft             EVPN IRB Evolution              November 2021


6.1.  Normative References

   [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-03, 25 October
              2021, <https://datatracker.ietf.org/doc/html/draft-
              sajassi-bess-evpn-ip-aliasing-03>.

   [I-D.wang-bess-evpn-distributed-bump-in-the-wire]
              Wang, Y. and Q. Niu, "Distributed Bump-in-the-wire Use
              Case", Work in Progress, Internet-Draft, draft-wang-bess-
              evpn-distributed-bump-in-the-wire-01, 24 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-wang-bess-
              evpn-distributed-bump-in-the-wire-01>.

   [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>.

   [RFC9135]  Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
              Rabadan, "Integrated Routing and Bridging in Ethernet VPN
              (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
              <https://www.rfc-editor.org/info/rfc9135>.

   [RFC9136]  Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
              A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
              (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
              <https://www.rfc-editor.org/info/rfc9136>.

6.2.  Informative References

   [I-D.ietf-bess-evpn-modes-interop]
              Krattiger, L., Sajassi, A., Thoria, S., Rabadan, J., and
              J. E. 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>.




Wang                       Expires 24 May 2022                 [Page 11]


Internet-Draft             EVPN IRB Evolution              November 2021


   [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-08, 10 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              srv6-services-08>.

   [I-D.sajassi-bess-evpn-ac-aware-bundling]
              Sajassi, A., Brissette, P., Mishra, M., 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.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-08, 1 September
              2021, <https://datatracker.ietf.org/doc/html/draft-wang-
              bess-evpn-arp-nd-synch-without-irb-08>.

   [I-D.wang-bess-evpn-ether-tag-id-usage]
              Wang, Y., "Ethernet Tag ID Usage Update for Ethernet A-D
              per EVI Route", Work in Progress, Internet-Draft, draft-
              wang-bess-evpn-ether-tag-id-usage-03, 26 August 2021,
              <https://datatracker.ietf.org/doc/html/draft-wang-bess-
              evpn-ether-tag-id-usage-03>.

   [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-02, 28 August 2021,
              <https://datatracker.ietf.org/doc/html/draft-wz-bess-evpn-
              vpws-as-vrf-ac-02>.

Author's Address

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

   Email: wang.yubao2@zte.com.cn





Wang                       Expires 24 May 2022                 [Page 12]