EVPN Support for L3 Fast Convergence and Aliasing/Backup Path

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 6 March 2023.¶

Copyright Notice

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

This document proposes an EVPN extension to allow several of its multihoming functions, fast convergence and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. It re-uses the existing EVPN routes, the Ethernet A-D per ES and the Ethernet A-D per EVI routes, which are used for these multihoming functions. In particular, there are three use-cases that could benefit from the use of these multihoming functions:¶

1. Inter-subnet forwarding for host routes in symmetric IRB [RFC9135].¶
2. Inter-subnet forwarding for prefix routes in the interface-less IP-VRF-to-IP-VRF model [RFC9136].¶
3. Inter-subnet forwarding for prefix routes when the ESI is used exclusively as an L3 construct [RFC9136].¶

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

                               +----------------+
                               |     EVPN       |
                            +------+            |
                            | PE1  | +--->      |
                     +------+      | RT-5       |
                     |      |      | IP1/32  +--+---+
              +---+  | ES1  +------+ ESI1    | PE3  |
         H1+--+CE1+--+         |             |      +-+H3
              +---+  |      +------+         |      |
                     |      | PE2  |         +--+---+
                     +------+      |            |
                            |      |            |
                            +------+            |
                               |                |
                               +----------------+

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

  Note:
    IP addresses expanded by adding 0s
    E.g., 50.0 expands to 50.0.0.0

                 +-------------------------------+
                 | PE1       EVPN                |
            +----------+                         |
            |  +------+|                         |
            |  |IP-VRF||                         |
     10.1 --------------------+                  |
   +---+    |+--+     ||      |eBGP              |
   |CE1|----||BD|-----+|      |PE-CE             |
   |   |-+  |+--+      |      |50.0/24           | PE3
   +---+ |  +----------+      |NH 10.1      +----------+
Prefixes:|       |            |             |+------+  |
50.0/24  |       |            |             ||IP-VRF|  |
60.0/24  |       | PE2        |   +--------->|    +--+ |
         |  +----------+      |   |         |+----|BD| |
         |  |  +------+|      |   |         |     +--+ |
         |  |  |IP-VRF||      |   |         +----------+
         |  |  |      ||      |   |              |  |
         |  |+--+     ||      |   |RT-5          |  |
         +--||BD|-----+|      |   |50.0/24       | H4
            |+--+      |      |   |ESI1          |
            +----------+      |   |NH PEC        |
                 |            |   |              |
                 |        30.1|   | PEC          |
                 |         +--V---|-+            |
                 |         |+------+|            |
                 +---------||IP-VRF||------------+
                           |+------+|
                           +--------+
  Note:
    IP addresses expanded by adding 0s
    E.g., 50.0 expands to 50.0.0.0

2. Ethernet Segments for L3 Aliasing/Backup Path and Fast Convergence

The first two use cases described in Section 1 do not require any extensions to the Ethernet Segment definition and both cases support Ethernet Segments as a set of Ethernet links and specified in [RFC7432], or virtual Ethernet Segments as a set of logical links specified in [I-D.ietf-bess-evpn-virtual-eth-segment].¶

The third use case in Section 1 requires an extension to the way Ethernet Segments are defined and associated. In this case, the Ethernet Segment is a Layer-3 construct characterized as follows:¶

1. The ES is defined as a set of Layer-3 links to the multi-homed CE and its state MUST be linked to the layer-3 reachability from each multi-homed PE to the CE's loopback address via a non-EVPN route in the PE's IP-VRF.¶
2. The ESI SHOULD be of type 4 [RFC7432] and set to the router ID of the multi-homed CE.¶
3. All-active or single-active multi-homing redundancy modes are supported, however, the redundancy mode only affects the procedures in Section 3.¶
4. PEs attached to the same Layer-3 ES discover each other through the exchange of RT-4 routes (Ethernet Segment routes). DF Election procedures [RFC8584] MAY be used for single-active multi-homing mode.¶
5. The routes advertised from the multi-homed CE's and installed in the PE's IP-VRF table with the CE's loopback as the next-hop MUST be re-advertised by the PE in EVPN IP Prefix routes with the ESI of the CE. The rest of the EVPN IP Prefix routes fields are set as per the Interface-less model in [RFC9136]. Note that the BGP PE-CE routes advertised by the multi-homed CE are installed in the IP-VRF normally irrespective of the Next Hop being resolved to an EVPN or a non-EVPN route, and they are exported as a RT-5 with the ESI.¶

In the example depicted in Figure 3, ES1 is defined as the set of layer-3 links that connects PE1 and PE2 to CE1. Its ESI, e.g., ESI-1, is derived as a type 4 ESI using the CE's router ID. ES-1 will be operationally active in the PE as long as CE1's loopback route is installed in the PE's IP-VRF and learned via any routing protocol except for an EVPN route. E.g., an active static route to 1.1.1.1 via next-hop 10.0.0.2 would make the ES operationally active in PE1, and the eBGP routes received from CE1 with next-hop 1.1.1.1 will be re-advertised as RT-5 routes with ESI-1.¶

