rfc9014v2.txt   rfc9014.txt 
skipping to change at line 24 skipping to change at line 24
Abstract Abstract
This document describes how Network Virtualization Overlays (NVOs) This document describes how Network Virtualization Overlays (NVOs)
can be connected to a Wide Area Network (WAN) in order to extend the can be connected to a Wide Area Network (WAN) in order to extend the
Layer 2 connectivity required for some tenants. The solution Layer 2 connectivity required for some tenants. The solution
analyzes the interaction between NVO networks running Ethernet analyzes the interaction between NVO networks running Ethernet
Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN)
technologies used in the WAN, such as Virtual Private LAN Services technologies used in the WAN, such as Virtual Private LAN Services
(VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),
EVPN, or PBB-EVPN. It also describes how the existing technical EVPN, or PBB-EVPN. It also describes how the existing technical
specifications apply to the Interconnection and extends the EVPN specifications apply to the interconnection and extends the EVPN
procedures needed in some cases. In particular, this document procedures needed in some cases. In particular, this document
describes how EVPN routes are processed on Gateways (GWs) that describes how EVPN routes are processed on Gateways (GWs) that
interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the
Interconnect Ethernet Segment (I-ES), to provide multihoming. This Interconnect Ethernet Segment (I-ES), to provide multihoming. This
document also describes the use of the Unknown MAC Route (UMR) to document also describes the use of the Unknown MAC Route (UMR) to
avoid issues of a Media Access Control (MAC) scale on Data Center avoid issues of a Media Access Control (MAC) scale on Data Center
Network Virtualization Edge (NVE) devices. Network Virtualization Edge (NVE) devices.
Status of This Memo Status of This Memo
skipping to change at line 130 skipping to change at line 130
[RFC4761] [RFC4762], VPLS extensions for Provider Backbone Bridging [RFC4761] [RFC4762], VPLS extensions for Provider Backbone Bridging
(PBB-VPLS) [RFC7041], EVPN [RFC7432], or PBB-EVPN [RFC7623] network (PBB-VPLS) [RFC7041], EVPN [RFC7432], or PBB-EVPN [RFC7623] network
that has to be used to interconnect Data Centers and WAN VPN users. that has to be used to interconnect Data Centers and WAN VPN users.
A Gateway (GW) function is required in these cases. In fact, A Gateway (GW) function is required in these cases. In fact,
[RFC8365] discusses two main Data Center Interconnect (DCI) solution [RFC8365] discusses two main Data Center Interconnect (DCI) solution
groups: "DCI using GWs" and "DCI using ASBRs". This document groups: "DCI using GWs" and "DCI using ASBRs". This document
specifies the solutions that correspond to the "DCI using GWs" group. specifies the solutions that correspond to the "DCI using GWs" group.
It is assumed that the NVO GW and the WAN Edge functions can be It is assumed that the NVO GW and the WAN Edge functions can be
decoupled into two separate systems or integrated into the same decoupled into two separate systems or integrated into the same
system. The former option will be referred to as "Decoupled system. The former option will be referred to as "decoupled
Interconnect solution" throughout the document, whereas the latter interconnect solution" throughout the document, whereas the latter
one will be referred to as "Integrated Interconnect solution". one will be referred to as "integrated interconnect solution".
The specified procedures are local to the redundant GWs connecting a The specified procedures are local to the redundant GWs connecting a
DC to the WAN. The document does not preclude any combination across DC to the WAN. The document does not preclude any combination across
different DCs for the same tenant. For instance, a "Decoupled" different DCs for the same tenant. For instance, a "Decoupled"
solution can be used in GW1 and GW2 (for DC1), and an "Integrated" solution can be used in GW1 and GW2 (for DC1), and an "Integrated"
solution can be used in GW3 and GW4 (for DC2). solution can be used in GW3 and GW4 (for DC2).
While the Gateways and WAN Provider Edges (PEs) use existing While the Gateways and WAN Provider Edges (PEs) use existing
specifications in some cases, the document also defines extensions specifications in some cases, the document also defines extensions
that are specific to DCI. In particular, those extensions are: that are specific to DCI. In particular, those extensions are:
skipping to change at line 250 skipping to change at line 250
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers VNI/VSID: refers to VXLAN/NVGRE virtual identifiers
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
VSI: Virtual Switch Instance or VPLS instance in a particular PE VSI: Virtual Switch Instance or VPLS instance in a particular PE
VXLAN: Virtual eXtensible LAN VXLAN: Virtual eXtensible LAN
3. Decoupled Interconnect Solution for EVPN-Overlay Networks 3. Decoupled Interconnect Solution for EVPN-Overlay Networks
This section describes the Interconnect solution when the GW and WAN This section describes the interconnect solution when the GW and WAN
Edge functions are implemented in different systems. Figure 1 Edge functions are implemented in different systems. Figure 1
depicts the reference model described in this section. Note that, depicts the reference model described in this section. Note that,
although not shown in Figure 1, GWs may have local Attachment although not shown in Figure 1, GWs may have local Attachment
Circuits (ACs). Circuits (ACs).
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
skipping to change at line 285 skipping to change at line 285
|<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->|
handoff handoff handoff handoff
Figure 1: Decoupled Interconnect Model Figure 1: Decoupled Interconnect Model
The following section describes the interconnect requirements for The following section describes the interconnect requirements for
this model. this model.
3.1. Interconnect Requirements 3.1. Interconnect Requirements
The Decoupled Interconnect architecture is intended to be deployed in The decoupled interconnect architecture is intended to be deployed in
networks where the EVPN-Overlay and WAN providers are different networks where the EVPN-Overlay and WAN providers are different
entities and a clear demarcation is needed. This solution solves the entities and a clear demarcation is needed. This solution solves the
following requirements: following requirements:
* A simple connectivity handoff between the EVPN-Overlay network * A simple connectivity handoff between the EVPN-Overlay network
provider and the WAN provider so that QoS and security enforcement provider and the WAN provider so that QoS and security enforcement
are easily accomplished. are easily accomplished.
* Independence of the L2VPN technology deployed in the WAN. * Independence of the L2VPN technology deployed in the WAN.
skipping to change at line 336 skipping to change at line 336
between both providers. The disadvantage of this model is the between both providers. The disadvantage of this model is the
provisioning overhead, since the service has to be mapped to a C-TAG provisioning overhead, since the service has to be mapped to a C-TAG
or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. or S/C-TAG VLAN ID combination at both GW and WAN Edge routers.
In this model, the GW acts as a regular Network Virtualization Edge In this model, the GW acts as a regular Network Virtualization Edge
(NVE) towards the DC. Its control plane, data plane procedures, and (NVE) towards the DC. Its control plane, data plane procedures, and
interactions are described in [RFC8365]. interactions are described in [RFC8365].
The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with
Attachment Circuits (ACs) to the GWs. Its functions are described in Attachment Circuits (ACs) to the GWs. Its functions are described in
[RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623]. [RFC4761], [RFC4762], [RFC6074], [RFC7432], and [RFC7623].
3.3. PW-Based Handoff 3.3. PW-Based Handoff
If MPLS between the GW and the WAN Edge router is an option, a PW- If MPLS between the GW and the WAN Edge router is an option, a PW-
based Interconnect solution can be deployed. In this option, the based interconnect solution can be deployed. In this option, the
handoff between both routers is based on FEC128-based PWs [RFC4762] handoff between both routers is based on FEC128-based PWs [RFC4762]
or FEC129-based PWs (for a greater level of network automation) or FEC129-based PWs (for a greater level of network automation)
[RFC6074]. Note that this model still provides a clear demarcation [RFC6074]. Note that this model still provides a clear demarcation
between DC and WAN (since there is a single PW between each MAC-VRF between DC and WAN (since there is a single PW between each MAC-VRF
and peer VSI), and security/QoS policies may be applied on a per-PW and peer VSI), and security/QoS policies may be applied on a per-PW
basis. This model provides better scalability than a C-TAG-based basis. This model provides better scalability than a C-TAG-based
handoff and less provisioning overhead than a combined C/S-TAG handoff and less provisioning overhead than a combined C/S-TAG
handoff. The PW-based handoff interconnect is illustrated in handoff. The PW-based handoff interconnect is illustrated in
Figure 1 (between the NVO-2 GWs and the WAN Edge routers). Figure 1 (between the NVO-2 GWs and the WAN Edge routers).
skipping to change at line 377 skipping to change at line 377
the EVPN instance) uses a combination of a PW label and VLAN IDs. the EVPN instance) uses a combination of a PW label and VLAN IDs.
PWs are treated as service interfaces, defined in [RFC7432]. PWs are treated as service interfaces, defined in [RFC7432].
3.4. Multihoming Solution on the GWs 3.4. Multihoming Solution on the GWs
EVPN single-active multihoming -- i.e., per-service load-balancing EVPN single-active multihoming -- i.e., per-service load-balancing
multihoming -- is required in this type of interconnect. multihoming -- is required in this type of interconnect.
The GWs will be provisioned with a unique ES for each WAN The GWs will be provisioned with a unique ES for each WAN
interconnect, and the handoff attachment circuits or PWs between the interconnect, and the handoff attachment circuits or PWs between the
GW and the WAN Edge router will be assigned an ESI for such ES. The GW and the WAN Edge router will be assigned an ESI for each such ES.
ESI will be administratively configured on the GWs according to the The ESI will be administratively configured on the GWs according to
procedures in [RFC7432]. This Interconnect ES will be referred to as the procedures in [RFC7432]. This I-ES will be referred to as "I-ES"
"I-ES" hereafter, and its identifier will be referred to as "I-ESI". hereafter, and its identifier will be referred to as "I-ESI".
Different ESI types are described in [RFC7432]. The use of Type 0 Different ESI types are described in [RFC7432]. The use of Type 0
for the I-ESI is RECOMMENDED in this document. for the I-ESI is RECOMMENDED in this document.
The solution (on the GWs) MUST follow the single-active multihoming The solution (on the GWs) MUST follow the single-active multihoming
procedures as described in [RFC8365] for the provisioned I-ESI -- procedures as described in [RFC8365] for the provisioned I-ESI --
i.e., Ethernet A-D routes per ES and per EVI will be advertised to i.e., Ethernet A-D routes per ES and per EVI will be advertised to
the DC NVEs for the multihoming functions, and ES routes will be the DC NVEs for the multihoming functions, and ES routes will be
advertised so that ES discovery and Designated Forwarder (DF) advertised so that ES discovery and Designated Forwarder (DF)
procedures can be followed. The MAC addresses learned (in the data procedures can be followed. The MAC addresses learned (in the data
plane) on the handoff links will be advertised with the I-ESI encoded plane) on the handoff links will be advertised with the I-ESI encoded
skipping to change at line 465 skipping to change at line 465
3.5.3. Handling Failures between GW and WAN Edge Routers 3.5.3. Handling Failures between GW and WAN Edge Routers
Link/PE failures are handled on the GWs as specified in [RFC7432]. Link/PE failures are handled on the GWs as specified in [RFC7432].
The GW detecting the failure will withdraw the EVPN routes, as per The GW detecting the failure will withdraw the EVPN routes, as per
[RFC7432]. [RFC7432].
Individual AC/PW failures may be detected by OAM mechanisms. For Individual AC/PW failures may be detected by OAM mechanisms. For
instance: instance:
* If the Interconnect solution is based on a VLAN handoff, Ethernet- * If the interconnect solution is based on a VLAN handoff, Ethernet-
CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC
failures on both the GW and WAN Edge router. An individual AC failures on both the GW and WAN Edge router. An individual AC
failure will trigger the withdrawal of the corresponding A-D per failure will trigger the withdrawal of the corresponding A-D per
EVI route as well as the MACs learned on that AC. EVI route as well as the MACs learned on that AC.
* If the Interconnect solution is based on a PW handoff, the Label * If the interconnect solution is based on a PW handoff, the Label
Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be
used to detect individual PW failures on both the GW and WAN Edge used to detect individual PW failures on both the GW and WAN Edge
router. router.
4. Integrated Interconnect Solution for EVPN-Overlay Networks 4. Integrated Interconnect Solution for EVPN-Overlay Networks
When the DC and the WAN are operated by the same administrative When the DC and the WAN are operated by the same administrative
entity, the Service Provider can decide to integrate the GW and WAN entity, the Service Provider can decide to integrate the GW and WAN
Edge PE functions in the same router for obvious reasons to save as Edge PE functions in the same router for obvious reasons to save as
relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX). relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX).
skipping to change at line 511 skipping to change at line 511
|NVE2|--| +---+ +---+ |--|NVE4| |NVE2|--| +---+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+ +----+ +---------+ | | +---------+ +----+
+--------------+ +--------------+
|<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->|
|<--PBB-VPLS-->| |<--PBB-VPLS-->|
Interconnect -> |<-EVPN-MPLS-->| Interconnect -> |<-EVPN-MPLS-->|
options |<--EVPN-Ovl-->|* options |<--EVPN-Ovl-->|*
|<--PBB-EVPN-->| |<--PBB-EVPN-->|
* EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). * EVPN-Ovl stands for EVPN-Overlay (and it's an interconnect option).
Figure 2: Integrated Interconnect Model Figure 2: Integrated Interconnect Model
4.1. Interconnect Requirements 4.1. Interconnect Requirements
The Integrated Interconnect solution meets the following The integrated interconnect solution meets the following
requirements: requirements:
* Control plane and data plane interworking between the EVPN-Overlay * Control plane and data plane interworking between the EVPN-Overlay
network and the L2VPN technology supported in the WAN, network and the L2VPN technology supported in the WAN,
irrespective of the technology choice -- i.e., (PBB-)VPLS or irrespective of the technology choice -- i.e., (PBB-)VPLS or
(PBB-)EVPN, as depicted in Figure 2. (PBB-)EVPN, as depicted in Figure 2.
* Multihoming, including single-active multihoming with per-service * Multihoming, including single-active multihoming with per-service
load balancing or all-active multihoming -- i.e., per-flow load- load balancing or all-active multihoming -- i.e., per-flow load-
balancing -- as long as the technology deployed in the WAN balancing -- as long as the technology deployed in the WAN
skipping to change at line 616 skipping to change at line 616
4.3.1. Control/Data Plane Setup Procedures on the GWs 4.3.1. Control/Data Plane Setup Procedures on the GWs
In this case, there is no impact on the procedures described in In this case, there is no impact on the procedures described in
[RFC7041] for the B-component. However, the I-component instances [RFC7041] for the B-component. However, the I-component instances
become EVI instances with EVPN-Overlay bindings and potentially local become EVI instances with EVPN-Overlay bindings and potentially local
attachment circuits. A number of MAC-VRF instances can be attachment circuits. A number of MAC-VRF instances can be
multiplexed into the same B-component instance. This option provides multiplexed into the same B-component instance. This option provides
significant savings in terms of PWs to be maintained in the WAN. significant savings in terms of PWs to be maintained in the WAN.
The I-ESI concept described in Section 4.2.1 will also be used for The I-ESI concept described in Section 4.2.1 will also be used for
the PBB-VPLS-based Interconnect. the PBB-VPLS-based interconnect.
B-component PWs and I-component EVPN-Overlay bindings established to B-component PWs and I-component EVPN-Overlay bindings established to
the same far end will be compared. The following rules will be the same far end will be compared. The following rules will be
observed: observed:
* Attempts to set up a PW between the two GWs within the B-component * Attempts to set up a PW between the two GWs within the B-component
context will never be blocked. context will never be blocked.
* If a PW exists between two GWs for the B-component and an attempt * If a PW exists between two GWs for the B-component and an attempt
is made to set up an EVPN binding on an I-component linked to that is made to set up an EVPN binding on an I-component linked to that
B-component, the EVPN binding will be kept down operationally. B-component, the EVPN binding will be kept down operationally.
Note that the BGP EVPN routes will still be valid but not used. Note that the BGP EVPN routes will still be valid but not used.
* The EVPN binding will only be up and used as long as there is no * The EVPN binding will only be up and used as long as there is no
PW to the same far end in the corresponding B-component. The EVPN PW to the same far end in the corresponding B-component. The EVPN
bindings in the I-components will be brought down before the PW in bindings in the I-components will be brought down before the PW in
the B-component is brought up. the B-component is brought up.
The optimization procedures described in Section 3.5 can also be The optimization procedures described in Section 3.5 can also be
applied to this Interconnect option. applied to this interconnect option.
4.3.2. Multihoming Procedures on the GWs 4.3.2. Multihoming Procedures on the GWs
This model supports single-active multihoming on the GWs. All-active This model supports single-active multihoming on the GWs. All-active
multihoming is not supported by this scenario. multihoming is not supported by this scenario.
The single-active multihoming procedures as described by [RFC8365] The single-active multihoming procedures as described by [RFC8365]
will be followed for the I-ES for each EVI instance connected to the will be followed for the I-ES for each EVI instance connected to the
B-component. Note that in this case, for a given EVI, all the EVPN B-component. Note that in this case, for a given EVI, all the EVPN
bindings in the I-component are assigned to the I-ES. The non-DF GW bindings in the I-component are assigned to the I-ES. The non-DF GW
skipping to change at line 731 skipping to change at line 731
Ethernet-Tag values. Ethernet-Tag values.
* Inclusive Multicast routes with independent tunnel-type value for * Inclusive Multicast routes with independent tunnel-type value for
the WAN and DC. For example, a P2MP Label Switched Path (LSP) may the WAN and DC. For example, a P2MP Label Switched Path (LSP) may
be used in the WAN, whereas ingress replication may be used in the be used in the WAN, whereas ingress replication may be used in the
DC. The routes sent to the WAN and the DC will have a consistent DC. The routes sent to the WAN and the DC will have a consistent
Ethernet-Tag. Ethernet-Tag.
* MAC/IP advertisement routes for MAC addresses learned in local * MAC/IP advertisement routes for MAC addresses learned in local
attachment circuits. Note that these routes will not include the attachment circuits. Note that these routes will not include the
I-ESI, but ESI=0 or different from 0 for local multihomed Ethernet I-ESI value in the ESI field. These routes will include a zero
Segments (ES). The routes sent to the WAN and the DC will have a ESI or a non-zero ESI for local multihomed Ethernet Segments (ES).
consistent Ethernet-Tag. The routes sent to the WAN and the DC will have a consistent
Ethernet-Tag.
Assuming GW1 and GW2 are peer GWs of the same DC, each GW will Assuming GW1 and GW2 are peer GWs of the same DC, each GW will
generate two sets of the above local service routes: set-DC will be generate two sets of the above local service routes: set-DC will be
sent to the DC RRs and will include an A-D per EVI, Inclusive sent to the DC RRs and will include an A-D per EVI, Inclusive
Multicast, and MAC/IP routes for the DC encapsulation and RT. Set- Multicast, and MAC/IP routes for the DC encapsulation and RT. Set-
WAN will be sent to the WAN RRs and will include the same routes but WAN will be sent to the WAN RRs and will include the same routes but
using the WAN RT and encapsulation. GW1 and GW2 will receive each using the WAN RT and encapsulation. GW1 and GW2 will receive each
other's set-DC and set-WAN. This is the expected behavior on GW1 and other's set-DC and set-WAN. This is the expected behavior on GW1 and
GW2 for locally generated routes: GW2 for locally generated routes:
skipping to change at line 913 skipping to change at line 914
MAC Mobility event. Only when the MAC moves from the WAN domain to MAC Mobility event. Only when the MAC moves from the WAN domain to
the DC domain (or from one DC to another) will the MAC be learned the DC domain (or from one DC to another) will the MAC be learned
from a different ES, and the MAC Mobility procedures will kick in. from a different ES, and the MAC Mobility procedures will kick in.
The sticky-bit indication in the MAC Mobility extended community MUST The sticky-bit indication in the MAC Mobility extended community MUST
be propagated between domains. be propagated between domains.
4.4.5. Gateway Optimizations 4.4.5. Gateway Optimizations
All the Gateway optimizations described in Section 3.5 MAY be applied All the Gateway optimizations described in Section 3.5 MAY be applied
to the GWs when the Interconnect is based on EVPN-MPLS. to the GWs when the interconnect is based on EVPN-MPLS.
In particular, the use of the Unknown MAC Route, as described in In particular, the use of the Unknown MAC Route, as described in
Section 3.5.1, solves some transient packet-duplication issues in Section 3.5.1, solves some transient packet-duplication issues in
cases of all-active multihoming, as explained below. cases of all-active multihoming, as explained below.
Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- Consider the diagram in Figure 2 for EVPN-MPLS interconnect and all-
active multihoming, and the following sequence: active multihoming, and the following sequence:
(a) MAC Address M1 is advertised from NVE3 in EVI-1. (a) MAC Address M1 is advertised from NVE3 in EVI-1.
(b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN (b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN
with I-ESI-2 in the ESI field. with I-ESI-2 in the ESI field.
(c) GW1 and GW2 learn M1 and install GW3/GW4 as next hops following (c) GW1 and GW2 learn M1 and install GW3/GW4 as next hops following
the EVPN aliasing procedures. the EVPN aliasing procedures.
skipping to change at line 947 skipping to change at line 948
packet duplication. However, because the Unknown MAC Route had packet duplication. However, because the Unknown MAC Route had
been advertised into the DC, NVE1 will unicast the packet to been advertised into the DC, NVE1 will unicast the packet to
either GW1 or GW2. either GW1 or GW2.
(e) Since both GW1 and GW2 know M1, the GW receiving the packet will (e) Since both GW1 and GW2 know M1, the GW receiving the packet will
forward it to either GW3 or GW4. forward it to either GW3 or GW4.
4.4.6. Benefits of the EVPN-MPLS Interconnect Solution 4.4.6. Benefits of the EVPN-MPLS Interconnect Solution
The "DCI using ASBRs" solution described in [RFC8365] and the GW The "DCI using ASBRs" solution described in [RFC8365] and the GW
solution with EVPN-MPLS Interconnect may be seen as similar, since solution with EVPN-MPLS interconnect may be seen as similar, since
they both retain the EVPN attributes between Data Centers and they both retain the EVPN attributes between Data Centers and
throughout the WAN. However, the EVPN-MPLS Interconnect solution on throughout the WAN. However, the EVPN-MPLS interconnect solution on
the GWs has significant benefits compared to the "DCI using ASBRs" the GWs has significant benefits compared to the "DCI using ASBRs"
solution: solution:
* As in any of the described GW models, this solution supports the * As in any of the described GW models, this solution supports the
connectivity of local attachment circuits on the GWs. This is not connectivity of local attachment circuits on the GWs. This is not
possible in a "DCI using ASBRs" solution. possible in a "DCI using ASBRs" solution.
* Different data plane encapsulations can be supported in the DC and * Different data plane encapsulations can be supported in the DC and
the WAN, while a uniform encapsulation is needed in the "DCI using the WAN, while a uniform encapsulation is needed in the "DCI using
ASBRs" solution. ASBRs" solution.
skipping to change at line 982 skipping to change at line 983
* The GW will not propagate MAC Mobility for the MACs moving within * The GW will not propagate MAC Mobility for the MACs moving within
a DC. Mobility intra-DC is solved by all the NVEs in the DC. The a DC. Mobility intra-DC is solved by all the NVEs in the DC. The
MAC Mobility procedures on the GWs are only required in case of MAC Mobility procedures on the GWs are only required in case of
mobility across DCs. mobility across DCs.
* Proxy-ARP/ND function on the DC GWs can be leveraged to reduce * Proxy-ARP/ND function on the DC GWs can be leveraged to reduce
ARP/ND flooding in the DC or/and the WAN. ARP/ND flooding in the DC or/and the WAN.
4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks 4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks
PBB-EVPN [RFC7623] is yet another Interconnect option. It requires PBB-EVPN [RFC7623] is yet another interconnect option. It requires
the use of GWs where I-components and associated B-components are the use of GWs where I-components and associated B-components are
part of EVI instances. part of EVI instances.
4.5.1. Control/Data Plane Setup Procedures on the GWs 4.5.1. Control/Data Plane Setup Procedures on the GWs
EVPN will run independently in both components, the I-component MAC- EVPN will run independently in both components, the I-component MAC-
VRF and B-component MAC-VRF. Compared to [RFC7623], the DC customer VRF and B-component MAC-VRF. Compared to [RFC7623], the DC customer
MACs (C-MACs) are no longer learned in the data plane on the GW but MACs (C-MACs) are no longer learned in the data plane on the GW but
in the control plane through EVPN running on the I-component. Remote in the control plane through EVPN running on the I-component. Remote
C-MACs coming from remote PEs are still learned in the data plane. C-MACs coming from remote PEs are still learned in the data plane.
skipping to change at line 1031 skipping to change at line 1032
C-MACs learned from the B-component will be advertised in EVPN within C-MACs learned from the B-component will be advertised in EVPN within
the I-component EVI scope. If the C-MAC was previously known in the the I-component EVI scope. If the C-MAC was previously known in the
I-component database, EVPN would advertise the C-MAC with a higher I-component database, EVPN would advertise the C-MAC with a higher
sequence number, as per [RFC7432]. From the perspective of Mobility sequence number, as per [RFC7432]. From the perspective of Mobility
and the related procedures described in [RFC7432], the C-MACs learned and the related procedures described in [RFC7432], the C-MACs learned
from the B-component are considered local. from the B-component are considered local.
4.5.4. Gateway Optimizations 4.5.4. Gateway Optimizations
All the considerations explained in Section 4.4.5 are applicable to All the considerations explained in Section 4.4.5 are applicable to
the PBB-EVPN Interconnect option. the PBB-EVPN interconnect option.
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks
If EVPN for Overlay tunnels is supported in the WAN, and a GW If EVPN for Overlay tunnels is supported in the WAN, and a GW
function is required, an end-to-end EVPN solution can be deployed. function is required, an end-to-end EVPN solution can be deployed.
While multiple Overlay tunnel combinations at the WAN and the DC are While multiple Overlay tunnel combinations at the WAN and the DC are
possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its
popularity in the industry. This section focuses on the specific popularity in the industry. This section focuses on the specific
case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the
[RFC7432] procedures. [RFC7432] procedures.
The procedures described in Section 4.4 apply to this section, too, The procedures described in Section 4.4 apply to this section, too,
only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics
and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3. and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3.
Since there are no ESI labels in VXLAN, GWs need to rely on "Local Since there are no ESI labels in VXLAN, GWs need to rely on "Local
Bias" to apply split horizon on packets generated from the I-ES and Bias" to apply split horizon on packets generated from the I-ES and
sent to the peer GW. sent to the peer GW.
This use case assumes that NVEs need to use the VNIs or VSIDs as This use case assumes that NVEs need to use the VNIs or VSIDs as
globally unique identifiers within a data center, and a Gateway needs globally unique identifiers within a Data Center, and a Gateway needs
to be employed at the edge of the data-center network to translate to be employed at the edge of the Data-Center network to translate
the VNI or VSID when crossing the network boundaries. This GW the VNI or VSID when crossing the network boundaries. This GW
function provides VNI and tunnel-IP-address translation. The use function provides VNI and tunnel-IP-address translation. The use
case in which local downstream-assigned VNIs or VSIDs can be used case in which local downstream-assigned VNIs or VSIDs can be used
(like MPLS labels) is described by [RFC8365]. (like MPLS labels) is described by [RFC8365].
While VNIs are globally significant within each DC, there are two While VNIs are globally significant within each DC, there are two
possibilities in the Interconnect network: possibilities in the interconnect network:
1. Globally unique VNIs in the Interconnect network. In this case, 1. Globally unique VNIs in the interconnect network. In this case,
the GWs and PEs in the Interconnect network will agree on a the GWs and PEs in the interconnect network will agree on a
common VNI for a given EVI. The RT to be used in the common VNI for a given EVI. The RT to be used in the
Interconnect network can be autoderived from the agreed-upon interconnect network can be autoderived from the agreed-upon
Interconnect VNI. The VNI used inside each DC MAY be the same as interconnect VNI. The VNI used inside each DC MAY be the same as
the Interconnect VNI. the interconnect VNI.
2. Downstream-assigned VNIs in the Interconnect network. In this 2. Downstream-assigned VNIs in the interconnect network. In this
case, the GWs and PEs MUST use the proper RTs to import/export case, the GWs and PEs MUST use the proper RTs to import/export
the EVPN routes. Note that even if the VNI is downstream the EVPN routes. Note that even if the VNI is downstream
assigned in the Interconnect network, and unlike option (a), it assigned in the interconnect network, and unlike option (a), it
only identifies the <Ethernet Tag, GW> pair and not the <Ethernet only identifies the <Ethernet Tag, GW> pair and not the <Ethernet
Tag, egress PE> pair. The VNI used inside each DC MAY be the Tag, egress PE> pair. The VNI used inside each DC MAY be the
same as the Interconnect VNI. GWs SHOULD support multiple VNI same as the interconnect VNI. GWs SHOULD support multiple VNI
spaces per EVI (one per Interconnect network they are connected spaces per EVI (one per interconnect network they are connected
to). to).
In both options, NVEs inside a DC only have to be aware of a single In both options, NVEs inside a DC only have to be aware of a single
VNI space, and only GWs will handle the complexity of managing VNI space, and only GWs will handle the complexity of managing
multiple VNI spaces. In addition to VNI translation above, the GWs multiple VNI spaces. In addition to VNI translation above, the GWs
will provide translation of the tunnel source IP for the packets will provide translation of the tunnel source IP for the packets
generated from the NVEs, using their own IP address. GWs will use generated from the NVEs, using their own IP address. GWs will use
that IP address as the BGP next hop in all the EVPN updates to the that IP address as the BGP next hop in all the EVPN updates to the
Interconnect network. interconnect network.
The following sections provide more details about these two options. The following sections provide more details about these two options.
4.6.1. Globally Unique VNIs in the Interconnect Network 4.6.1. Globally Unique VNIs in the Interconnect Network
Considering Figure 2, if a host H1 in NVO-1 needs to communicate with Considering Figure 2, if a host H1 in NVO-1 needs to communicate with
a host H2 in NVO-2, and assuming that different VNIs are used in each a host H2 in NVO-2, and assuming that different VNIs are used in each
DC for the same EVI (e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2), then DC for the same EVI (e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2), then
the VNIs MUST be translated to a common Interconnect VNI (e.g., VNI- the VNIs MUST be translated to a common interconnect VNI (e.g., VNI-
100) on the GWs. Each GW is provisioned with a VNI translation 100) on the GWs. Each GW is provisioned with a VNI translation
mapping so that it can translate the VNI in the control plane when mapping so that it can translate the VNI in the control plane when
sending BGP EVPN route updates to the Interconnect network. In other sending BGP EVPN route updates to the interconnect network. In other
words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the
BGP update messages for H1's MAC route. This mapping is also used to BGP update messages for H1's MAC route. This mapping is also used to
translate the VNI in the data plane in both directions: that is, translate the VNI in the data plane in both directions: that is,
VNI-10 to VNI-100 when the packet is received from NVO-1 and the VNI-10 to VNI-100 when the packet is received from NVO-1 and the
reverse mapping from VNI-100 to VNI-10 when the packet is received reverse mapping from VNI-100 to VNI-10 when the packet is received
from the remote NVO-2 network and needs to be forwarded to NVO-1. from the remote NVO-2 network and needs to be forwarded to NVO-1.
The procedures described in Section 4.4 will be followed, considering The procedures described in Section 4.4 will be followed, considering
that the VNIs advertised/received by the GWs will be translated that the VNIs advertised/received by the GWs will be translated
accordingly. accordingly.
4.6.2. Downstream-Assigned VNIs in the Interconnect Network 4.6.2. Downstream-Assigned VNIs in the Interconnect Network
In this case, if a host H1 in NVO-1 needs to communicate with a host In this case, if a host H1 in NVO-1 needs to communicate with a host
H2 in NVO-2, and assuming that different VNIs are used in each DC for H2 in NVO-2, and assuming that different VNIs are used in each DC for
the same EVI, e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2, then the the same EVI, e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2, then the
VNIs MUST be translated as in Section 4.6.1. However, in this case, VNIs MUST be translated as in Section 4.6.1. However, in this case,
there is no need to translate to a common Interconnect VNI on the there is no need to translate to a common interconnect VNI on the
GWs. Each GW can translate the VNI received in an EVPN update to a GWs. Each GW can translate the VNI received in an EVPN update to a
locally assigned VNI advertised to the Interconnect network. Each GW locally assigned VNI advertised to the interconnect network. Each GW
can use a different Interconnect VNI; hence, this VNI does not need can use a different interconnect VNI; hence, this VNI does not need
to be agreed upon on all the GWs and PEs of the Interconnect network. to be agreed upon on all the GWs and PEs of the interconnect network.
The procedures described in Section 4.4 will be followed, taking into The procedures described in Section 4.4 will be followed, taking into
account the considerations above for the VNI translation. account the considerations above for the VNI translation.
5. Security Considerations 5. Security Considerations
This document applies existing specifications to a number of This document applies existing specifications to a number of
Interconnect models. The security considerations included in those interconnect models. The security considerations included in those
documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and
[RFC4762] apply to this document whenever those technologies are [RFC4762] apply to this document whenever those technologies are
used. used.
As discussed, [RFC8365] discusses two main DCI solution groups: "DCI As discussed, [RFC8365] discusses two main DCI solution groups: "DCI
using GWs" and "DCI using ASBRs". This document specifies the using GWs" and "DCI using ASBRs". This document specifies the
solutions that correspond to the "DCI using GWs" group. It is solutions that correspond to the "DCI using GWs" group. It is
important to note that the use of GWs provides a superior level of important to note that the use of GWs provides a superior level of
security on a per-tenant basis, compared to the use of ASBRs. This security on a per-tenant basis, compared to the use of ASBRs. This
is due to the fact that GWs need to perform a MAC lookup on the is due to the fact that GWs need to perform a MAC lookup on the
skipping to change at line 1154 skipping to change at line 1155
In addition, the GW optimizations specified in this document provide In addition, the GW optimizations specified in this document provide
additional protection of the DC tenant systems. For instance, the additional protection of the DC tenant systems. For instance, the
MAC-address advertisement control and Unknown MAC Route defined in MAC-address advertisement control and Unknown MAC Route defined in
Section 3.5.1 protect the DC NVEs from being overwhelmed with an Section 3.5.1 protect the DC NVEs from being overwhelmed with an
excessive number of MAC/IP routes being learned on the GWs from the excessive number of MAC/IP routes being learned on the GWs from the
WAN. The ARP/ND flooding control described in Section 3.5.2 can WAN. The ARP/ND flooding control described in Section 3.5.2 can
reduce/suppress broadcast storms being injected from the WAN. reduce/suppress broadcast storms being injected from the WAN.
Finally, the reader should be aware of the potential security Finally, the reader should be aware of the potential security
implications of designing a DCI with the Decoupled Interconnect implications of designing a DCI with the decoupled interconnect
solution (Section 3) or the Integrated Interconnect solution solution (Section 3) or the integrated interconnect solution
(Section 4). In the Decoupled Interconnect solution, the DC is (Section 4). In the decoupled interconnect solution, the DC is
typically easier to protect from the WAN, since each GW has a single typically easier to protect from the WAN, since each GW has a single
logical link to one WAN PE, whereas in the Integrated solution, the logical link to one WAN PE, whereas in the Integrated solution, the
GW has logical links to all the WAN PEs that are attached to the GW has logical links to all the WAN PEs that are attached to the
tenant. In either model, proper control plane and data plane tenant. In either model, proper control plane and data plane
policies should be put in place in the GWs in order to protect the DC policies should be put in place in the GWs in order to protect the DC
from potential attacks coming from the WAN. from potential attacks coming from the WAN.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
skipping to change at line 1199 skipping to change at line 1205
"Extensions to the Virtual Private LAN Service (VPLS) "Extensions to the Virtual Private LAN Service (VPLS)
Provider Edge (PE) Model for Provider Backbone Bridging", Provider Edge (PE) Model for Provider Backbone Bridging",
RFC 7041, DOI 10.17487/RFC7041, November 2013, RFC 7041, DOI 10.17487/RFC7041, November 2013,
<https://www.rfc-editor.org/info/rfc7041>. <https://www.rfc-editor.org/info/rfc7041>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong,
Requirement Levels", BCP 14, RFC 2119, "Covering Prefixes Outbound Route Filter for BGP-4",
DOI 10.17487/RFC2119, March 1997, RFC 7543, DOI 10.17487/RFC7543, May 2015,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc7543>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>. September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>. <https://www.rfc-editor.org/info/rfc8365>.
[RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"Covering Prefixes Outbound Route Filter for BGP-4", "The BGP Tunnel Encapsulation Attribute", RFC 9012,
RFC 7543, DOI 10.17487/RFC7543, May 2015, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc7543>. <https://www.rfc-editor.org/info/rfc9012>.
7.2. Informative References 7.2. Informative References
[IEEE.802.1AG]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management", IEEE standard 802.1ag-
2007, January 2008.
[IEEE.802.1Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE standard
802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December
2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>. November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870,
DOI 10.17487/RFC6870, February 2013,
<https://www.rfc-editor.org/info/rfc6870>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation Y.1731, August 2019.
[IEEE.802.1AG]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management", IEEE standard 802.1ag-
2007, January 2008.
[IEEE.802.1Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE standard
802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December
2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870,
DOI 10.17487/RFC6870, February 2013,
<https://www.rfc-editor.org/info/rfc6870>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[VIRTUAL-ES] [VIRTUAL-ES]
Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and
J. Rabadan, "EVPN Virtual Ethernet Segment", Work in J. Rabadan, "EVPN Virtual Ethernet Segment", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-virtual- Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
eth-segment-06, 9 March 2020, eth-segment-06, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual- <https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-
eth-segment-06>. eth-segment-06>.
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation Y.1731, August 2019.
Acknowledgments Acknowledgments
The authors would like to thank Neil Hart, Vinod Prabhu, and Kiran The authors would like to thank Neil Hart, Vinod Prabhu, and Kiran
Nagaraj for their valuable comments and feedback. We would also like Nagaraj for their valuable comments and feedback. We would also like
to thank Martin Vigoureux and Alvaro Retana for their detailed to thank Martin Vigoureux and Alvaro Retana for their detailed
reviews and comments. reviews and comments.
Contributors Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
 End of changes. 42 change blocks. 
97 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/