Internet DRAFT - draft-sajassi-bess-evpn-ip-aliasing

draft-sajassi-bess-evpn-ip-aliasing







Network Working Group                                    A. Sajassi, Ed.
Internet-Draft                                                 G. Badoni
Intended status: Standards Track                               P. Warade
Expires: September 10, 2020                                  S. Pasupula
                                                                   Cisco
                                                                J. Drake
                                                                 Juniper
                                                              J. Rabadan
                                                                   Nokia
                                                           March 9, 2020


            L3 Aliasing and Mass Withdrawal Support for EVPN
                 draft-sajassi-bess-evpn-ip-aliasing-01

Abstract

   This document proposes an extension to do Aliasing and Backup paths
   for EVPN layer-3 routes in an IP-VRF.  The solution leverages the use
   of EVPN Ethernet Segments for an efficient layer-3 load-balancing and
   fast convergence in case of failures.

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 September 10, 2020.

Copyright Notice

   Copyright (c) 2020 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



Sajassi, et al.        Expires September 10, 2020               [Page 1]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Ethernet Segments for Host Routes in Symmetric IRB  . . .   3
     1.2.  Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF
           use-cases . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Terminology and Conventions . . . . . . . . . . . . . . .   6
   2.  IP Aliasing and Backup Path . . . . . . . . . . . . . . . . .   7
     2.1.  Constructing Ethernet A-D per EVPN Instance Route . . . .   8
   3.  Fast Convergence for Routed Traffic . . . . . . . . . . . . .   9
     3.1.  Constructing Ethernet A-D per Ethernet Segment Route  . .  10
       3.1.1.  Ethernet A-D Route Targets  . . . . . . . . . . . . .  10
     3.2.  Avoiding convergence issues by synchronizing IP prefixes   10
     3.3.  Handling Silent Host MAC/IP route IP Aliasing . . . . . .  11
     3.4.  MAC Aging . . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Determining Reachability to Unicast IP Addresses  . . . . . .  12
     4.1.  Local Learning  . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Remote Learning . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Constructing MAC/IP Address Advertisement . . . . . . . .  12
       4.3.1.  Route Resolution  . . . . . . . . . . . . . . . . . .  12
   5.  Forwarding Unicast Packets  . . . . . . . . . . . . . . . . .  13
   6.  Load Balancing of Unicast Packets . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  13
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document proposes an extension to do Aliasing and Backup paths
   for EVPN layer-3 routes in an IP-VRF.  The solution leverages the use
   of EVPN Ethernet Segments for an efficient layer-3 load-balancing and
   fast convergence in case of failures in two use-cases:

   a.  Inter-subnet-forwarding for host routes in symmetric IRB

   b.  IP-VRF to IP-VRF host or prefix based forwarding







Sajassi, et al.        Expires September 10, 2020               [Page 2]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


1.1.  Ethernet Segments for Host Routes in Symmetric IRB

   Consider a pair of multi-homing PEs, PE1 and PE2, as illustrated in
   Figure 1.  Let there be a host H1 attached to them.  Consider PE3 and
   a host H3 attached to it.

                                  +----------------+
                                  |     EVPN       |
                               +------+            |
                               | PE1  | +--->      |
                        +------+      | RT2        |
                        |      |      | IP1     +--+---+
                 +---+  | ES1  +------+ ESI1    | PE3  |
            H1+--+CE1+--+         |             |      +-+H3
                 +---+  |      +------+         |      |
                        |      | PE2  |         +--+---+
                        +------+      |            |
                               |      |            |
                               +------+            |
                                  |                |
                                  +----------------+



   Figure 1: Inter-subnet traffic between Multihoming PEs and Remote PE

   With Asymmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if
   H3 sends inter-subnet traffic to H1, routing will happen at PE3.  PE3
   will be attached to the destination IRB interface and will trigger
   ARP/ND requests if it does not have an ARP/ND adjacency to H1.  A
   subsequent routing lookup will resolve the destination MAC to H1's
   MAC address.  Furthermore, H1's MAC will point to an ECMP EVPN
   destination on PE1 and PE2, either due to host route advertisement
   from both PE1 and PE2, or due to Ethernet Segment MAC Aliasing as
   detailed in [RFC7432].

   With Symmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if
   H3 sends inter-subnet traffic to H1, a routing lookup will happen at
   PE3's IP-VRF and this routing lookup will not yield the destination
   IRB interface and therefore MAC Aliasing is not possible.  In order
   to have per-flow load balancing for H3's routed traffic to H1, an IP
   ECMP list (to PE1/PE2) needs to be associated to H1's host route in
   the IP-VRF route-table.  If H1 is locally learned only at one of the
   multi-homing PEs, PE1 or PE2, due to LAG hashing, PE3 will not be
   able to build an IP ECMP list for the H1 host route.

   With the extension described in this document, PE3's IP-VRF becomes
   Ethernet-Segment-aware and builds an IP ECMP list for H1 based on the