In the example illustrated in Figure 4, ES1 is a set of layer-3 links connecting PE1, PE2 and PEC to CE1. ESI-1 is derived as a type 4 ESI using the CE's router ID, as in the previous example. CE1's loopback route (which is associated to ES1) is installed in PE1 and PE2 via non-EVPN route, hence ES1 is operationally active in PE1 and PE2. On PE-C though, CE1's loopback is installed via EVPN IP Prefix route, therefore, as per point 1 in the current section, ES1 is operationally inactive in PEC. As per point 5, this does not prevent PEC from exporting CE1's prefixes into RT-5 routes with ESI-1. However, since ES-1 is operationally inactive in PEC, no IP A-D per EVI routes (Section 3) and no IP A-D per ES routes Section 4 for ESI-1 will be advertised from PEC, preventing PEC from attracting traffic destined to CE1.¶

3. IP Aliasing and Backup Path

In order to address the use-cases described in Section 1, above, this document proposes that:¶

1. A PE that is attached to a given ES will advertise a set of one or more Ethernet A-D per ES routes for that ES. Each is termed an 'IP A-D per ES' route and is tagged with the route targets (RTs) for one or more of the IP-VRFs defined on it for that ES; the complete set of IP A-D per ES routes contains the RTs for all of the IP-VRFs defined on it for that ES.¶

   A remote PE imports an IP A-D per ES route into the IP-VRFs corresponding to the RTs with which the route is tagged. When the complete set of IP A-D per ES routes has been processed, a remote PE will have imported an IP A-D per ES route into each of the IP-VRFs defined on it for that ES; this enables fast convergence for each of these IP-VRFs.¶

2. A PE advertises, for this ES, an Ethernet A-D per EVI route for each of the IP-VRFs defined on it. Each is termed an 'IP A-D per EVI' route and is tagged with the RT for a given IP-VRF, and conveys a label that identifies that IP-VRF. A label in this context refers to an MPLS label, a VNI (VXLAN Network Identifier) or a Segment Routing IPv6 SID, depending on the transport being used.¶

   A remote PE imports an IP A-D per EVI route into the IP-VRF corresponding to the RT with which the route is tagged. The label contained in the route enables aliasing/backup path for the routes in that IP-VRF.¶

To address the third use-case described in Section 1, where the links between a CE and its multihomed PEs are used exclusively for L3 protocols and L3 forwarding, a PE uses the procedures described in 1) and 2), above.¶

The processing of the IP A-D per ES and the IP A-D per EVI routes is as defined in [RFC7432] and [RFC8365] except that the fast convergence and aliasing/backup path functions apply to the routes contained in an IP-VRF. In particular, a remote PE that receives an EVPN MAC/IP Advertisement route or an IP Prefix route with a non-reserved ESI and the RT of a particular IP-VRF SHOULD consider it reachable by every PE that has advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF.¶

4. Fast Convergence for Routed Traffic

Host or Prefix reachability is learned via the BGP-EVPN control plane over the MPLS/NVO network. EVPN IP routes for a given ES are advertised by one or more of the PEs attached to that ES. When one of these PEs fails, a remote PE needs to quickly invalidate the EVPN IP routes received from it.¶

To accomplish this, EVPN defined the fast convergence function specified in [RFC7432]. This document extends fast convergence to inter-subnet forwarding by having each PE advertise a set of one or more IP A-D per ES routes for each locally attached Ethernet segment (refer to Section 4.1 below for details on how these routes are constructed). A PE may need to advertise more than one IP A-D 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 A-D per ES routes for the ES allows each route to contain a subset of the complete set of Route Targets. Each IP A-D 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 A-D 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 A-D 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.¶

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

5. Determining Reachability to Unicast IP Addresses

6. Forwarding Unicast Packets

Refer to Section 5 in [RFC9135] and [RFC9136].¶

7. Load Balancing of Unicast Packets

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

8. IP Aliasing and Unequal ECMP for IP Prefix Routes

[I-D.ietf-bess-evpn-unequal-lb] specifies the use of the EVPN Link bandwidth extended community to achieve weighted load balancing to an ES or Virtual ES for unicast traffic. The procedures in [I-D.ietf-bess-evpn-unequal-lb] MAY be used along with the procedures described in this document for any of the three cases described in Section 1, with the following considerations:¶

• The ES weight is signaled by the multi-homed PEs in the IP A-D per ES routes.¶
• The remote ingress PE learning an EVPN IP Route to prefix/host P that is associated to a weighted load balancing ES, will follow the procedures in [I-D.ietf-bess-evpn-unequal-lb] to influence the load balancing for traffic to P.¶

• [I-D.ietf-bess-evpn-unequal-lb] also allows the use of the EVPN Link Bandwidth Extended Community along with RT-5s. If the ingress PE learns a prefix P via a non-reserved ESI RT-5 route with a weight (for which IP A-D per ES routes also signal a weight) and a zero ESI RT-5 that includes a weight, the ingress PE will consider all the PEs attached to the ES as a single PE when normalizing weights.¶

  As an example, consider PE1 and PE2 are attached to ES-1 and PE1 advertises an RT-5 for prefix P with ESI-1 (and EVPN Link Bandwidth of 1). Consider PE3 advertises an RT-5 for P with ESI=0 and EVPN Link Bandwidth of 2. If PE1 and PE2 advertise an EVPN Link Bandwidth of 1 and 2, respectively, in the IP A-D per ES routes for ES-1, an ingress PE4 SHOULD assign a normalized weight of 1 to ES-1 and a normalized weight of 2 to PE3. When PE4 sprays the flows to P, it will send twice as many flows to PE3. For the flows sent to ES-1, the individual PE EVPN Link Bandwidths advertised in the IP A-D per ES routes will be considered.¶

9. 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.¶

10. IANA Considerations

No IANA considerations.¶

Authors' Addresses