Internet DRAFT - draft-wang-bess-evpn-ether-tag-id-usage
draft-wang-bess-evpn-ether-tag-id-usage
BESS WG Y. Wang
Internet-Draft ZTE Corporation
Intended status: Standards Track 26 August 2021
Expires: 27 February 2022
Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route
draft-wang-bess-evpn-ether-tag-id-usage-03
Abstract
This draft discusses the issues with several service interfaces of L3
EVIs. Then it proposes an extension to [RFC7432] and
[I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP
aliasing for Layer 3 routes that is needed for L3-EVIs to build a
complete IP ECMP. It also introduced two new EVPN Service Interfaces
for EVPN VPLS services and an extension of AC-ID extended community
to improve ARP/ND Probing upon remote PE 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 27 February 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 27 February 2022 [Page 1]
Internet-Draft ET-ID Usage Update August 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Service Interfaces of L3 EVIs . . . . . . . . . . . . . . 3
1.1.1. IRB Service Interface . . . . . . . . . . . . . . . . 4
1.1.2. Mono VLAN-based Service Interface . . . . . . . . . . 4
1.1.3. Multiple VLAN-based Service Interface . . . . . . . . 4
1.1.4. VLAN-bundle Service Interface . . . . . . . . . . . . 5
1.1.5. Shared Risk VLAN-bundle Service Interface . . . . . . 6
1.1.6. Integrated Routing and Cross-connecting Service
Interface . . . . . . . . . . . . . . . . . . . . . . 7
1.2. New Service Interfaces of L2 EVIs . . . . . . . . . . . . 7
1.2.1. Multiple VLAN-based ACs of the Same BD . . . . . . . 7
1.2.1.1. Attaching these ACs to an ETI-Specific BD . . . . 8
1.2.1.2. Attaching these ACs to an ETI-Agnostic BD . . . . 8
1.2.2. Separated Risk VLAN-bundle AC . . . . . . . . . . . . 9
1.2.2.1. Dedicating Such AC to a Single ETI-Specific BD . 10
1.2.2.2. Attaching Such AC to an ETI-Agnostic BD . . . . . 10
1.3. Terminology and Acronyms . . . . . . . . . . . . . . . . 10
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Problem with Multiple VLAN-based L3SI . . . . . . . . . . 12
2.2. Problem with IRB Service Interface . . . . . . . . . . . 14
2.3. Problem with Multipe VLANs of a Single BD . . . . . . . . 15
2.3.1. Problem with Multipe VLAN-based L2SI . . . . . . . . 15
2.3.2. Problem with Separated Risk VLAN-bundle of a BD . . . 16
2.4. Problem with Bump-in-the-wire Use-Case . . . . . . . . . 16
2.5. Problem with ARP/ND Probing upon Remote PE Failure . . . 18
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Ethernet Auto-Discovery modes . . . . . . . . . . . . . . 19
3.1.1. BDI-Specific EAD vs ACI-Specific EAD . . . . . . . . 19
3.1.2. Use Cases and their ET-IDs and AC-IDs . . . . . . . . 20
3.1.2.1. ETI-ACI Combinations for L2EVI Use Cases . . . . 20
3.1.2.2. ETI-ACI Combinations for EVPN IRB Use Cases . . . 22
3.1.2.3. ETI-ACI Combinations for L3EVI Use Cases . . . . 24
3.2. Determining the Aliasing Pathes for RT-5E/RT-2R . . . . . 25
3.3. ACI-specific Overlay Index Extended Community . . . . . . 27
3.4. ARP/ND Synching and IP Aliasing . . . . . . . . . . . . . 29
3.4.1. Constructing MAC/IP Advertisement Route . . . . . . . 29
3.4.2. Constructing IP-AD/EVI Route . . . . . . . . . . . . 30
Wang Expires 27 February 2022 [Page 2]
Internet-Draft ET-ID Usage Update August 2021
3.5. Constructing IP Prefix Advertisement Route . . . . . . . 31
3.6. Secenario-Specific Procedures . . . . . . . . . . . . . . 31
3.6.1. EVPN-IRB Specific Procedures . . . . . . . . . . . . 31
3.6.2. On Separated Risk VLAN-bundle of the same BD . . . . 32
3.6.3. On Multiple VLAN-based ACs of the same BD . . . . . . 32
3.6.4. Bump-in-the-wire Specific Procedures . . . . . . . . 33
3.6.5. ARP/ND Probing Specific Procedures . . . . . . . . . 35
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Normative References . . . . . . . . . . . . . . . . . . 36
6.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Explanation for Physical Links of the Use-cases . . 38
A.1. Failure Detections for P1.2 (or P2.1) . . . . . . . . . . 39
A.2. Protection Approaches for N1 (or N2) . . . . . . . . . . 39
A.2.1. CCC-Approaches . . . . . . . . . . . . . . . . . . . 39
A.2.1.1. CCC Active-Active Protection . . . . . . . . . . 40
A.2.1.2. CCC Active-Standby Protection . . . . . . . . . . 40
A.2.2. VSI-Approaches . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
In [I-D.wang-bess-evpn-arp-nd-synch-without-irb] section 5.1, the ESI
of IP-VRF ACs are advertised as Overlay index of IP forwarding. But
in IP-VRF context, the Ethernet A-D per EVI routes of the same ESI
are more easier to conflict with each other, when they are imported
into the same IP-VRF. This document discribes three secenarios of
such kind. Then it discribes the solutions of them. These solutions
all need an extension for the Ethernet Tag ID of the Ethernet A-D per
EVI routes. Then this draft proposes two new Service Interfaces for
EVPN VPLS services, they are Multiple VLAN-based ACs of the Same BD
and Dedicating all VLANs of Separated Risk VLAN-bundle AC to a single
BD . When different VLANs on the same ES of the same Broadcast
Domain can fail independently, these two service interfaces will work
better than VLAN-bundle and VLAN-aware bundle service interface.
1.1. Service Interfaces of L3 EVIs
The detailed explanation of this network's physical links are
described in Figure 12 and Appendix A. 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.
Ethernet segment ES1 is the ethernet segment of P1 and P2 of
Figure 12, and its ESI is ESI21.
Wang Expires 27 February 2022 [Page 3]
Internet-Draft ET-ID Usage Update August 2021
1.1.1. IRB Service Interface
The L3 EVI service interface per [I-D.sajassi-bess-evpn-ip-aliasing]
is called as IRB Service Interface in this draft.
1.1.2. Mono VLAN-based Service Interface
+-------------------+
PNEC1 PE1 | |
+---------+ +----------+--------+ |
| | | __(P1.1)__(VPNx) | |
| " | P1 | / | |
| #==============< | | PE3
| " | ESI21 | \__ __ | +----+----+
| N1+--+ | + | (P1.2) (VPNy) | | |
| " | | +-----------+-------+ | (VPNx)---+N3
| " | | | | |
| " | | | | |
| " | | PE2 | | |
| " | | +-----------+-------+ | (VPNy)---+N5
| N2+--" | + | __(P2.2)__(VPNy) | | |
| " | ESI21 | / | +----+----+
| #==============< | |
| " | P2 | \__ __ | |
| | | (P2.1) (VPNx) | |
+---------+ +----------+--------+ |
| |
+-------------------+
Figure 1: Mono VLAN-Based S-I
In this service interface, each ESI can have no more than one of its
VLANs attached to a specified EVPN Instance.
Take above figure for example, P1.1 and P1.2 are two subinterfaces of
the same ESI, and <ESI21, VPNx> is Mono VLAN-based service interface,
thus P1.1 and P1.2 can't be attached to the same EVPN Instance.
Actually, P1.1 are attached to VPNx, while P1.2 are attached to VPNy.
Note that There are no MAC-VRF or IRB interface on PE1/PE2/PE3 in
this case. Thus the IP-VRFs are called as EVPN instance instead.
Such EVPN instance can be called EVPN signalled L3VPN or L3EVI for
short.
1.1.3. Multiple VLAN-based Service Interface
Wang Expires 27 February 2022 [Page 4]
Internet-Draft ET-ID Usage Update August 2021
+-----------------------+
PNEC1 PE1 | |
+---------+ +-------+------+ |
| | | __(P1.1) | |
| " | | / \ | |
| #=============< (VPN1) | | PE3
| " | ESI21 | \__ / | +----+----+
| N1+--" | + | (P1.2) | | |
| " | | +--------+-----+ | |
| " | | | | |
| " | | | | (VPN1)----+N3
| " | | PE2 | | |
| " | | +--------+-----+ | |
| N2+--" | + | __(P2.2) | | |
| " | ESI21 | / \ | +----+----+
| #=============< (VPN1) | |
| " | | \__ / | |
| | | (P2.1) | |
+---------+ +-------+------+ |
| |
+-----------------------+
Figure 2: Multiple VLAN-based S-I
This network is similar to Figure 1 with a few notable exceptions as
below: The L3EVIs VPNx and VPNy there are the same L3EVI (VPN1) here.
So two of PE1's VPN1's ACs are both subinterfaces (P1.1 and P1.2) of
the same ESI (ESI23).
Note that P1.1 is the gateway of N1, while P1.2 is the gateway of N2.
N1 and N2 are just not in the same subnets.
1.1.4. VLAN-bundle Service Interface
When two VLANs of the same ES shares the same Gateway IP address of
the same EVPN, These two VLANs can be configured into the same
subinterface of that ES. This is VLAN-bundle service interface.
Wang Expires 27 February 2022 [Page 5]
Internet-Draft ET-ID Usage Update August 2021
+-----------------------+
PNEC1 PE1 | |
+---------+ +-------+-------------+ |
| | | | |
| " | | (P1.1) AC1 | |
| #=============< >======(VPN1) | | PE3
| " | ESI21 | (P1.2) | +----+----+
| N1+--" | + | | | |
| " | | +--------+------------+ | |
| " | | | | |
| " | | | | (VPN1)----+N3
| " | | PE2 | | |
| " | | +--------+------------+ | |
| N2+--" | + | | | |
| " | ESI21 | (P2.1) AC2 | +----+----+
| #=============< >======(VPN1) | |
| " | | (P2.2) | |
| | | | |
+---------+ +-------+-------------+ |
| |
+-----------------------+
Figure 3: Separated Risk VLAN-Bundle S-I
This network is similar to Figure 2 with a few notable exceptions as
below. P1.1 and P1.2 are aggregated into the same subinterface (that
is AC1). It is AC1 that is attached to VPN1.
Note that although P1.1 and P1.2 are aggregated into the same
subinterface AC1, when <P1, VLAN 1>(P1.1) fails, <P1, VLAN 1>(P1.2)
may not fail. Thus we say that AC1 are configured with Separated
Risk VLAN-Bundle.
Note that VLAN-bundle Service Interface is actually Separated Risk
VLAN-Bundle Service Inerface.
1.1.5. Shared Risk VLAN-bundle Service Interface
There may be other network which is similar to Section 1.1.4, except
for that the VLAN-bundle of AC1 is Shared Risk VLAN-bundle, not
Separated Risk VLAN-bundle.
When we say subinterface AC1 is of Shared Risk VLAN-bundle, we are
saying that when an event result in P1.1's failure, that event will
also result in P1.2's failure.
When AC1 is of Shared Risk VLAN-bundle, we say that <ESI21, VPN1> is
Shared Risk VLAN-bundle service interface.
Wang Expires 27 February 2022 [Page 6]
Internet-Draft ET-ID Usage Update August 2021
1.1.6. Integrated Routing and Cross-connecting Service Interface
The service interface in [I-D.wz-bess-evpn-vpws-as-vrf-ac] can be
called as IRC (Ingegrated Routing and Cross-connecting) Service
Interface.
1.2. New Service Interfaces of L2 EVIs
The detailed explanation of this network's physical links are
described in Figure 12 and Appendix A. 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.
Ethernet segment ES1 is the ethernet segment of P1 and P2 of
Figure 12, and its ESI is ESI21.
1.2.1. Multiple VLAN-based ACs of the Same BD
+-----------------------+
PNEC1 PE1 | |
+---------+ +-------+------+ |
| | | __(P1.1) | |
| " | | / \ | |
| #=============< (BD100) | | PE3
| " | ESI21 | \__ / | +----+----+
| N1+--" | + | (P1.2) | | |
| " | | +--------+-----+ | |
| " | | | | |
| " | | | | (BD100)---+N3
| " | | PE2 | | |
| " | | +--------+-----+ | |
| N2+--" | + | __(P2.2) | | |
| " | ESI21 | / \ | +----+----+
| #=============< (BD100) | |
| " | | \__ / | |
| | | (P2.1) | |
+---------+ +-------+------+ |
| |
+-----------------------+
Figure 4: Multiple VLAN-based S-I
This network is similar to Figure 2 with a few notable exceptions as
below: The EVI there (VPN1) is a L3 EVI, but the EVI here is a L2 EVI
(one of whose BDs is BD100).
Wang Expires 27 February 2022 [Page 7]
Internet-Draft ET-ID Usage Update August 2021
Note that P1.1 and P1.2 are two ACs of BD100. thus they are two
subinterfaces of the same ESI (ESI21) and the same BD.
1.2.1.1. Attaching these ACs to an ETI-Specific BD
A Broadcast Domain (BD) whose data packets can be received along with
any Ethernet Tag ID (ETI). When an EVPN Instance (EVI) can have
multiple broadcast domains (BDs), every BD of that EVI Instance will
be called as an ETI-specific BD in this draft.
An ETI-Specific BD is identified by an ET-ID in the context of that
EVI. That ET-ID are called as that ETI-Specific BD's BD-ID in this
draft. That is to say, all MAC entries of that ETI-Specific BD are
in a MAC-space identified by that BD-ID. Thus the ET-ID fields of
the RT-2 routes of these MAC entries will all be set to the value of
that BD-ID. That's why the BD-ID is also called as the normalized
ET-ID of that BD.
Although the VLANs of P1.1 and P1.2 are different, when P1.1 and P1.2
are configured with the same normalized ET-ID, they will belong to
the same ETI-specific BD whose BD-ID is that normalized ET-ID.
If a BD is an ETI-Specific BD, when we say that an AC is attached to
that BD, we means that the AC is attached to the EVI of that BD, and
the normalized ET-ID of that AC is configured with the BD-ID of that
BD.
So we assign the same normalized ET-ID (say ET-ID 100) to P1.1, P1.2,
P2.1 and P2.2. As a result of that, and according to [RFC7432], the
Ethernet A-D per EVI routes for P1.1 and P1.2 will be the same (say
R1_100_P1b), the Ethernet A-D per EVI routes for P2.1 and P2.2 will
be the same (say R1_100_P2b). The ET-IDs of R1_100_P1b and
R1_100_P2b will be the same ET-ID 100.
1.2.1.2. Attaching these ACs to an ETI-Agnostic BD
When an EVPN Instance (EVI) can only have one broadcast domain (BD),
the only BD of that EVI Instance will be called as an ETI-Agnostic BD
in this draft. A broadcast domain of a L2 EVI of VLAN-based service
interface is a good example of an ETI-Agnostic BD.
If a BD is an ETI-Agnostic BD, when we say that an AC is attached to
that BD, we means that the AC is attached to the EVI of that BD. The
ET-ID fields of the RT-2 routes of all MAC entries of a ETI-Agnostic
BD will always be zero.
Wang Expires 27 February 2022 [Page 8]
Internet-Draft ET-ID Usage Update August 2021
When P1.1, P1.2, P2.1 and P2.2 are attched to an ETI-agnostic BD,
according to [RFC7432], the Ethernet A-D per EVI routes for P1.1 and
P1.2 will be the same (say R1_100_P1c), the Ethernet A-D per EVI
routes for P2.1 and P2.2 will be the same (say R1_100_P2c). The ET-
IDs of R1_100_P1c and R1_100_P2c will both be the same value (that's
zero) too.
1.2.2. Separated Risk VLAN-bundle AC
Although P1.1 and P1.2 can be aggregated into a single subinterface,
this can't change the fact that they don't share the same risks.
When the physical interface P3 (see Figure 12) fails, one of them
will fail, while the other will continue to work well.
+-----------------------+
PNEC1 PE1 | |
+---------+ +-------+-------------+ |
| | | | |
| " | | (P1.1) AC1 | |
| #=============< >=====(BD100) | | PE3
| " | ESI21 | (P1.2) | +----+----+
| N1+--" | + | | | |
| " | | +--------+------------+ | |
| " | | | | |
| " | | | | (BD100)---+N3
| " | | PE2 | | |
| " | | +--------+------------+ | |
| N2+--" | + | | | |
| " | ESI21 | (P2.1) AC2 | +----+----+
| #=============< >=====(BD100) | |
| " | | (P2.2) | |
| | | | |
+---------+ +-------+-------------+ |
| |
+-----------------------+
Figure 5: Separated Risk VLAN-Bundle S-I
This network is similar to Figure 4 with a few notable exceptions as
below. P1.1 and P1.2 are aggregated into the same subinterface (that
is AC1). Now it is AC1 that is attached to VPN1, not P1.1 or P1.2.
Note that although P1.1 and P1.2 are aggregated into the same
subinterface AC1, when <P1, VLAN 1>(P1.1) fails, <P1, VLAN 1>(P1.2)
may not fail. Thus we say that AC1 are configured as Separated Risk
VLAN-Bundle Service Interface.
Wang Expires 27 February 2022 [Page 9]
Internet-Draft ET-ID Usage Update August 2021
Note that VLAN-bundle Service Interface of [RFC7432] is actually
Shared Risk VLAN-Bundle Service Inerface.
1.2.2.1. Dedicating Such AC to a Single ETI-Specific BD
When we say AC1 (which is a VLAN-bundle subinterface) is dedicated to
BD100, That is saying that AC1 is attached to the EVI of BD100, and
all VLANs of AC1 is configured with BD100's normalized ET-ID (that's
100).
According to [RFC7432], the Ethernet A-D per EVI routes for P1.1 and
P1.2 will be the same (say R1_100_P1d), the Ethernet A-D per EVI
routes for P2.1 and P2.2 will be the same (say R1_100_P2d). Both
R1_100_P1d and R1_100_P2d will have an ET-ID 100.
Note that if each VLAN has individual normalized ET-ID, it is just
normal VLAN-aware bundle service interface as per [RFC7432]. In such
case, we say that the VLAN-mapping relationship between the AC and
BD100 is 1:1 mapping, but when the AC is dedicated to a single ETI-
Specific BD, the VLAN-mapping relationship betwenn the AC and BD100
is N:1 mapping.
Note that when we say an VLAN-bundle AC is attached to an ETI-Specifc
BD, that AC may be dedicated to that BD in some use cases, but maybe
only a VLAN of that AC is attached to that BD in some other use
cases.
1.2.2.2. Attaching Such AC to an ETI-Agnostic BD
When a BD is not ETI-Specific, we can say that it is ETI-Agnostic.
When we say an AC is attached to an ETI-Agnostic BD, it means that
all VLANs of that AC are attached to that ETI-Agnostic BD. In other
words, the AC is dedicated to that BD.
When the BD is ETI-Agnostic, according to [RFC7432], the Ethernet A-D
per EVI routes for P1.1 and P1.2 will be the same (say R1_100_P1e),
the Ethernet A-D per EVI routes for P2.1 and P2.2 will be the same
(say R1_100_P2e). Both R1_100_P1e and R1_100_P2e will have an zero
ET-ID.
1.3. 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.
Wang Expires 27 February 2022 [Page 10]
Internet-Draft ET-ID Usage Update August 2021
* 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.
* IP-AD/EVI - Ethernet Auto-Discovery route per EVI, and the EVI
here is an IP-VRF. Note that the Ethernet Tag ID of an IP-AD/
EVI route may be not zero.
* IP-AD/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
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.
* RT-5E - An EVPN Prefix Advertisement Route with a non-reserved
ESI as its overlay index (the ESI-as-Overlay-Index-style RT-5)
.
* IRC - Integrated Routing and Cross-connecting, thus a IRC
interface is the virtual interface connecting an IP-VRF and an
EVPN VPWS.
* CE-BGP - The BGP session between PE and CE. Note that CE-BGP
route doesn't have a RD or Route-Target.
* CE-Prefix - An IP Prefixes behind a CE is called as that CE's
CE-Prefix.
* EVC - Ethernet Virtual Connection, which is typically
constructed per <Port, VLAN> basis.
* ETI-Agnostic BD - A Broadcast Domain (BD) whose data packets
Wang Expires 27 February 2022 [Page 11]
Internet-Draft ET-ID Usage Update August 2021
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.
* ACI-Specific EADR - When the <ESI, BD> uses ACI-Specific
Ethernet Auto-discovery mode, the Ethernet A-D per EVI routes
of that <ESI, BD> are called as ACI-Specific EADRs in this
draft.
* U-Tag - User Tag, a data packet's U-tag is a tag which is not
used to find out the AC of that data packet. The U-Tag
typically is not configured on the AC.
2. Problem Statement
2.1. Problem with Multiple VLAN-based L3SI
Wang Expires 27 February 2022 [Page 12]
Internet-Draft ET-ID Usage Update August 2021
+--------------------------+
PNEC1 PE1 | |
+-------------+ +-------+------+ | PE3
| | | X__(20.9) | ----X----> +----+----+
| " | P1 | / \ | Withdraw | |
| #==============< (VPN1) | IP-AD/EVI | (VPN1)---+N6
| R1_______" | ESI21 | \__ / | ET-ID=0 | |
| 10.2 " | + | (10.9) | +----+----+
| " | | +--------+-----+ |
| " | | | |
| " | | | | DGW1
| " | | PE2 | +----+----+
| R2_______" | | +--------+-----+ | |
| 20.2 " | + | __(20.9) | |(3.3.3.3)|
| " | ESI21 | / \ | | | |
| #==============< (VPN1) | Withdraw | (VPN1)---+N3
| " | P2 | \__ / | IP-AD/EVI | |
| | | X (10.9) | ----X----> +----+----+
+-------------+ +-------+------+ ET-ID=0 |
| |
+--------------------------+
Figure 6: RT-1 Confliction of L3EVIs
The IP addresses of P1.1, P1.2, P2.1, P2.2, R1 and R2 (see Figure 2)
are illustrated in above Figure.
P1 and P2 are configured with the same ESI ESI21, thus an Ethernet
A-D per EVI route ETI_10_2 is advertsed for P1.1, an Ethernet A-D per
EVI route ETI_10_3 is advertsed for P2.1, an Ethernet A-D per EVI
route ETI_20_2 is advertsed for P1.2, and an Ethernet A-D per EVI
route ETI_20_3 is advertsed for P2.2.
When PE3 receives ETI_10_2 and ETI_20_2, it will pick up only one of
them to be installed to the data plane. Because that they have the
same <RD,ESI,ET-ID> and nexthop. We assume that the ETI_20_2 are
picked out. When PE3 receives ETI_10_3 and ETI_20_3, it will also
pick up only one of them to be installed to the data plane. Because
that they also have the same <RD,ESI,ET-ID> and nexthop. We assume
that the ETI_20_3 are picked out.
Although PE1 will advertise a RT-5 Route R5_SN8_1 (whose ESI is
ESI23) to PE3, When H3 send data packet DP_3_8 to a host in SN8 after
P1.1 fails, PE3 may still send DP_3_8 to PE1 because that PE3 will
load-balance traffics just fllowing ETI_20_2 and ETI_20_3. That's a
problem that will cause packet-drop or traffic-bypassing.
Wang Expires 27 February 2022 [Page 13]
Internet-Draft ET-ID Usage Update August 2021
When physical port P3 (see Figure 12, which illustrates the physical
links of Figure 6) fails, the CFM session of P2.1 (10.9 of PE2) goes
down (illustrated by the 'X' inside PE2), while the CFM session of
P2.2 (20.9 of PE2) continues to be UP. thus only the IP-AD/EVI route
(whose ET-ID=1) of P2.1 should be withdrawn by PE2. the IP-AD/EVI
route (where ET-ID=2) of P2.2 and the IP-AD/ES route should not be
withdrawn by PE2.
Note that if the ET-IDs of these two IP-AD/EVI routes are the same,
when P2.1 fails, DGW1 will continue to load-balance traffics whose
DA=20.2 to PE2, because that there is still another IP-AD/EVI route
(of VPN1) whose ESI and ET-ID are the same. That's why ACI-Specific
Auto-discovery (Section 3.1.1) should be followed.
The solution for this problem is decribed in Section 3.
2.2. Problem with IRB Service Interface
The detailed explanation of this network's physical links are
described in Figure 12 and Appendix A. 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.
PNEC1 PE1
+------------+ +----------------+
| | | __(BD-20) |
| H4 " | P1 | / \ IRB21 |
| | #================ (IP-VRF) +-----------------+
| N1______" | ESI21 | \__ / IRB11 | |
| 10.2 " | + | (BD-10) | | PE3
| " | | +----------------+ +---+----+
| " | | | |
| " | | |(IP-VRF)+-+H3
| " | | PE2 | |
| N2______" | | +----------------+ +---+----+
| 20.2 " | + | __(BD-10) | |
| " | ESI21 | / \ IRB12 | |
| #================ (IP-VRF) +-----------------+
| " | P2 | \__ / IRB22 |
| | | (BD-20) |
+------------+ +----------------+
Figure 7: RT-1 Confliction of EVPN IRB
The BD-10 here is the VPNx of Figure 12, and the BD-20 is the VPNy of
Figure 12.
Wang Expires 27 February 2022 [Page 14]
Internet-Draft ET-ID Usage Update August 2021
BD-10 and BD-20 are both BDs (broadcast domains), not IP-VRFs. 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.
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.
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.6.1.
2.3. Problem with Multipe VLANs of a Single BD
2.3.1. Problem with Multipe VLAN-based L2SI
We want the IP addresses of N1, N2 and N3 are of the same subnet (say
SN100), so we select the network of Figure 4 to accomplish that. Now
assume that the BD100 of that network is a ETI-Agnostic broadcast
domain. That's to say that, the EVI of BD100 is of VLAN-based
service interface.
According to [RFC7432], the Ethernet A-D per EVI routes for P1.1 and
P1.2 will be the same (say R1_100_P1), the Ethernet A-D per EVI
routes for P2.1 and P2.2 will be the same (say R1_100_P2). Both
R1_100_P1 and R1_100_P2 will have a zero Ethernet Tag ID.
Wang Expires 27 February 2022 [Page 15]
Internet-Draft ET-ID Usage Update August 2021
So when the CFM of subinterface P1.1 fails, if R1_100_P1 is
withdrawn, the forwarding of N2's packets (data packets which are
destined to N2) will be in the wrong, but if R1_100_P1 is not
withdrawn, the forwarding of N1's packets will be affected. That's
the problem.
The solution for this problem is decribed in Section 3.6.2.
2.3.2. Problem with Separated Risk VLAN-bundle of a BD
Then P1.1 and P1.2 of Section 2.3.1 are aggregated into a single
subinterface (see AC1 of Figure 5). The BD-100 is an ETI-Specific
BD. Although that EVI is of VLAN-aware bundle Service Interface and
the VLANs of P1.1 and P1.2 are different, P1.1 and P1.2 can't be
attached to the same broadcast domain of that EVI. Because that we
still want the IP addresses of N1,N2 and N3 are of the same subnet
(say SN100), like what we have expected in Section 2.3.1.
So we assign the same normalized ET-ID (say ET-ID 100) to P1.1, P1.2,
P2.1 and P2.2. As a result of that, the Ethernet A-D per EVI routes
for P1.1 and P1.2 will be the same (say R1_100_P1b), the Ethernet A-D
per EVI routes for P2.1 and P2.2 will be the same (say R1_100_P2b).
Both R1_100_P1b and R1_100_P2b will have a ET-ID 100.
So when the CFM of subinterface P1.1 fails, if R1_100_P1b is
withdrawn, the forwarding of N2's packets (those packets destinating
to N2) will be in the wrong, but if R1_100_P1b is not withdrawn, the
forwarding of N1's packets will be affected. That's the problem.
Note that this problem will not be resolved even if R1_100_P1b can
carry two AC-ID Extended Communities (one per AC).
The solution for this problem is decribed in Section 3.6.3.
2.4. Problem with Bump-in-the-wire Use-Case
Section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement] defined the
Bump-in-the-wire use-case, where a style (which is called as RT-5E in
this draft) of RT-5 routes (whose overlay index is a non-zero ESI),
is used to advertise the IP prefix of subnet SN1 (see Figure 8). The
RT-5E routes (whose IP prefix is SN1, and ESI is ESI23) of that draft
is called as RT5E_SN1 in this draft. And the RT-1 routes (whose ESI
is ESI23) corresponding to the RT5E_SN1 is called as RT1_ESI23 in
this draft.
Wang Expires 27 February 2022 [Page 16]
Internet-Draft ET-ID Usage Update August 2021
RT1_ESI23 is advertised for BD-10, but how RT5E_SN1 is advertised and
how it is imported into IP-VRF are not very clear in that draft. In
some secenarios, the obscureness may have influence on what behavior
of a RT-5E route should be expected for non-upgraded DGW1 following
that draft. Take the following network for example:
TS2 NVE2
+--------------+ +---------------+
| | | |
SN7-----(N2-M4)__ | | __(BD-20) |
| \ | IF2 | / |
| =============== +-------+
| __/ | ESI23 | \__ | |
+----- (N1-M2) | + | (BD-10) | | DGW1
| | | | | | +---+-----+
| +--------------+ | +---------------+ | (BD-10) |
| | | \IRB1 |
SN1 | |(IP-VRF) +-+H3
| TS3 | NVE3 | /IBR3 |
| +--------------+ | +---------------+ | (BD-20) |
| | | | | | +---+-----+
+------(N1-M3)__ | + | __(BD-10) | |
| \ | ESI23 | / | |
| =============== +-------+
| __/ | IF3 | \__ |
SN7-----(N2-M5) | | (BD-20) |
| | | |
+--------------+ +---------------+
Figure 8: RT-1 Confliction of Bump-in-the-wire
This network is similar to Figure 7 of
[I-D.ietf-bess-evpn-prefix-advertisement] with a few notable
exceptions as below.
The NVE2,NVE3,DGW1,IRB1,BD-10,ESI23,TS2,TS3 and SN1 here is the
NVE2,NVE3,DGW1,IRB1,BD-10,ESI23,TS2,TS3 and SN1 there. The N1 here
is the Virtual Appliance (whose VA-MAC is M2/M3 on TS2/TS3) there.
But here we have another Virtual Appliance N2, which are attached to
another Broadcast Domain BD-20. Both BD-10 and BD-20 are integrated
into the same IP-VRF by DGW1. But the subnet SN1 can only be reached
through BD-10, while the subnet SN7 can only be reached through BD-
20.
If RT5E_SN1 is imported into IP-VRF directly by DGW1 using its route-
target (whose value is not clear in that draft), PE3 will not know
which BD should the RT-1 per EVI routes for RT5E_SN1 be selected
Wang Expires 27 February 2022 [Page 17]
Internet-Draft ET-ID Usage Update August 2021
from, and PE3 will not know which MAC should the SA of the data
packets corresponding to RT5E_SN1 be set to. But if RT5E_SN1 (whose
route-target identifying BD-10) is imported into the BD-10 at first,
although it can be imported into the IP-VRF following BD-10's IRB
interface, RT5E_SN1 will not be imported into the IP-VRF on other PEs
which don't have an instance of BD-10. Thus such PEs are precluded
from connecting to the hosts of SN1 by such rules.
Note that both BD-10 and BD-20 are L2 EVIs of VLAN-based Service
Interfaces.
The solution for this problem is decribed in Section 3.6.4.
2.5. Problem with ARP/ND Probing upon Remote PE Failure
In order to avoid blackholing, when PE2 detects loss of reachability
to PE1, it can trigger ARP/ND requests for all synced IP prefixes
received from PE1 across all affected BDs. This will force host H21a
(a host of subnet SN31) to reply to the solicited ARP/ND messages
from PE2 and refresh both MAC and IP for the corresponding host in
its tables.
This procedures are called as ARP/ND Probing in this draft, the
problem with ARP/ND Probing are described as the following:
+-----------------+
PNEC1 PE1 | |
+----------------------+ +-------+------+ |
| | (S-VLAN21) | __(P1.1) | |
| SN31(C-VLAN31) " | QinQ-uplink | / \ | |
| | #===================< (BD100) | |
| + QinQ-Access " | ESI21 | \__ / | +--+--+
| N1+---------------" | + | (P1.2) | | |
| + Trunk " | | +--------+-----+ | |
| | " | | | | |
| SN32(C-VLAN32) " | | | | PE3 |
| " | | PE2 | | |
| Trunk " | | +--------+-----+ | |
| N2+---------------" | + | __(P2.2) | | |
| QinQ-Access " | ESI21 | / \ | +--+--+
| #===================< (BD100) | |
| " | QinQ-uplink | \__ / | |
| | (S-VLAN21) | (P2.1) | |
+----------------------+ +-------+------+ |
| |
+-----------------+
Figure 9: RT-1 Confliction of Bump-in-the-wire
Wang Expires 27 February 2022 [Page 18]
Internet-Draft ET-ID Usage Update August 2021
But when QinQ is enabled in PNEC1 but the ACs (P1.1 and P2.1) are
still dot1q subinterface. The ARP/ND Probing procedures will fail.
Because PE2 doesn't know the required C-VLAN of H21a. Although AC-ID
extended coummunity of [I-D.sajassi-bess-evpn-ac-aware-bundling] can
be used, the AC-ID extended coummunity is not used to advertise
U-Tags. So PE2 can not trigger an ARP/ND request along with the
required C-VLAN (that's C-VLAN 31) of H21a.
The solution for this problem is decribed in Section 3.6.5.
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. Ethernet Auto-Discovery modes
When the AC-type is N:1 mapping, we propose a new Ethernet Auto-
discovery mode, It is called as ACI-Specific Ethernet A-D mode in
this draft, while the Ethernet A-D mode from [RFC7432] are called as
BDI-Specific Ethernet A-D mode in this draft.
3.1.1. BDI-Specific EAD vs ACI-Specific EAD
* BDI-Specific Ethernet A-D mode - 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.
* ACI-Specific Ethernet A-D mode - 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 ACI-Specific
Ethernet Auto-discovery mode, and each of such Ethernet A-D per EVI
route is called as a ACI-Specific EADR (Ethernet A-D per EVI Route)
in this draft.
Note that when a Shared Risk VLAN-bundle AC is dedicated to a single
BD, either BDI-Specific EAD-mode or ACI-Specific EAD-mode can be
used. But when a Separated Risk VLAN-bundle AC is dedicated to a
single BD, only ACI-Specific EAD-mode should be used.
Note that when BDI-Specific Ethernet Auto-Discovery is used, the IP-
AD per EVI route's ET-ID should be set to the BD-Identifier of its
BD. When ETI-Specific Ethernet Auto-Discovery is used, the the ET-
IDs of the IP-AD per EVI routes of the <ESI, BD> should be set per
each VLAN of the bundle, but the ET-ID of RT-2R should still be set
Wang Expires 27 February 2022 [Page 19]
Internet-Draft ET-ID Usage Update August 2021
to the BD-Identifier of that BD. As a result of that, an AC-ID
Overlay Index Extended Community should be carried along with that
RT-2R in ETI-Specific Ethernet A-D mode.
3.1.2. Use Cases and their ET-IDs and AC-IDs
The advertisement of ET-IDs and AC-IDs can be combined in many ways,
which are illustrated in Table 1:
3.1.2.1. ETI-ACI Combinations for L2EVI Use Cases
+======+==============+=================+========+=======+=======+
| No | BD-Type | AC-Type | AC-ETI | BD-ID | ACI-T |
+======+==============+=================+========+=======+=======+
| 1 | ETI-Agnostic | Mono VLAN | 0 | 0 | / |
+------+--------------+-----------------+--------+-------+-------+
| 2 | ETI-Agnostic | N:1 Shared | 0 | 0 | AC-ID |
+------+--------------+-----------------+--------+-------+-------+
| 3 | ETI-Agnostic | N:1 Shared | ACI | 0 | AOI |
+------+--------------+-----------------+--------+-------+-------+
| 4 | ETI-Agnostic | N:1 Separated * | ACI | 0 | AOI |
+------+--------------+-----------------+--------+-------+-------+
| 5 | ETI-Specific | 1:1 mapping | BDI | BDI | / |
+------+--------------+-----------------+--------+-------+-------+
| 6 ** | ETI-Specific | N:1 Shared | BDI | BDI | AC-ID |
+------+--------------+-----------------+--------+-------+-------+
| 7 | ETI-Specific | N:1 Shared | ACI | BDI | AOI |
+------+--------------+-----------------+--------+-------+-------+
| 8 | ETI-Specific | N:1 Separated | ACI | BDI | AOI |
+------+--------------+-----------------+--------+-------+-------+
Table 1: Combinations for L2EVIs
The Table is explained in details as the following:
o The "BD-Type","AC-Type" Columns: Which use cases can each
combination be used for?
* BD-Type: Which type of broadcast domain is selected in that use
case?
* AC-Type: Which type of AC is slected for that BD in that use
case?
* ETI-Specific: The broacast domain is an ETI-specific BD.
* ETI-Agnostic: The broacast domain is an ETI-agnostic BD.
* Mono VLAN: only one VLAN of the ES is attached to the ETI-
Agnostic BD.
* N:1 Separated: a VLAN-bundle AC whose risk factors is separated
per each VLAN of its own.
Wang Expires 27 February 2022 [Page 20]
Internet-Draft ET-ID Usage Update August 2021
* N:1 Shared: a VLAN-bundle AC whose VLANs will share the same
risks.
* N:1 mapping: a VLAN-bundle AC whose VLANs are all attached to
the same BD.
* 1:1 mapping: only one VLAN of the ES is attached to the ETI-
specific BD.
o The "AC-ETI", "IP-ETI", "ACI-T" Columns: Which value can each
field be assigned to?
* AC-ETI: The ET-ID field of RT-1 per EVI route of that BD.
* BD-ID: The ET-ID field of a RT-2 route. it is the identifier
(in the context of an EVI) of that RT-2 route's broadcast
domain.
* ACI-T: Which Extended Community should the ACI be carried in?
Attachment Circuit ID Extended Community or AOI Extended
Community?
* ACI: The AC-ID of an AC for a specified broadcast domain.
Note that when the AC-Type is N:1 Separated, different VLAN
of that AC have different ACI, the ACI typically will be
the same value with the corresponding VLAN.
* AOI: The ACI is encapsulated as AOI Extended Coummunity.
Note that in such case, the ACI is the overlay index of
that RT-2R or RT-5E. When the AC-Type is N:1 Separated,
each RT-1 per EVI route will select individual VLAN of that
AC to be its own AOI.
* AC-ID: The ACI is encapsulated as Attachment Circuit ID Extended
Community.
Note that in such case the AOI is still the ET-ID field of
that RT-2R or RT-5E.
* BDI: That field is set to the BD identifier of an ETI-Specific
BD.
* 0: That field is set to zero.
* /: That Attachment Circuit ID Extended Community is not
carried along with that RT-2R or RT-5E route.
o The "No." Column: The index number of each use case.
o Notes:
* When the AC-Type is N:1 shared or N:1 Separated, we can say the
AC-Type is N:1 mapping.
** This follows [I-D.sajassi-bess-evpn-ac-aware-bundling].
Wang Expires 27 February 2022 [Page 21]
Internet-Draft ET-ID Usage Update August 2021
3.1.2.2. ETI-ACI Combinations for EVPN IRB Use Cases
+=====+==============+===============+=========+==========+========+
| No. | BD-Type | L2AC-Type | IAD-ETI | RT2R-ETI | IP-ACI |
+=====+==============+===============+=========+==========+========+
| 19 | ETI-Agnostic | Mono VLAN | 0 | 0 | / |
+-----+--------------+---------------+---------+----------+--------+
| 20 | ETI-Agnostic | N:1 Shared | 0 | 0 | AC-ID |
+-----+--------------+---------------+---------+----------+--------+
| 21 | ETI-Agnostic | N:1 Shared | ACI | 0 | AOI |
+-----+--------------+---------------+---------+----------+--------+
| 22 | ETI-Agnostic | N:1 Separated | ACI | 0 | AOI |
+-----+--------------+---------------+---------+----------+--------+
| 23 | ETI-Specific | 1:1 mapping | 0* | BDI | / |
+-----+--------------+---------------+---------+----------+--------+
| 24 | ETI-Specific | N:1 Shared | 0 | BDI | AC-ID |
+-----+--------------+---------------+---------+----------+--------+
| 25 | ETI-Specific | N:1 Shared | ACI | BDI | AOI |
+-----+--------------+---------------+---------+----------+--------+
| 26 | ETI-Specific | N:1 Separated | ACI | BDI | AOI |
+-----+--------------+---------------+---------+----------+--------+
| 29 | ETI-0 BDs | Any | ACI | 0 | AOI |
+-----+--------------+---------------+---------+----------+--------+
| 30 | ETI-X BDs | Any | ACI | BDI* | AOI |
+-----+--------------+---------------+---------+----------+--------+
Table 2: Combinations for EVPN IRB
The Table is explained in details as the following:
o The "BD-Type", "L2AC-Type" Columns: Which use cases can each
combination be used for?
* L2AC-Type: Which type of AC is used for that BD in that use
case?.
* Any: Regardless of which type the L2 AC is.
* ETI-0 BDs: Multiple ETI-Agnostic BDs on the same ES are
integrated into the same L3EVI.
* ETI-X BDs: Multiple ETI-Specific BDs on the same ES are
integrated into the same L3EVI.
o The "IAD-ETI", "RT2R-ETI", "IP-ACI" Columns: Which value can each
field be assigned to?
* IAD-ETI: The Ethernet Tag ID field of IP AD per EVI route of
that IP-VRF.
* RT2R-ETI: The Ethernet Tag ID field of RT-2R route.
* IP-ACI: Which Extended Community should the ACI be carried in?
Wang Expires 27 February 2022 [Page 22]
Internet-Draft ET-ID Usage Update August 2021
Attachment Circuit ID Extended Community or AOI Extended
Community?
o Notes:
* The ET-ID of IP-AD per EVI route should be set to 0 according to
[I-D.sajassi-bess-evpn-ip-aliasing], even if the BD is of VLAN-
aware bundle service interface.
** The ET-ID of RT-2R route should be set to the BDI of a ETI-
Specific BD according to
[I-D.ietf-bess-evpn-inter-subnet-forwarding].
+======+============+===============+==========+==========+========+
| No. | BD-Type | L2AC-Type | L2AC-ETI | RT5E-ETI | IP-ACI |
+======+============+===============+==========+==========+========+
| 11 | BumpWire0 | Mono VLAN | 0 | 0 | / |
+------+------------+---------------+----------+----------+--------+
| 12 | BumpWire0 | N:1 Shared | 0 | 0 | AC-ID |
+------+------------+---------------+----------+----------+--------+
| 13 | BumpWire0 | N:1 Shared | ACI | 0 | AOI |
+------+------------+---------------+----------+----------+--------+
| 14 | BumpWire0 | N:1 Separated | ACI | 0 | AOI |
+------+------------+---------------+----------+----------+--------+
| 15* | BumpWireX | 1:1 mapping | BDI | BDI | / |
+------+------------+---------------+----------+----------+--------+
| 16 | BumpWireX | N:1 Shared | BDI | BDI | AC-ID |
+------+------------+---------------+----------+----------+--------+
| 17 | BumpWireX | N:1 Shared | ACI | BDI | AOI |
+------+------------+---------------+----------+----------+--------+
| 18** | BumpWireX | N:1 Separated | ACI | BDI | AOI |
+------+------------+---------------+----------+----------+--------+
| 27 | BumpWire0s | Any | ACI | 0 | AOI |
+------+------------+---------------+----------+----------+--------+
| 28 | BumpWireXs | Any | ACI | BDI | AOI |
+------+------------+---------------+----------+----------+--------+
Table 3: Combinations for Bump-in-the-wire
The Table is explained in details as the following:
o The "BD-Type", "L2AC-Type" Columns: Which use cases can each
combination be used for?
* BumpWire0: The broadcast domain is an ETI-Agnostic BD, and the
use case is a Bump-in-the-wire use case. This is the
original Bump-in-the-wire use case of
[I-D.ietf-bess-evpn-prefix-advertisement] section 4.3.
Wang Expires 27 February 2022 [Page 23]
Internet-Draft ET-ID Usage Update August 2021
* BumpWireX The broadcast domain is an ETI-Specific BD, and the
use case is a Bump-in-the-wire use case.
* BumpWire0s: Multiple BumpWire0-BDs on the same ES are integrated
into the same L3EVI.
* BumpWireXs: Multiple BumpWireX-BDs on the same ES are integrated
into the same L3EVI.
o The "L2AC-ETI", "RT5E-ETI", "IP-ACI" Columns: Which value can each
field be assigned to?
* L2AC-ETI: The Ethernet Tag ID field of Ethernet A-D per EVI
route of the L2AC of that BD.
* RT5E-ETI: The Ethernet Tag ID field of RT-5E route.
o Notes:
* When the BD-10 of above Bump-in-the-wire use case is replaced
with an ETI-specific BD, that use case is called ETI-specific
Bump-in-the-wire use case. The ETI-specific Bump-in-the-wire
use case is implied in [I-D.ietf-bess-evpn-prefix-advertisement]
as discussed in Section 3.5, Paragraph 4.
** When the BD-10 of above Bump-in-the-wire use case is replaced
with an ETI-specific BD and ACI-Specific EAD mode ACs, that use
case is called N:1 ETI-specific Bump-in-the-wire use case.
3.1.2.3. ETI-ACI Combinations for L3EVI Use Cases
+=====+=====================+==========+========+========+====+
| No. | Use Cases | L3AC-ETI | IP-ETI | IP-ACI | |
+=====+=====================+==========+========+========+====+
| 33 | Multiple VLAN-based | ACI | 0 | AOI | |
+-----+---------------------+----------+--------+--------+----+
| 34 | Separated Risk | ACI | ACI | / | * |
+-----+---------------------+----------+--------+--------+----+
| 35 | Mono VLAN-based | 0 | 0 | / | |
+-----+---------------------+----------+--------+--------+----+
| 36 | Shared Risk | ACI | 0 | AOI | ** |
+-----+---------------------+----------+--------+--------+----+
Table 4: Combinations for L3EVIs
The Table is explained in details as the following:
o The "Use Cases" Column: Which use cases can each combination be
used for?
* L3 EVPN Service Interfaces: Mutiple VLAN-based service
Wang Expires 27 February 2022 [Page 24]
Internet-Draft ET-ID Usage Update August 2021
interface, Separated Risk VLAN-bundle service interface,
Mono VLAN-based service interface, Shared Risk service
interface.
o The "L3AC-ETI", "IP-ETI", "IP-ACI" Columns: Which value can each
field be assigned to?
* IP-ETI: The Ethernet Tag ID field of RT-5E route.
* L3AC-ETI: The ET-ID field of IP-AD per EVI route of that L3EVI.
o Notes:
* Both Multiple VLAN-based service interface and Separated Risk
VLAN-bundle service interface can use combinations 33-34. The
difference is that the ACI of combination 34 will be
encapsulated into data packets, but the ACI of combination 33
won't.
** Both Mono VLAN-based service interface and Shared Risk VLAN-
bundle service interface can use combinations 35-36. If you are
not very sure whether the risks are shared or separated, the
combination 36 will be safer.
3.2. Determining the Aliasing Pathes for RT-5E/RT-2R
When PE3 forward a data packet DP_2021 according to an IP Prefix
advertisement route R5_2021 whose overlay index is an ESI, If the ET-
ID of R5_2021 is a non-reserved ET-ID, DP_2021 should not be
forwarded according to an ethernet A-D per EVI route R1_2021, unless
the ET-ID and ESI of R1_2021 are both the same as that of R5_2021.
Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the IP-AD 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-AD/EVI route instead, even if there is a RMAC
in RT-2R route.
Note that this is a data-plane update of
[I-D.ietf-bess-evpn-prefix-advertisement] for both EVPN signalled
L3VPN and [I-D.sajassi-bess-evpn-ip-aliasing]. According to
[I-D.ietf-bess-evpn-prefix-advertisement] section 4.3 or
[I-D.ietf-bess-evpn-inter-subnet-forwarding] section 5.4, the inner
destination MAC will follow the RMAC of RT-5E Route or RT-2R Route.
When selecting corresponding IP-AD/EVI routes for a RT-5E route, the
AOI Extended Community (if it exists) of the RT-5E route is prefered
than the ET-ID of the RT-5E route.
Wang Expires 27 February 2022 [Page 25]
Internet-Draft ET-ID Usage Update August 2021
* Using ET-ID to select BDI-Specific EADRs - In this case, the RT-1
per EVI routes corresponding to that RT-5E route are selected in
the context of a BD.
There may be multiple Ethernet A-D per EVI routes which all can
match the RT-5E's ESI. In such case, The Ethernet A-D per EVI
routes with the same ET-ID as the RT-5E should be selected.
Note that when the RT-5E's ET-ID is X (X!=0), the ET-IDs of the
selected Ethernet A-D per EVI routes (of that RT-5E) should be all
X.
Note that the RT-5E's ET-ID not only just be used to select
Ethernet A-D per EVI routes, but also be encapsulated into data
packets in order to keep compatible with ETI-specific Bump-in-the-
wire use case.
* Using AOI to select ETI-Specific EADRs - In this case, the RT-1
per EVI routes corresponding to that RT-5E route may (as required
by specific secenarios) be selected either in the context of a BD,
or in the context of the IP-VRF.
There may be multiple Ethernet A-D per EVI routes which all can
match the RT-5E's ESI. In such case, The Ethernet A-D per EVI
routes whose ET-ID are the same as the RT-5E's AOI should be
selected.
Note that when the RT-5E's AOI is Y (Y!=0), the ET-IDs of the
selected Ethernet A-D per EVI routes (of that RT-5E) should be all
Y.
Note that when the RT-5E's ET-ID is not 0, and an AOI is advertised
along with the RT-5E, the Ethernet A-D per EVI routes of that RT-5E
should be selected according to the AOI.
Note that when a data packet is load-balanced according to <ESI,
AOI>, in Bump-in-the-wire use case, it is the RT-5E's ET-ID which
should be encapsulated into the data packet, not the AOI.
Note that [I-D.sajassi-bess-evpn-ac-aware-bundling] requires the
Presence of Attachment Circuit ID Extended Community MUST be
ignored by non multihoming PEs. It requires the remote PE (non-
multihome PE, e.g. PE3) MUST process MAC route as defined in
[RFC7432]. But the AOI of this case should be used to select ETI-
Specific EADRs. This is non-compatible with the Attachment Circuit
Extended Community, thus the new ACI-Specific Overlay Index
Extended Community is defined.
Wang Expires 27 February 2022 [Page 26]
Internet-Draft ET-ID Usage Update August 2021
Note that the usage of RT-2R's AOI in the context of an IP-VRF should
be the same as the usage of RT-5E's AOI. but the RT-2R's non-zero
ET-ID (in the context of an IP-VRF) don't have to be encapsulated (as
VLAN-tag) into data packets in VXLAN EVPN. Note that the data
packets over an IP-NVO tunnel will be raw IP packets. In EVPN IRB
use case, the non-zero ET-ID of a RT-2R (when it is used in IP-VRF
context) is also not used to select the corresponding RT-1 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.
3.3. ACI-specific Overlay Index Extended Community
A new EVPN BGP Extended Community called Supplementary Overlay Index
is introduced. This new extended community is a transitive extended
community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD.
It is advertised along with EVPN MAC/IP Advertisement Route (Route
Type 2) per [RFC7432] in ACI-Sepecific Ethernet Auto-Discovery mode.
It may also be advertised along with EVPN Prefix Advertisement Route
(Route Type 5) as per [I-D.ietf-bess-evpn-prefix-advertisement].
Generically speaking, the new extended community must be attached to
any routes which are leant over an <ESI, EVI> of ACI-specific
Ethernet Auto-Discovery.
The Supplementary Overlay Index Extended Community is encoded as an
8-octet value as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=TBD | Type |O|Z|F=1| Flags | VLAN3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN3(Cont.) | VLAN2 | VLAN1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Supplementary Overlay Index Extended Community
o F: Format Indicator, its value is always 1 in this draft. Other
values are reserved.
o Type: .
* 0-1: VLAN-based AC-ID. Is VLAN2 an U-Tag?
= 1: VLAN2 is an U-Tag.
Note that when the ACI-Specific Overlay Index is used to
slect RT-1 per EVI routes, the U-Tags of the AOI should not
be used, because that the corresponding RT-1 per EVI
route's ET-ID will always be advertised following the
Type-0 AOI format. Thus a Type-1 AOI should be translated
Wang Expires 27 February 2022 [Page 27]
Internet-Draft ET-ID Usage Update August 2021
into a Type-0 AOI before it is used to select RT-1 per EVI
routes. When the U-Tags of a Type-1 AOI is set to zero, it
will change to the corresponding Type-0 AOI.
= 0: Neither VLAN1 nor VLAN2 is an U-Tag.
+=====+===========+========+=======+=======+========+
| No. | Use Cases | Type | VLAN2 | VLAN1 | VLAN3 |
+=====+===========+========+=======+=======+========+
| 1 | untag | type 0 | 0 | 0 | 0 |
+-----+-----------+--------+-------+-------+--------+
| 2 | default | type 0 | 0 | FFF | 0 |
+-----+-----------+--------+-------+-------+--------+
| 3 | dot1q | type 0 | 0 | E | 0 |
+-----+-----------+--------+-------+-------+--------+
| 4 | QinQ | type 0 | E | I | 0 |
+-----+-----------+--------+-------+-------+--------+
| 5 | dot1q | type 1 | U | E | 0 |
+-----+-----------+--------+-------+-------+--------+
| 6 | default | type 1 | U | FFF | 0 |
+-----+-----------+--------+-------+-------+--------+
| 7 | default | type 1 | U | FFF | U-Tag2 |
+-----+-----------+--------+-------+-------+--------+
Table 5: VLAN-based AOIs
Notes:
E : That field is the External VLAN of the AC.
I : That field is the Internal VLAN of the AC.
U : That field is a U-Tag of a packet received by the AC.
0 : The tag corresponding to that field is absent.
FFF : The AC is the default subinterface (Section 3.3) of the
corresponding ES.
untag : An untagged subinterface should be matched by that
format.
default : A default subinterface should be matched by that
format. When the AC is a default subinterface, it will
match all the remaining VLAN-tags (which are left over by
other subinterfaces) on its main-interface.
dot1q : A dot1q subinterface should be matched by that format.
QinQ : A QinQ subinterface should be matched by that format.
U-Tag2 : The Inner VLAN-Tag of the U-Tag which is
corresponding to VLAN2 field. It is only used for the
type-1 AOI of a main interface's default subinterface.
* 2-7: Reserved.
* 8-15: Reserved until all of 2-7 are used, or the first bit
should be used as a specail flag.
o O Flag: Overlay Index Flag, this extended community is used as
overlay index.
Wang Expires 27 February 2022 [Page 28]
Internet-Draft ET-ID Usage Update August 2021
When type field is 0-1: For ACI-Specific Ethernet auto-discovery
mode, when it is carried along with a RT-2 route, the O Flag should
be set to 1, For BDI-Specific Ethernet auto-discovery, when it is
carried along with a RT-2 route, the O Flag should be set to 0.
When the O Flag is set to 1, this AC-ID is also called as AOI (ACI-
Specific Overlay Index), and the <ESI, AOI> of that RT-2R or RT-5E
should be used to determine ECMP pathes. At the same time, the AOI
should also be used like Attachment Circuit ID Extended Community
too.
Note that only the lowest 8 bits of VLAN3 field should be used to
select RT-1 per EVI routes. <lowest 8 bits of VLAN3, VLAN2, VLAN1>
of a type-0 AOI forms an Ethernet Tag ID of an ACI-Specific EADR.
o Z Flag: Must be zero. Reserved for future use, the receiver
should ignore this extended coummunity if Z flag is not zero at
now.
o Flags: Reserved for future use. it is set to 0 on advertising, and
ignored on receiving.
Note that although this extended community is actually an extension
of the AC-ID extended community (as per
[I-D.sajassi-bess-evpn-ac-aware-bundling]), we can assume that they
may be of different Sub-Types because that they have different
behaviors.
3.4. ARP/ND Synching and IP Aliasing
3.4.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 L3EVI 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 Route-Distinguisher should be set to the corresponding L3EVI
context.
* The Ethernet Tag ID should be set to a value according to
Table 2's IP-ETI column.
* The ACI should be set to a value according to Table 2's IP-ACI
column.
Wang Expires 27 February 2022 [Page 29]
Internet-Draft ET-ID Usage Update August 2021
Note that the ACI may be encapsulated as Attachment Circuit ID
Extended Communinty or ACI Extended Community. If it is
encapsulated as ACI Extended Communinty, the <ESI, ACI> will be
used to select IP-AD/EVI routes by PE3, and the selected IP-AD/EVI
routes are used to determine the aliasing pathes of this RT-2
route. But if it is encapsualted as Attachment Circuit ID
Extended Community, PE3 will ignore it, and the aliasing pathes of
this RT-2 route will be determined by <ESI, ET-ID> as per
[RFC7432].
* 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].
In EVPN signalled L3VPN, The ESI SHOULD be set to the ESI of the
VRF interface from which the ARP entry is learnt.
Note that the <ESI,ACI> is used to install the synched ARP entries
to corresponding VRF interfaces on PE1/PE2. But on PE3, the
<ESI,ACI> is used to load balance traffics.
* The MAC/IP Advertisement SHOULD carry one or more IP VRF Route-
Target (RT) attributes.
* In EVPN Signalled L3VPN, the MPLS Label1 should be set to the same
pre-configured value for all local ARP entries. It is just used
to be compatible with existing RRs.
In EVPN IRB, the MPLS Label1 should follow
[I-D.ietf-bess-evpn-inter-subnet-forwarding].
* The MPLS Label2 should be set to the local label of the IP-VRF in
MPLS or VXLAN EVPN. But it should be set to implicit-null in SRv6
EVPN. This is the same as [I-D.sajassi-bess-evpn-ip-aliasing].
* The RMAC Extended Community attribute SHOULD be carried in VXLAN
EVPN. This follows [I-D.ietf-bess-evpn-inter-subnet-forwarding].
3.4.2. Constructing IP-AD/EVI Route
The usage/construction of this route is similar to the IP-AD 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 a value according to
Table 2's EADR-ETI column.
Wang Expires 27 February 2022 [Page 30]
Internet-Draft ET-ID Usage Update August 2021
3.5. Constructing IP Prefix Advertisement Route
When an IP Prefix Advertisement is advertised, The Ethernet Tag ID is
recommanded to be carried along with it, if it is not clear that
whether there will be conflictions among IP A-D per EVI routes in the
future.
Note that the Ethernet Tag ID here is not used to isolate IP address
spaces. It is just used to resolve its ESI overlay index to a proper
IP A-D per EVI route.
The AC-ID extended community can't be considered as a substitute of
the ET-ID. Because that the AC-ID is not the key of IP A-D per EVI
routes, but the ET-ID is.
Arguably, non-reserved Ethernet Tag ID in the RT-5 route, could be
assumed that it is already in
[I-D.ietf-bess-evpn-prefix-advertisement], because that when the
BD-10 of the Bump-in-the-wire use-case is of an EVI of VLAN-aware
bundl service interface, non-reserved ethernet tag ID will be carried
along with Ethernet A-D per EVI routes, hence non-reserved Ethernet
Tag ID should be carried along with IP Prefix Advertisement Routes
too. Otherwise those Ethernet A-D per EVI routes can not be referred
by these IP Prefix Advertisement Routes.
3.6. Secenario-Specific Procedures
3.6.1. EVPN-IRB Specific Procedures
PE1 may advertise two IP A-D per EVI routes for subinterface P1.1,
one (say R1_110b) is for BD-10, 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-5 Route for a prefix behind BD-10, the
Ethernet Tag ID of that RT-5 Route is determined by the out-interface
(P1.1) of the MAC of that prefix's overlay nexthop (10.0.0.2).
Note that R1_110b will not be imported into the IP-VRF.
PE1 may advertise two RT-2 routes for N1's MAC/IP, one (say R2_N1b)
is for BD-10, the other (that R2_N1) is for the IP-VRF. The Ethernet
Tag ID of R2_N1b is zero per [RFC7432], but the Ethernet Tag ID of
R2_N1 is set to the VLANs of P1.1 according to this draft.
Wang Expires 27 February 2022 [Page 31]
Internet-Draft ET-ID Usage Update August 2021
The MAC-VRFs and IP-VRFs in this solution will have their own copy of
EVPN routes, This issue can be improved using the mechanisms of
Section 3.6.2, if interoperation between VLAN-based service interface
and VLAN-aware service interface per
[I-D.ietf-bess-evpn-modes-interop] is provisioned in this network.
3.6.2. On Separated Risk VLAN-bundle of the same BD
PE1 will advertise different Ethernet A-D per EVI routes for P1.1 and
P1.2, the Ethernet Tag ID of them will be the VLANs of corresponding
AC (P1.1 or P1.2).
Note that the MAC/IPs on P1.1 and P1.2 will be advertised along with
such ET-IDs too.
When PE3 receives such Ethernet A-D per EVI routes and RT-2 routes,
it SHOULD process them following [I-D.ietf-bess-evpn-modes-interop]'s
section 3.1.2. As a result of that, although PE3 works in VLAN-based
or VLAN-baundle Service Interface, Such MAC/IPs will be istalled in
BD-100 and they will be resolved to those Ethernet A-D per EVI routes
under the help of such ET-IDs.
3.6.3. On Multiple VLAN-based ACs of the same BD
PE1 will advertise different Ethernet A-D per EVI routes for P1.1 and
P1.2, the Ethernet Tag ID of them will be the VLANs (10 or 20) of
corresponding AC (P1.1 or P1.2), not the normalized ET-ID (100).
Note that the MAC/IPs on P1.1 and P1.2 will not be advertised along
with such ET-IDs too, They will be advertised along with the
normalized ET-ID and the corresponding AC-ID extended community per
[I-D.sajassi-bess-evpn-ac-aware-bundling].
When PE3 receives these two Ethernet A-D per EVI routes, it installs
them separately. Whe PE3 receives the RT-2 route for N1's address,
that route carries the AC-ID 1 of P1.1, PE3 will resolve it to the
Ethernet A-D per EVI routes (in all-active mode) whose ET-ID are 1
(not the normalized ET-ID 100). Whe PE3 receives the RT-2 route for
N2's address, that route carries the AC-ID 2 of P1.2, PE3 will
resolve it to the Ethernet A-D per EVI routes (in all-active mode)
whose ET-ID are 2 (not the normalized ET-ID 100).
The ET-ID fields of Ethernet A-D per EVI routes follows Table 1's AC-
ETI column. The ET-ID fields of RT-2 routes follows Table 1's BD-ID
column. The AOI/AC-ID extended community follows Table 1's ACI-T
column.
Wang Expires 27 February 2022 [Page 32]
Internet-Draft ET-ID Usage Update August 2021
In this case, the ACI-specific EADRs can be used to do AC-influenced
DF-election procedures. Each VLAN of that ES may have individual DF-
election result.
3.6.4. Bump-in-the-wire Specific Procedures
TS2 NVE2
+--------------+ +---------------+
| | | |
SN7-----(N2-M4)__ | | __(BD-20) |
| \ | IF2 | / |
| =============== +-------+
| __/ | ESI23 | \__ | |
+----- (N1-M2) | + | (BD-10) | | DGW8
| | | | | | +---+-----+
| +--------------+ | +---------------+ | (SBD8) |
| | | | |
SN1 | | |IRB8 |
| TS3 | NVE3 | | |
| +--------------+ | +---------------+ |(IP-VRF)-+-+H8
| | | | | | +---+-----+
+------(N1-M3)__ | + | __(BD-10) | |
| \ | ESI23 | / | |
| =============== +-------+
| __/ | IF3 | \__ |
SN7-----(N2-M5) | | (BD-20) |
| | | |
+--------------+ +---------------+
Figure 11: SBD of Bump-in-the-wire
We can assume that maybe neither BD-10 nor BD-20 will be configured
on DGW8, as illustrated in Figure 11. In such case, we assume that a
SBD (Supplementary BD) can be provisoned on DGW1.
The SBD8 is similar to the SBD of section 4.4.3 of
[I-D.ietf-bess-evpn-prefix-advertisement], except for the following
factors:
The SBD8 will import all the RT-5E routes and the RT-1 routes
which are advertised for BD-10 and BD-20 (and other such BDs of
Bump-in-the-wire use cases) by the NVEs of that DC, But the SBD8
don't import other EVPN routes. and it don't have to advertise
any EVPN routes (e.g. IMET route) because there are no hosts
(even the IP address of IRB8 will not be provisoned in this case)
in the SBD.
Wang Expires 27 February 2022 [Page 33]
Internet-Draft ET-ID Usage Update August 2021
Note that DGW3 will advertise the IP prefixes of the IP-VRF using its
own EVPN label and route-targets. It don't have to expect any data
packets to be received from such SBD.
The route advertisement behavior of NVE2 and NVE3 should also be
changed:
* ACI-specific ethernet auto-discovery mode should be used when NVEs
advertise the RT-1 routes of Bump-in-the-wire use case. Otherwise
the RT-1 routes from BD-10 and BD-20 will conflict with each
other, because that both BD-10 and BD-20 are of VLAN-based
Servcice Interface.
* ACI-specific Overlay Index extended community should be advertised
along with the RT-5E routes. Thus the ET-ID of these RT-5E routes
can be set to zero because that BD-10 and BD-20 are ETI-agnostic
BDs.
Note that the combination of <ESI, AOI> will be used to select the
corresponding RT-1 per EVI routes for these RT-5E routes by SBDs
of other PEs.
The RT-5E routes (for the CE-prefixes behind each BD) should be
advertised follows Table 2. Note that the IP-ETI, EADR-ETI and
IP-ACI should be determined by the outgoing AC per each CE-
prefix's VA MAC. The IP-ETI is set to the BD-ID of that outgoing
AC's BD. Given that <AC, BD> is ACI-Specific EAD mode, the IP-ACI
is the AOI extended comunity for that <AC, BD>, and the EADR-ETI
is the same value as the IP-ACI.
* The MAC addresses of IRB interfaces of each BD (e.g. BD-10 and
BD-20) should be the same as the SBD IRB interfaces of the same L3
EVI, otherwise the source MAC may be not expected to be learnt by
the CE-side L2 switches.
Note that although the NVEs of the original Bump-in-the-wire don't
have an IP-VRF instance, it will be no difficult for the RT5E_SN1
and RT1_ESI23 are used when there is an IP-VRF (where SN9 is
learnt by a CE-BGP session) and IRBs on each of the NVEs. In such
case, maybe it will be better for the NVEs to advertise its IRB
(e.g. BD-10's IRB) MAC along with RT1_ESI23 (which is for BD-10)
in order to indicate DGW8 to encapsulate that MAC as source MAC.
By doing so, there will be no need for SBDs, thus the RT-5E routes
and RT-1 per EVI routes can be advertised and imported using the
IP-VRF's route-targets. The RT-1 per EVI routes (whose MPLS label
identifies that BD) can be advertised along with both BD's RT and
IP-VRF's RT. thus the amount of RT-1 per EVI routes will not be
increased.
Wang Expires 27 February 2022 [Page 34]
Internet-Draft ET-ID Usage Update August 2021
Note that in Bump-in-the-wire use cases, the EVPN label that is
encapsulated by DGW1/DGW3 for NVE2 or NVE2 will be a label that
identifies a L2 EVI. So when the BD is an ETI-Specific BD, the IP-
ETI MUST be encapsulated into the ethernet header of the data
packets. Otherwise such data packets won't be received by that BD.
Note that in Bump-in-the-wire use cases, even if the BD is a MPLS
EVPN BD, PE3 should send data packets to NVE2/NVE3 along with the
overlay ethernet header (whose SA is the SBD IRB's MAC address),
because the Bump-in-the-wire use case is actually a special EVPN IRB
use case. Otherwise NVE2/NVE3 can't decapsulate the data packets
properly.
Note that in such case, the RT-5E routes technically can be directly
imported into the IP-VRF identified by its route-target. only if
there would be no more than one SBD in a specified IP-VRF. In
original Bump-in-the-wire use-case, if there would be no more than
one BD in a specified IP-VRF, the the RT-5E routes technically can be
directly imported into the IP-VRF identified by its route-target
(which is determined by policy, because a RT-5E route itself will be
learnt by policy too, according to
[I-D.ietf-bess-evpn-prefix-advertisement]). For backward
comptibility with such implementations, the ET-ID (if it is not zero)
of these RT-5E routes may be used to selected RT-1 per EVI routes
from the only BD of that IP-VRF, and in such case it should be
encapsulated into the ethernet header (in VXLAN EVPN) of the
corresponding data packets, because that the RT-1 per EVI routes of
Bump-in-the-wire use case are advertised for BD-10, and BD-10 may use
VLAN-aware bundle service interface according to
[I-D.ietf-bess-evpn-prefix-advertisement].
The ESIs of these RT-5E routes are used to selecte RT-1 per EVI
routes in the context of a BD, as described in
[I-D.ietf-bess-evpn-prefix-advertisement]. When the ESIs of RT-5E
routes are used to selected RT-1 per EVI routes in the context of an
IP-VRF, it seems that this is not explicitly described in
[I-D.ietf-bess-evpn-prefix-advertisement].
3.6.5. ARP/ND Probing Specific Procedures
When PE1 synchs the ARP/ND entry of H21a to PE2, The AOI extended
community is carried along with the RT-2 route for H21a. The AOI
extended community is constructed in the following format:
The Type-1 AOI is used, the VLAN1 field is the VLAN ID of
subinterface P1.1 (see Figure 9), and the VLAN2 field is the
C-VLAN (that's C-VLAN 31) against which that ARP/ND entry is
learnt on P1.1.
Wang Expires 27 February 2022 [Page 35]
Internet-Draft ET-ID Usage Update August 2021
When PE2 receives the RT-2 route of H21a, it don't use the VLAN2
field to install the MAC/ARP/ND entry, because that VLAN2 field is a
U-Tag, which would not have been configured on subinterface P2.1.
PE2 use VLAN1 field to install the MAC/ARP/ND entry on P2.1, but
VLAN2 field as an U-Tag are also recorded into the ARP/ND entry.
When PE2 decide to trigger the ARP/ND Probing for H21a, the ARP/ND
request should be sent over P2.1 along with VLAN2 field as its inner
VLAN-tag (the outer VLAN-tag will be VLAN1 field).
Note that it is not necessary for an U-Tag to be recorded in any MAC
entries.
4. IANA Considerations
A new transitive extended community Type of 0x06 and Sub-Type of TBD
for EVPN Supplementary Overlay Index Extended Community needs to be
allocated by IANA.
5. Security Considerations
TBD.
6. References
6.1. Normative References
[I-D.ietf-bess-evpn-modes-interop]
Krattiger, L., Sajassi, A., Thoria, S., Rabadan, J., and
J. 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>.
[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-07, 11 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
srv6-services-07>.
Wang Expires 27 February 2022 [Page 36]
Internet-Draft ET-ID Usage Update August 2021
[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-02, 8 June
2021, <https://datatracker.ietf.org/doc/html/draft-
sajassi-bess-evpn-ip-aliasing-02>.
[I-D.sajassi-bess-evpn-ac-aware-bundling]
Sajassi, A., Brissette, P., Mishra, M. P., 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.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-prefix-
advertisement-11, 18 May 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-prefix-advertisement-11>.
[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", Work
in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-
subnet-forwarding-15, 26 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-inter-subnet-forwarding-15>.
[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>.
6.2. Informative References
[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 Expires 27 February 2022 [Page 37]
Internet-Draft ET-ID Usage Update August 2021
wang-bess-evpn-arp-nd-synch-without-irb-07, 9 August 2021,
<https://datatracker.ietf.org/doc/html/draft-wang-bess-
evpn-arp-nd-synch-without-irb-07>.
[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-01, 28 July 2021,
<https://datatracker.ietf.org/doc/html/draft-wz-bess-evpn-
vpws-as-vrf-ac-01>.
Appendix A. Explanation for Physical Links of the Use-cases
+------------------+
PE1 | P6 |
L2NE1 +----------+---------+ |
+----------+ | __(P1.1)__(VPNx) | |
+---+ P4 | | P1 | / \ | |
|N1 |-----O==------=======< (NIz) | P6 | PE3
+---+ | \ / | | \__ __ / | +----+-------+
| | | | | (P1.2) (VPNy) | | |
+----|P3|--+ +-----------+--------+ | (VPNx)--+N3
| | | | / |
P3.1 | | P3.2 | P7 | (NIz)--------+N4
| | PE2 | | \ |
+----|P3|--+ +-----------+--------+ | (VPNy)--+N5
| \/ | | __(P2.2)__(VPNy) | | |
+---+ | /\ | | / \ | +----+-------+
|N2 |-----O====--=========< (NIz) | P8 |
+---+ P5 | | P2 | \__ __ / | |
+----------+ | (P2.1) (VPNx) | |
L2NE2 +----------+---------+ |
| P8 |
+------------------+
Figure 12: Physical Links Illustrated
There are three PEs, two L2NEs (Layer 2 Network Elements) and five
L3NEs (Layer 3 Network Elements) in abobe network. The PEs are PE1,
PE2 and PE3. The L2NEs are L2NE1 and L2NE2. The L3NEs are
N1/N2/N3/N4/N5. They are all illustrated in Figure 12.
There are 9 physical links among these 10 physical devices as
illustrated in Figure 12. These physical links are called as PLi
(i=1,2...8). The two physical ports of the same physical link PLi
are both called as Pi (i=1,2...8).
Wang Expires 27 February 2022 [Page 38]
Internet-Draft ET-ID Usage Update August 2021
As illustrated in Figure 12, some of these physical ports may have
subinterfaces. When a subinterface's VLAN ID is j and it is physical
port Pi's subinterface, that subinterface is called as Pi.j. For
example, P1.2 is a subinterface of physical port P1 and its VLAN ID
is 2.
There are three NIs (Network Instances) among PE1, PE2 and PE3. They
are VPNx, VPNy and NIz. Two subinterfaces are attached to VPNx, they
are P1.1 and P2.1. Other two subinterfaces are attached to VPNy,
they are P1.2 and P2.2. N3 is also attched to VPNx, while N5 is also
attached to VPNy.
There are two EVCs (Ethernet Virtual Connections) between L2NE1 and
L2NE2, they are EVC1 and EVC2. The L2NE1's EVC1 instance (which is
illustrated as the "O" on L2NE1) have three member interfaces, they
are P4, P1.1 and P3.1, where P3.1 and P1.1 are of the same
protection-group. The L2NE2's EVC1 instance have two member
interfaces, they are P3.1 and P2.1. The L2NE2's EVC2 instance (which
is illustrated as the "O" on L2NE2) have three member interfaces,
they are P5, P2.2 and P3.2, where P3.1 and P1.1 are of the same
protection-group. The L2NE1's EVC2 instance have two member
interfaces, they are P3.2 and P1.2. The L2NE2's EVC1 instance and
L2NE1's EVC2 instance are both CCC (Circuit Cross Connection) local
connections.
VPNx and VPNy are associated to NIz on each PE.
A.1. Failure Detections for P1.2 (or P2.1)
There is a CFM session CFM1 between P1.2 of PE1 and L2NE2's P3.2,
when physical port P3 fails, the CFM session CFM1 will go down.
There is a CFM session CFM2 between P2.1 of PE2 and L2NE1's P3.1,
when physical port P3 fails, the CFM session CFM2 will go down.
A.2. Protection Approaches for N1 (or N2)
A.2.1. CCC-Approaches
The L2NE1's EVC2 instance and L2NE2's EVC1 instance are both CCC
local connections too. In L2NE1's EVC1 instance, P1.1 and P3.1 are
of the same protection-group PG1. In L2NE2's EVC2 instance, P2.2 and
P3.2 are of the same protection-group PG2. In PG1, both P1.1 and
P3.1 will receive data packets. In PG2, both P2.2 and P3.2 will
receive data packets.
Wang Expires 27 February 2022 [Page 39]
Internet-Draft ET-ID Usage Update August 2021
A.2.1.1. CCC Active-Active Protection
L2NE1 (or L2NE2) will load-balance N1's (N2's) data packets between
P1.1 and P3.1 (or P2.2 and P3.2).
A.2.1.2. CCC Active-Standby Protection
In PG1, P1.1 is the active path, P3.1 is the backup path. In PG2,
P2.2 is the active path, P3.2 is the backup path.
That's saying that L2NE1 (or L2NE2) will not send N1's (or N2's) data
packets over P3.1 (or P3.2), unless P1.1 (or P2.2) or P1 (or P2) has
been in failure before that data forwarding.
A.2.2. VSI-Approaches
L2NE1's EVC2 instance and L2NE2's EVC1 instance are both VSI
instances in this case. P1.1, P3.1, P2.2 and P3.2 are all individual
ACs in these VSIs.
Note that L2NE2's EVC1 instance and L2NE1's EVC2 instance are still
both CCC local connections in this case, and there is no PG1 or PG2
in this case, and there are no PWs in this case.
Author's Address
Yubao Wang
ZTE Corporation
No.68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Wang Expires 27 February 2022 [Page 40]