Sajassi, et al.        Expires September 10, 2020               [Page 3]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   advertisement of ES1 along with H1 in a MAC/IP route and the
   availability of ES1 on PE1 and PE2.  In order to know that PE1 and
   PE2 are attached to ES1, PE3 needs to import AD per ES and AD per EVI
   routes that PE1/PE2 advertise for ES1.  This extension is referred to
   as "IP Aliasing".

   If ES1 is configured as "single-active" as opposed to "all-active" in
   the previous paragraph, this document describes how PE3 can build a
   primary and backup IP path for H1.

   In both cases, IP Aliasing and IP backup paths, fast convergence and
   mass withdraw capabilities are supported in case of failures on the
   multi-homing PEs.

1.2.  Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases

   This document also allows the use of Ethernet Segments in EVPN IP
   Prefix routes (or routes type 5)
   [I-D.ietf-bess-evpn-prefix-advertisement] for the purpose of IP
   Aliasing or IP backup paths.

   As an example, consider the scenario in Figure 2 in which PE1 and PE2
   are multi-homed to CE1.  However, and contrary to CE1 in Figure 1, in
   this case CE1 uses layer-3 links to get connected to PE1 and PE2 in
   different BDs, and a BGP session established between CE1's loopback
   address and PE1's IRB address.

   In these use-cases, typically CE1 supports a single BGP session to
   one of the PEs (through which it advertises a number of IP Prefixes
   seating behind itself) and yet, it is desired that remote PEs (e.g.,
   PE3) can build an IP ECMP list or backup IP list including additional
   PEs (e.g., PE2 in Figure 2).



















Sajassi, et al.        Expires September 10, 2020               [Page 4]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


                                      +-----------------------+
                                      |        EVPN           |
                        PE1           |                       |
                       +-------------------+                  |
                       |       IRB1        |                  |
                       |  +---+   +------+ | ------->         |
              +-----------|BD1|---|IPVRF1| | RT5              |
      eBGP    |        |  +---+   |      | | 50.0/24          |   PE3
   +------------------------>10.1 +------+ | ESI1    +--------------+
   |          |        +-------------------+         |+------+      |
  +-----+10.2 |                       |   ^          ||IPVRF1| +---+|
  | CE1 |-----+    ES1                |   |          ||      |-|BD3|--H4
  |     |-----+                       |   +----------|+------+ +---+|
  +-----+20.2 |         PE2           |        +-----|              |
  lo1         |        +--------------+----+   |     +--------------+
  1.1.1.1     |        |       IRB2        |   |              |
  Prefixes:   |        |  +---+   +------+ |   |              |
  50.0/24     +-----------|BD2|---|IPVRF1| |<--+              |
  60.0/24              |  +---+   |      | |                  |
                       |     20.1 +------+ |                  |
                       +-------------------+                  |
                                      |                       |
                                      +-----------------------+

              Figure 2: Layer-3 Multihoming PEs and Remote PE

   In order to achieve IP Aliasing or IP Backup path from PE3, PE1 and
   PE2 interfaces are associated to the same virtual Ethernet Segment
   (ES1) even though they are attached to different BDs.  All the IP
   Prefixes learned from CE1 are installed in PE1's IP-VRF and
   subsequently advertised from PE1 as EVPN IP Prefix routes encoding
   ESI-1 in the Ethernet Segment field.

   Upon configuration of ES1, both PE1 and PE2 advertise an AD per ES
   route for ESI1, indicating if the ES works in single-active or all-
   active mode, as per [RFC7432].  These AD per ES routes are sent along
   with the set of route-targets of the IP-VRFs attached to the Ethernet
   Segment.

   In addition, both PEs advertise an AD per EVI route with the route-
   target of IP-VRF1, indicating the availability of the IP-VRF to
   forward routed IP traffic to CE1.  PE3 will install the IP Prefix
   routes associated to ESI1, where ESI1 is resolved to an IP ECMP list
   (or IP primary and backup paths) formed upon the reception of the AD
   routes for ESI1.  As in the previous example, fast convergence and
   mass withdrawal capabilities are supported based on the advertisement
   and withdrawal of the AD per EVI/ES routes.




