| Internet-Draft | EVPN IRB Evolution | November 2021 |
| Wang | Expires 24 May 2022 | [Page] |
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.¶
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 (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 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.¶
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 [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].¶
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:¶
An Attachment Circuit (AC) that attaches a CE to an IP-VRF but is not an IRB 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.¶
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.¶
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.¶
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].¶
Ethernet Auto-Discovery route per ES, and the EVI for one of its route targets is an IP-VRF.¶
Router's MAC, which is signaled in the Router's MAC extended community.¶
ESI as overlay index.¶
Ethernet Tag ID, it is also called ETI for short in this document.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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) | +------------+ +----------------+
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.¶
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.¶
Now imagine that the BD-20 of above network 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.¶
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) | +------------+ +----------------+
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.¶
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.¶
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:¶
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].¶
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].¶
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.¶
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.¶
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.¶
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.¶
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 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 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.¶
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.¶
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.¶
It is discussed in Section 3.2 of [I-D.wang-bess-evpn-distributed-bump-in-the-wire].¶
TBD.¶