Internet DRAFT - draft-wang-bess-evpn-irb-smooth-evolution
draft-wang-bess-evpn-irb-smooth-evolution
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]