Sajassi, et al.        Expires September 10, 2020               [Page 5]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


1.3.  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   -  IRB: Integrated Routing and Bridging

   -  IRB Interface: A virtual interface that connects the bridging
      module and the routing module on an NVE.

   -  BD: or Broadcast Domain.  An EVI may be comprised of one BD (VLAN-
      based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle
      services).

   -  Bridge Table: An instantiation of a broadcast domain on a MAC-VRF.

   -  CE: Customer Edge device, e.g., a host, router, or switch.

   -  EVI: An EVPN instance spanning the Provider Edge (PE) devices
      participating in that EVPN.

   -  MAC-VRF: A Virtual Routing and Forwarding table for Media Access
      Control (MAC) addresses on a PE.

   -  Ethernet Segment (ES): When a customer site (device or network) is
      connected to one or more PEs via a set of Ethernet links, then
      that set of links is referred to as an 'Ethernet segment'.

   -  Ethernet Segment Identifier (ESI): A unique non-zero identifier
      that identifies an Ethernet segment is called an 'Ethernet Segment
      Identifier'.

   -  LACP: Link Aggregation Control Protocol.

   -  PE: Provider Edge device.

   -  Single-Active Redundancy Mode: When only a single PE, among all
      the PEs attached to an Ethernet segment, is allowed to forward
      traffic to/from that Ethernet segment for a given VLAN, then the
      Ethernet segment is defined to be operating in Single-Active
      redundancy mode.

   -  All-Active Redundancy Mode: When all PEs attached to an Ethernet
      segment are allowed to forward known unicast traffic to/from that




Sajassi, et al.        Expires September 10, 2020               [Page 6]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


      Ethernet segment for a given VLAN, then the Ethernet segment is
      defined to be operating in All-Active redundancy mode.

   -  AD per EVI: refers to the Auto-Discovery per EVPN instance routes
      (type 1).  Specified in [RFC7432], they allow for the auto-
      discovery of all the EVIs attached to a given ES on a given PE.

   -  AD per ES: refers to the Auto-Discovery per ES routes (type 1).
      Specified in [RFC7432], they allow for the auto-discovery of all
      the Ethernet Segments attached to a given PE, as well as their
      characteristics.

   -  VNF: Virtual Network Function.

2.  IP Aliasing and Backup Path

   MAC/IP routes are learned by PEs on the access side via a control
   plane protocol like ARP/ND, whereas IP Prefix routes are learned by
   the PEs via a routing protocol, typically BGP (ipv4/ipv6 families).

   Without IP Aliasing, in case where a CE is multihomed to multiple PE
   nodes using a LAG and is running in All-Active Redundancy Mode, the
   Host IP will be learned and advertised in the MAC/IP Advertisement
   only by the PE that receives the ARP packet.  As a result, the remote
   PE sees only one next-hop for the Host IP and forwards traffic to
   that advertising PE.  Hence, the remote PE is not be able to
   effectively load balance the traffic towards the multihomed Ethernet
   Segment.

   In a similar way, where the CE is multihomed to multiple nodes using
   a group of active layer-3 interfaces but it uses fewer routing
   protocol adjacencies than multihoming PEs, the CE IP Prefix routes
   will be learned and advertised by only the PE(s) that has(have) a
   routing protocol adjacency with the CE.  For example, if we consider
   the scenario in Figure 2 PE3 sees only one next-hop for CE1 Prefix
   routes and PE3 is not able to local balance the traffic to CE1.

   To address this issue, the concept of Aliasing that was introduced
   [RFC7432] can be extended for Layer 3 routes as well.  The PE SHOULD
   advertise reachability to an IP-VRF instance on a given ES for IP
   routes using the existing AD per ES/EVI routes.  In this case, the
   EVPN instance is the IP-VRF table to which the host IP address or IP
   Prefix belongs.  This will henceforth be referred to as the IP AD per
   ES/EVI route.

   A remote PE that receives an IP route with a non reserved ESI SHOULD
   consider it reachable by all PEs that have advertised the IP AD per
   ES/EVI advertisement route for the IP-VRF.  An IP AD per ES/EVI route



Sajassi, et al.        Expires September 10, 2020               [Page 7]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   is considered to be "for the IP-VRF" if it contains the IP-VRF route-
   target(s).

   The IP AD per ES route must have the Single-Active bit in the flags
   of the ESI Label extended community set to 0 for Aliasing to take
   effect.  Otherwise the receiving PE will process the routes for
   Primary and Backup IP paths.

   The IP AD per ES route cannot be used for route forwarding until the
   associated IP AD per ES route is received.

   In case of Single-Active redundancy mode, the remote PE SHOULD use
   the IP AD per EVI route EVPN Layer 2 attribute extended community as
   mentioned in [RFC8214] in combination with the IP AD per ES route to
   determine the Backup Path for the IP addresses for the given IP VRF
   context.  This alternate path SHOULD be installed as a backup path
   for the IP address.

2.1.  Constructing Ethernet A-D per EVPN Instance Route

   This document proposes the advertisement of IP AD per EVI routes for
   IP-VRFs to enable Aliasing or Backup paths for IP addresses.  The
   usage/construction of this route remains similar to that described in
   [RFC7432] with a few notable exceptions as below.

   -  The Route-Distinguisher should be set to the corresponding IP-VRF
      context.

   -  The Ethernet Tag should be set to 0.

   -  The IP AD per EVI/ES routes SHOULD carry one or more IP VRF Route-
      Targets (RT) attributes.

   -  The IP AD per EVI route MUST carry the Router's MAC Extended
      Community attribute [I-D.ietf-bess-evpn-prefix-advertisement] if
      the encapsulation among the PE IP-VRFs correspond to that of an
      Ethernet NVO tunnel.

   -  The MPLS Label usage SHOULD be used as described in [RFC7432] and
      [RFC8365].

   -  In case of IP Aliasing, all the PEs that are attached to the same
      ES will advertise P=1 in the Layer 2 attribute extended community
      [RFC8214].

   -  When IP Primary/Backup paths are desired, the Primary PE will
      advertise P=1 in the Layer 2 extended community, whereas the best
      Backup PE will advertise P=0, B=1.



Sajassi, et al.        Expires September 10, 2020               [Page 8]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


      o  The Primary PE SHOULD be the PE that learns the IP prefix at
         the access side.

      o  The Primary PE MAY be determined by policy or MAY be elected by
         a DF Election as in [RFC8584]

   It is important to note that the prefix for an IP AD per EVI and a
   layer 2 AD per-EVI may be identical.  However, since the Route-
   Distinguisher (RD) of the IP AD per EVI is set to the corresponding
   IP-VRF context and the RD of the layer-2 AD per EVI is set to the
   corresponding MAC-VRF context, the import will happen in the
   respective IP-VRFs and MAC-VRFs and hence, the prefix will not be
   overwritten.

3.  Fast Convergence for Routed Traffic

   Host or Prefix reachability is learned via the BGP-EVPN control plane
   over the MPLS/NVO network.  All the host or prefix routes that are
   connected behind an ES are advertised by the PEs belonging to the
   redundancy group.  A remote PE receiving these routes can loose
   reachability from any of the PEs either due node reload or core
   failure or access failure for that PE.

   To alleviate this, EVPN defines a mechanism to efficiently and
   quickly signal to remote PE nodes, the need to update their
   forwarding tables upon the occurrence of a failure in connectivity to
   an Ethernet segment.  This is done by having each PE advertise a set
   of one or more IP AD per ES routes for each locally attached Ethernet
   segment (refer to Section 3.1 below for details on how these routes
   are constructed).  A PE may need to advertise more than one IP AD per
   ES route for a given ES because the ES may be in a multiplicity of
   IP-VRFs and the Route-Targets for all of these IP-VRFs may not fit
   into a single route.  Advertising a set of IP AD per ES routes for
   the ES allows each route to contain a subset of the complete set of
   Route Targets.  Each IP AD per ES route is differentiated from the
   other routes in the set by a different Route Distinguisher (RD).

   Upon failure in connectivity to the attached ES, the PE withdraws the
   corresponding set of IP AD per ES routes.  This triggers all PEs that
   receive the withdrawal to update their next-hop adjacencies for all
   IP addresses associated with the Ethernet Segment in question, across
   IP-VRFs.  If no other PE has advertised an IP AD per ES route for the
   same Ethernet Segment, then the PE that received the withdrawal
   simply invalidates the IP entries for that segment.  Otherwise, the
   PE updates its next-hop adjacencies accordingly.






Sajassi, et al.        Expires September 10, 2020               [Page 9]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   These routes should be processed with higher priority than other EVPN
   MAC/IP or IP Prefix route withdrawals upon failure.  Similar priority
   processing is needed even on the intermediate Route Reflectors.

   This document is therefore addressing the mass withdrawal behavior
   for routed traffic.  For Layer 2 traffic, refer to Section 8.2 of
   [RFC7432].

3.1.  Constructing Ethernet A-D per Ethernet Segment Route

   This section describes the procedures used to construct the Ethernet
   A-D per ES route, which is used for fast convergence (as discussed in
   Section 3).  The usage/construction of this route remains similar to
   that described in section 8.2.1. of [RFC7432] with a few notable
   exceptions as explained in following sections.

3.1.1.  Ethernet A-D Route Targets

   Each IP Ethernet A-D per ES route MUST carry one or more Route
   Targets (RTs).  The set of IP AD routes per ES MUST carry the entire
   set of IP-VRF RTs for all the IP-VRFs attached to the ES, in addition
   to MAC VRF RTs for all the EVPN instances to which the Ethernet
   Segment belongs.

3.2.  Avoiding convergence issues by synchronizing IP prefixes

   Consider a pair of multi-homing PEs, PE1 and PE2.  Let there be a
   host H1 attached to them.  Consider PE3 and a host H3 attached to it.

   If the host H1 is learned on both the PEs, the ECMP path list is
   formed on PE3 pointing to (PE1/PE2).  Traffic from H3 to H1 is not
   impacted even if one of the PEs becomes unreachable as the path list
   gets corrected upon receiving the mass withdrawal route (IP AD per ES
   route).

   In a case where H1 is locally learned only on PE1 due to LAG hashing
   or a single routing protocol adjacency to PE1, at PE3, H1 has ECMP
   path list (PE1/PE2) using Aliasing as described in this document.
   Traffic from H3 can reach H1 via either PE1 or PE2.

   On PE2, all the remote MAC/IP or IP Prefix routes belonging to the
   same Ethernet Segment that are advertised by the ES peer (e.g., PE1)
   should be synchronized and installed locally on PE2 but not
   advertised as local routes by BGP-EVPN.  When the traffic from H3
   reaches PE2, PE2 will be able forward the traffic to H1 without any
   convergence delay (caused by triggering ARP/ND to H1 or to the next-
   hop to reach H1).  The synchronization of the ES MAC/IP or IP Prefix




Sajassi, et al.        Expires September 10, 2020              [Page 10]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   routes across all PEs of the same Ethernet Segment is important to
   solve convergence issues.

3.3.  Handling Silent Host MAC/IP route IP Aliasing

   Considering the example of Figure 1 for IP Aliasing, if the
   reachability of PE1 is lost, PE3 will update the ECMP list for H1 to
   PE2, upon receiving mass withdrawal from PE1.  If host H1 is also
   withdrawn from PE1, then the same route is withdrawn from PE2 and
   PE3.  Hence traffic from H3 to H1 is blackholed till H1 is re-learned
   on PE2.

   This blackholing can be much worse if the H1 behaves like a silent
   host.  IP address of H1 will not be re-learned on PE2 till H1 ARP/ND
   messages or some traffic triggers ARP/ND for H1.

   PE2 can detect the failure of PE1's reachability in different ways:

   a.  When core failure or node reboot happens on PE1, the next hop
       tracking to PE1 in the underlay routing protocols can help detect
       the failure..

   b.  Upon access failure, PE1 withdraws the IP AD per ES/EVI routes
       and PE2 can use this as a trigger to detect failure.

   Thus to avoid blackholing, when PE2 detects loss of reachability to
   PE1, it should trigger ARP/ND requests for all remote IP prefixes
   received from PE1 across all affected IP-VRFs.  This will force host
   H1 to reply to the solicited ARP/ND messages from PE2 and refresh
   both MAC and IP for the corresponding host in its tables.

   Even in core failure scenario on PE1, PE1 must withdraw all its local
   layer-2 connectivity, as Layer-2 traffic should not be received by
   PE1.  So when ARP/ND is triggered from PE2 the replies from host H1
   can only be received by PE2.  Thus H1 will be learned as local route
   and also advertised from PE2.

   It is recommended to have a staggered or delayed deletion of the IP
   routes from PE1, so that ARP/ND refresh can happen on PE2 before the
   deletion.

3.4.  MAC Aging

   In the same example as in section 3.3, PE1 would do ARP/ND refresh
   for H1 before it ages out.  During this process, H1 on can age out
   genuinely or due to the ARP/ND reply landing on PE2.  PE1 must
   withdraw the local entry from BGP when H1 entry ages out.  PE1




Sajassi, et al.        Expires September 10, 2020              [Page 11]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   deletes the entry from the local forwarding only when there are no
   remote synced entries.

4.  Determining Reachability to Unicast IP Addresses

4.1.  Local Learning

   The procedures for local learning do not change from [RFC7432] or
   [I-D.ietf-bess-evpn-prefix-advertisement].

4.2.  Remote Learning

   The procedures for remote learning do not change from [RFC7432] or
   [I-D.ietf-bess-evpn-prefix-advertisement].

4.3.  Constructing MAC/IP Address Advertisement

   The procedures for constructing MAC/IP Address or IP Prefix
   Advertisements do not change from [RFC7432] or
   [I-D.ietf-bess-evpn-prefix-advertisement].

4.3.1.  Route Resolution

   If the ESI field is set to reserved values of 0 or MAX-ESI, the IP
   route resolution MUST be based on the MAC/IP or IP Prefix route
   alone.

   If the ESI field is set to a non-reserved ESI, the IP route
   resolution MUST happen only when both the MAC/IP or IP Prefix route
   and the associated set of IP AD per ES routes have been received.  To
   illustrate this with an example, consider a pair of multi-homed PEs,
   PE1 and PE2, connected to an all-active Ethernet Segment.  A given
   host with IP address H1 is learned by PE1 but not by PE2.  When the
   MAC/IP or IP Prefix advertisement route from PE1 and a set of IP AD
   per ES and IP AD per EVI routes from PE1 and PE2 are received, then
   (1) PE3 can forward traffic destined to H1 to both PE1 and PE2.

   If after (1) PE1 withdraws the IP AD per ES route, then PE3 will
   forward the traffic to PE2 only.

   If after (1) PE2 withdraws the IP AD per ES route, then PE3 will
   forward the traffic to PE1 only.

   If after (1) PE1 withdraws the MAC/IP or IP Prefix route, then PE3
   will do delayed deletion of H1, as described in section 3.3.

   If after (1) PE2 advertised the MAC/IP or IP Prefix route, but PE1
   withdraws it, PE3 will continue forwarding to both PE1 and PE2 as



Sajassi, et al.        Expires September 10, 2020              [Page 12]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   long as it has the IP AD per ES and the IP AD per EVI route from
   both.

5.  Forwarding Unicast Packets

   Refer to Section 5 in [I-D.ietf-bess-evpn-inter-subnet-forwarding]
   and [I-D.ietf-bess-evpn-prefix-advertisement].

6.  Load Balancing of Unicast Packets

   The procedures for load balancing of Unicast Packets do not change
   from [RFC7432]

7.  Security Considerations

   The mechanisms in this document use EVPN control plane as defined in
   [RFC7432].  Security considerations described in [RFC7432] are
   equally applicable.  This document uses MPLS and IP-based tunnel
   technologies to support data plane transport.  Security
   considerations described in [RFC7432] and in [RFC8365] are equally
   applicable.

8.  IANA Considerations

9.  Contributors

10.  Acknowledgments

11.  References

11.1.  Normative References

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

   [RFC8214]  Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
              Rabadan, "Virtual Private Wire Service Support in Ethernet
              VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
              <https://www.rfc-editor.org/info/rfc8214>.

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




Sajassi, et al.        Expires September 10, 2020              [Page 13]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

11.2.  Informative References

   [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", draft-
              ietf-bess-evpn-inter-subnet-forwarding-08 (work in
              progress), March 2019.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
              bess-evpn-prefix-advertisement-11 (work in progress), May
              2018.

Authors' Addresses

   Ali Sajassi (editor)
   Cisco
   MILPITAS, CALIFORNIA 95035
   UNITED STATES

   Email: sajassi@cisco.com


   G. Badoni
   Cisco
   MILPITAS, CALIFORNIA 95035
   UNITED STATES

   Email: gbadoni@cisco.com






Sajassi, et al.        Expires September 10, 2020              [Page 14]

Internet-Draft        IP Aliasing Support for EVPN            March 2020


   P. Warade
   Cisco
   MILPITAS, CALIFORNIA 95035
   UNITED STATES

   Email: pwarade@cisco.com


   S. Pasupula
   Cisco
   MILPITAS, CALIFORNIA 95035
   UNITED STATES

   Email: surpasup@cisco.com


   John E Drake
   Juniper

   Email: jdrake@juniper.net


   Jorge Rabadan
   Nokia

   Email: jorge.rabadan@nokia.com

























Sajassi, et al.        Expires September 10, 2020              [Page 15]