draft-ietf-bess-dci-evpn-overlay-04.txt   draft-ietf-bess-dci-evpn-overlay-05.txt 
BESS Workgroup J. Rabadan BESS Workgroup J. Rabadan (Ed.)
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track W. Henderickx
S. Palislamovic Nokia
R. Shekhar Nokia
A. Lohiya A. Sajassi
J. Drake
Juniper A. Sajassi
D. Cai
Cisco Cisco
Expires: March 12, 2017 September 8, 2016 J. Drake
Juniper
Expires: January 19, 2018 July 18, 2017
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-04 draft-ietf-bess-dci-evpn-overlay-05
Abstract Abstract
This document describes how Network Virtualization Overlay networks This document describes how Network Virtualization Overlays (NVO) can
(NVO) can be connected to a Wide Area Network (WAN) in order to be connected to a Wide Area Network (WAN) in order to extend the
extend the layer-2 connectivity required for some tenants. The layer-2 connectivity required for some tenants. The solution analyzes
solution analyzes the interaction between NVO networks running EVPN the interaction between NVO networks running EVPN and other L2VPN
and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN,
or EVPN/PBB-EVPN, and proposes a solution for the interworking and proposes a solution for the interworking between both.
between both.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 12, 2017. This Internet-Draft will expire on January 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 15 skipping to change at page 3, line 15
3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18 3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18
3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18 3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18
3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 19 3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 19
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 19 3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 19
3.6.1. Globally unique VNIs in the Interconnect network . . . 20 3.6.1. Globally unique VNIs in the Interconnect network . . . 20
3.6.2. Downstream assigned VNIs in the Interconnect network . 20 3.6.2. Downstream assigned VNIs in the Interconnect network . 20
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[EVPN-Overlays] discusses the use of EVPN as the control plane for [EVPN-Overlays] discusses the use of EVPN as the control plane for
Network Virtualization Overlay (NVO) networks, where VXLAN, NVGRE or Network Virtualization Overlays (NVO), where VXLAN, NVGRE or MPLS
MPLS over GRE can be used as possible data plane encapsulation over GRE can be used as possible data plane encapsulation options.
options.
While this model provides a scalable and efficient multi-tenant While this model provides a scalable and efficient multi-tenant
solution within the Data Center, it might not be easily extended to solution within the Data Center, it might not be easily extended to
the WAN in some cases due to the requirements and existing deployed the WAN in some cases due to the requirements and existing deployed
technologies. For instance, a Service Provider might have an already technologies. For instance, a Service Provider might have an already
deployed (PBB-)VPLS or (PBB-)EVPN network that must be used to deployed (PBB-)VPLS or (PBB-)EVPN network that has to be used to
interconnect Data Centers and WAN VPN users. A Gateway (GW) function interconnect Data Centers and WAN VPN users. A Gateway (GW) function
is required in these cases. is required in these cases.
This document describes a Interconnect solution for EVPN overlay This document describes a Interconnect solution for EVPN overlay
networks, assuming that the NVO Gateway (GW) and the WAN Edge networks, assuming that the NVO Gateway (GW) and the WAN Edge
functions can be decoupled in two separate systems or integrated into functions can be decoupled in two separate systems or integrated into
the same system. The former option will be referred as "Decoupled the same system. The former option will be referred as "Decoupled
Interconnect solution" throughout the document, whereas the latter Interconnect solution" throughout the document, whereas the latter
one will be referred as "Integrated Interconnect solution". one will be referred as "Integrated Interconnect solution".
skipping to change at page 4, line 36 skipping to change at page 4, line 36
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.
2.1. Interconnect requirements 2.1. Interconnect requirements
This proposed Interconnect architecture will be normally deployed in This proposed Interconnect architecture will be normally 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. The solution must observe entities and a clear demarcation is needed. The solution needs to
the following requirements: observe the following requirements:
o A simple connectivity hand-off must be provided between the EVPN- o A simple connectivity hand-off needs to be provided between the
Overlay network provider and the WAN provider so that QoS and EVPN-Overlay network provider and the WAN provider so that QoS and
security enforcement are easily accomplished. security enforcements are easily accomplished.
o The solution must be independent of the L2VPN technology deployed o The solution has to be independent of the L2VPN technology deployed
in the WAN. in the WAN.
o Multi-homing between GW and WAN Edge routers is required. Per- o Multi-homing between GW and WAN Edge routers is required. Per-
service load balancing MUST be supported. Per-flow load balancing service load balancing MUST be supported. Per-flow load balancing
MAY be supported but it is not a strong requirement since a MAY be supported but it is not a strong requirement since a
deterministic path per service is usually required for an easy QoS deterministic path per service is usually required for an easy QoS
and security enforcement. and security enforcement.
o Ethernet OAM and Connectivity Fault Management (CFM) functions must o Ethernet OAM and Connectivity Fault Management (CFM) functions
be supported between the EVPN-Overlay network and the WAN network. needs to be supported between the EVPN-Overlay network and the WAN
network.
o The following optimizations MAY be supported at the GW: o The following optimizations MAY be supported at the GW:
+ Flooding reduction of unknown unicast traffic sourced from the DC + Flooding reduction of unknown unicast traffic sourced from the DC
Network Virtualization Edge devices (NVEs). Network Virtualization Edge devices (NVEs).
+ Control of the WAN MAC addresses advertised to the DC. + Control of the WAN MAC addresses advertised to the DC.
+ ARP flooding control for the requests coming from the WAN. + ARP flooding control for the requests coming from the WAN.
2.2. VLAN-based hand-off 2.2. VLAN-based hand-off
In this option, the hand-off between the GWs and the WAN Edge routers In this option, the hand-off between the GWs and the WAN Edge routers
is based on 802.1Q VLANs. This is illustrated in Figure 1 (between is based on 802.1Q VLANs. This is illustrated in Figure 1 (between
the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is
connected to a different VSI/MAC-VRF instance in the WAN Edge router connected to a different VSI/MAC-VRF instance in the WAN Edge router
by using a different C-TAG VLAN ID or a different combination of by using a different C-TAG VLAN ID or a different combination of
S/C-TAG VLAN IDs that matches at both sides. S/C-TAG VLAN IDs that matches at both sides.
This option provides the best possible demarcation between the DC and This option provides the best possible demarcation between the DC and
WAN providers and it does not require control plane interaction WAN providers and it does not require control plane interaction
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 must be mapped to a S/C-TAG provisioning overhead since the service has to be mapped to a 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 [EVPN-Overlays]. interactions are described in [EVPN-Overlays].
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] or [RFC7432], [RFC7623].
2.3. PW-based (Pseudowire-based) hand-off 2.3. PW-based (Pseudowire-based) hand-off
If MPLS can be enabled between the GW and the WAN Edge router, a PW- If MPLS can be enabled between the GW and the WAN Edge router, a PW-
based Interconnect solution can be deployed. In this option the based Interconnect solution can be deployed. In this option the
hand-off between both routers is based on FEC128-based PWs or FEC129- hand-off between both routers is based on FEC128-based PWs or FEC129-
based PWs (for a greater level of network automation). Note that this based PWs (for a greater level of network automation). Note that this
model still provides a clear demarcation boundary between DC and WAN, model still provides a clear demarcation boundary between DC and WAN
and security/QoS policies may be applied on a per PW basis. This (since there is a single PW between each MAC-VRF and peer VSI), and
model provides better scalability than a C-TAG based hand-off and security/QoS policies may be applied on a per PW basis. This model
less provisioning overhead than a combined C/S-TAG hand-off. The provides better scalability than a C-TAG based hand-off and less
PW-based hand-off interconnect is illustrated in Figure 1 (between provisioning overhead than a combined C/S-TAG hand-off. The PW-based
the NVO-2 GWs and the WAN Edge routers). hand-off interconnect is illustrated in Figure 1 (between the NVO-2
GWs and the WAN Edge routers).
In this model, besides the usual MPLS procedures between GW and WAN In this model, besides the usual MPLS procedures between GW and WAN
Edge router, the GW MUST support an interworking function in each Edge router, the GW MUST support an interworking function in each
MAC-VRF that requires extension to the WAN: MAC-VRF that requires extension to the WAN:
o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
(WAN Edge), the provisioning of the VCID for such PW MUST be (WAN Edge), the provisioning of the VCID for such PW MUST be
supported on the MAC-VRF and must match the VCID used in the peer supported on the MAC-VRF and MUST match the VCID used in the peer
VSI at the WAN Edge router. VSI at the WAN Edge router.
o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used
between the GW MAC-VRF and the WAN Edge VSI, the provisioning of between the GW MAC-VRF and the WAN Edge VSI, the provisioning of
the VPLS-ID MUST be supported on the MAC-VRF and must match the the VPLS-ID MUST be supported on the MAC-VRF and MUST match the
VPLS-ID used in the WAN Edge VSI. VPLS-ID used in the WAN Edge VSI.
2.4. Multi-homing solution on the GWs 2.4. Multi-homing solution on the GWs
As already discussed, single-active multi-homing, i.e. per-service As already discussed, single-active multi-homing, i.e. per-service
load-balancing multi-homing MUST be supported in this type of load-balancing multi-homing MUST be supported in this type of
interconnect. All-active multi-homing may be considered in future interconnect.
revisions of this document.
The GWs will be provisioned with a unique ESI per WAN interconnect The GWs will be provisioned with a unique ESI per WAN interconnect
and the hand-off attachment circuits or PWs between the GW and the and the hand-off attachment circuits or PWs between the GW and the
WAN Edge router will be assigned to such ESI. The ESI will be WAN Edge router will be assigned to such ESI. The ESI will be
administratively configured on the GWs according to the procedures in administratively configured on the GWs according to the procedures in
[RFC7432]. This Interconnect ESI will be referred as "I-ESI" [RFC7432]. This Interconnect ESI will be referred as "I-ESI"
hereafter. hereafter.
The solution (on the GWs) MUST follow the single-active multi-homing The solution (on the GWs) MUST follow the single-active multi-homing
procedures as described in [EVPN-Overlays] for the provisioned I-ESI, procedures as described in [EVPN-Overlays] for the provisioned I-ESI,
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Address Length is set to 48, the MAC address is set to Address Length is set to 48, the MAC address is set to
00:00:00:00:00:00, the IP length is set to 0, and the ESI field is 00:00:00:00:00:00, the IP length is set to 0, and the ESI field is
set to the DC GW's I-ESI. set to the DC GW's I-ESI.
An NVE within that DC that understands the Unknown MAC route will An NVE within that DC that understands the Unknown MAC route will
send (unicast) a packet with an unknown unicast MAC address to one of send (unicast) a packet with an unknown unicast MAC address to one of
the DCs GWs which will then forward that packet to the correct egress the DCs GWs which will then forward that packet to the correct egress
PE. I.e., because the ESI is set to the DC GW's I-ESI, all-active PE. I.e., because the ESI is set to the DC GW's I-ESI, all-active
multi-homing can be applied to unknown unicast MAC addresses. multi-homing can be applied to unknown unicast MAC addresses.
This document proposes that administrative policy determines whether This document proposes that local policy determines whether MAC
and which external MAC addresses and/or the Unknown MAC route are to addresses and/or the Unknown MAC route are advertised into a given
be advertised into a given DC. E.g., when all the DC MAC addresses DC. As an example, when all the DC MAC addresses are learned in the
are learned in the control/management plane, it may be appropriate to control/management plane, it may be appropriate to advertise only the
advertise the Unknown MAC route. Unknown MAC route.
2.5.2. ARP flooding control 2.5.2. ARP flooding control
Another optimization mechanism, naturally provided by EVPN in the Another optimization mechanism, naturally provided by EVPN in the
GWs, is the Proxy ARP/ND function. The GWs SHOULD build a Proxy GWs, is the Proxy ARP/ND function. The GWs SHOULD build a Proxy
ARP/ND cache table as per [RFC7432]. When the active GW receives an ARP/ND cache table as per [RFC7432]. When the active GW receives an
ARP/ND request/solicitation coming from the WAN, the GW does a Proxy ARP/ND request/solicitation coming from the WAN, the GW does a Proxy
ARP/ND table lookup and replies as long as the information is ARP/ND table lookup and replies as long as the information is
available in its table. available in its table.
This mechanism is especially recommended on the GWs since it protects This mechanism is especially recommended on the GWs since it protects
the DC network from external ARP/ND-flooding storms. the DC network from external ARP/ND-flooding storms.
2.5.3. Handling failures between GW and WAN Edge routers 2.5.3. Handling failures between GW and WAN Edge routers
Link/PE failures MUST be handled on the GWs as specified in Link/PE failures are handled on the GWs as specified in [RFC7432].
[RFC7432]. The GW detecting the failure will withdraw the EVPN routes The GW detecting the failure will withdraw the EVPN routes as per
as per [RFC7432]. [RFC7432].
Individual AC/PW failures should be detected by OAM mechanisms. For Individual AC/PW failures MAY be detected by OAM mechanisms. For
instance: instance:
o If the Interconnect solution is based on a VLAN hand-off, o If the Interconnect solution is based on a VLAN hand-off,
802.1ag/Y.1731 Ethernet-CFM MAY be used to detect individual AC 802.1ag/Y.1731 Ethernet-CFM 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.
o If the Interconnect solution is based on a PW hand-off, the LDP PW o If the Interconnect solution is based on a PW hand-off, the LDP PW
Status bits TLV MAY be used to detect individual PW failures on Status bits TLV MAY be used to detect individual PW failures on
skipping to change at page 8, line 44 skipping to change at page 8, line 44
|<--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-->|
Figure 2 Integrated Interconnect model Figure 2 Integrated Interconnect model
3.1. Interconnect requirements 3.1. Interconnect requirements
The solution must observe the following requirements: The solution needs to observe the following requirements:
o The GW function must provide control plane and data plane o The GW function MUST provide control plane and data plane
interworking between the EVPN-overlay network and the L2VPN interworking between the EVPN-overlay network and the L2VPN
technology supported in the WAN, i.e. (PBB-)VPLS or (PBB-)EVPN, as technology supported in the WAN, i.e. (PBB-)VPLS or (PBB-)EVPN, as
depicted in Figure 2. depicted in Figure 2.
o Multi-homing MUST be supported. Single-active multi-homing with o Multi-homing MUST be supported. Single-active multi-homing with
per-service load balancing MUST be implemented. All-active multi- per-service load balancing MUST be implemented. All-active multi-
homing, i.e. per-flow load-balancing, MUST be implemented as long homing, i.e. per-flow load-balancing, SHOULD be implemented as long
as the technology deployed in the WAN supports it. as the technology deployed in the WAN supports it.
o If EVPN is deployed in the WAN, the MAC Mobility, Static MAC o If EVPN is deployed in the WAN, the MAC Mobility, Static MAC
protection and other procedures (e.g. proxy-arp) described in protection and other procedures (e.g. proxy-arp) described in
[RFC7432] must be supported end-to-end. [RFC7432] MUST be supported end-to-end.
o Any type of inclusive multicast tree MUST be independently o Any type of inclusive multicast tree MUST be independently
supported in the WAN as per [RFC7432], and in the DC as per [EVPN- supported in the WAN as per [RFC7432], and in the DC as per [EVPN-
Overlays]. Overlays].
3.2. VPLS Interconnect for EVPN-Overlay networks 3.2. VPLS Interconnect for EVPN-Overlay networks
3.2.1. Control/Data Plane setup procedures on the GWs 3.2.1. Control/Data Plane setup procedures on the GWs
Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN
PEs and RRs as per [RFC4761][RFC4762][RFC6074] and overlay tunnels PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay
and EVPN will be setup as per [EVPN-Overlays]. Note that different tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that
route-targets for the DC and for the WAN are normally required. A different route-targets for the DC and for the WAN are normally
single type-1 RD per service may be used. required. A single type-1 RD per service may be used.
In order to support multi-homing, the GWs will be provisioned with an In order to support multi-homing, the GWs will be provisioned with an
I-ESI (see section 2.4), that will be unique per interconnection. All I-ESI (see section 2.4), that will be unique per interconnection. All
the [RFC7432] procedures are still followed for the I-ESI, e.g. any the [RFC7432] procedures are still followed for the I-ESI, e.g. any
MAC address learned from the WAN will be advertised to the DC with MAC address learned from the WAN will be advertised to the DC with
the I-ESI in the ESI field. the I-ESI in the ESI field.
A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have
two different types of tunnel bindings instantiated in two different two different types of tunnel bindings instantiated in two different
split-horizon-groups: split-horizon-groups:
skipping to change at page 9, line 50 skipping to change at page 9, line 50
Attachment circuits are also supported on the same MAC-VRF, but they Attachment circuits are also supported on the same MAC-VRF, but they
will not be part of any of the above split-horizon-groups. will not be part of any of the above split-horizon-groups.
Traffic received in a given split-horizon-group will never be Traffic received in a given split-horizon-group will never be
forwarded to a member of the same split-horizon-group. forwarded to a member of the same split-horizon-group.
As far as BUM flooding is concerned, a flooding list will be created As far as BUM flooding is concerned, a flooding list will be created
with the sub-list created by the inclusive multicast routes and the with the sub-list created by the inclusive multicast routes and the
sub-list created for VPLS in the WAN. BUM frames received from a sub-list created for VPLS in the WAN. BUM frames received from a
local attachment circuit will be flooded to both sub-lists. BUM local attachment circuit will be forwarded to the flooding list. BUM
frames received from the DC or the WAN will be forwarded to the frames received from the DC or the WAN will be forwarded to the
flooding list observing the split-horizon-group rule described above. flooding list observing the split-horizon-group rule described above.
Note that the GWs are not allowed to have an EVPN binding and a PW to Note that the GWs are not allowed to have an EVPN binding and a PW to
the same far-end within the same MAC-VRF in order to avoid loops and the same far-end within the same MAC-VRF in order to avoid loops and
packet duplication. This is described in [EVPN-VPLS-INTEGRATION]. packet duplication. This is described in [EVPN-VPLS-INTEGRATION].
The optimizations procedures described in section 2.5 can also be The optimizations procedures described in section 2.5 can also be
applied to this model. applied to this model.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
of all the bindings in the "WAN split-horizon-group" for BUM and of all the bindings in the "WAN split-horizon-group" for BUM and
unicast traffic. unicast traffic.
3.3. PBB-VPLS Interconnect for EVPN-Overlay networks 3.3. PBB-VPLS Interconnect for EVPN-Overlay networks
3.3.1. Control/Data Plane setup procedures on the GWs 3.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. M MAC-VRF instances can be multiplexed into the attachment circuits. A number of MAC-VRF instances can be multiplexed
same B-component instance. This option provides significant savings into the same B-component instance. This option provides significant
in terms of PWs to be maintained in the WAN. savings in terms of PWs to be maintained in the WAN.
The I-ESI concept described in section 3.2.1 will also be used for The I-ESI concept described in section 3.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:
o Attempts to setup a PW between the two GWs within the B- o Attempts to setup a PW between the two GWs within the B-
component context will never be blocked. component context will never be blocked.
skipping to change at page 11, line 15 skipping to change at page 11, line 15
o The EVPN binding will only be up and used as long as there is no o 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 optimizations procedures described in section 2.5 can also be The optimizations procedures described in section 2.5 can also be
applied to this Interconnect option. applied to this Interconnect option.
3.3.2. Multi-homing procedures on the GWs 3.3.2. Multi-homing procedures on the GWs
Single-active multi-homing MUST be supported on the GWs. Single-active multi-homing MUST be supported on the GWs. All-active
multi-homing is not supported by this scenario.
All the single-active multi-homing procedures as described by [EVPN- All the single-active multi-homing procedures as described by [EVPN-
Overlays] will be followed for the I-ESI for each EVI instance Overlays] will be followed for the I-ESI for each EVI instance
connected to B-component. connected to B-component.
3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks 3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks
If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the
WAN, an end-to-end EVPN solution can be deployed. The following WAN, an end-to-end EVPN solution can be deployed. The following
sections describe the proposed solution as well as the impact sections describe the proposed solution as well as the impact
skipping to change at page 12, line 10 skipping to change at page 12, line 11
Overlay network MUST get assigned a different I-ESI. Overlay network MUST get assigned a different I-ESI.
Received EVPN routes will never be reflected on the GWs but consumed Received EVPN routes will never be reflected on the GWs but consumed
and re-advertised (if needed): and re-advertised (if needed):
o Ethernet A-D routes, ES routes and Inclusive Multicast routes o Ethernet A-D routes, ES routes and Inclusive Multicast routes
are consumed by the GWs and processed locally for the are consumed by the GWs and processed locally for the
corresponding [RFC7432] procedures. corresponding [RFC7432] procedures.
o MAC/IP advertisement routes will be received, imported and if o MAC/IP advertisement routes will be received, imported and if
they become active in the MAC-VRF MAC FIB, the information will they become active in the MAC-VRF, the information will be re-
be re-advertised as new routes with the following fields: advertised as new routes with the following fields:
+ The RD will be the GW's RD for the MAC-VRF. + The RD will be the GW's RD for the MAC-VRF.
+ The ESI will be set to the I-ESI. + The ESI will be set to the I-ESI.
+ The Ethernet-tag value will be kept from the received NLRI. + The Ethernet-tag value will be kept from the received NLRI.
+ The MAC length, MAC address, IP Length and IP address values + The MAC length, MAC address, IP Length and IP address values
will be kept from the received NLRI. will be kept from the received NLRI.
skipping to change at page 20, line 17 skipping to change at page 20, line 17
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.
3.6.1. Globally unique VNIs in the Interconnect network 3.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, VNI- 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 reverse 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 from the 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. remote NVO-2 network and needs to be forwarded to NVO-1.
The procedures described in section 3.4 will be followed, considering The procedures described in section 3.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.
3.6.2. Downstream assigned VNIs in the Interconnect network 3.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 VNIs 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 3.6.1. However, in this case, there MUST be translated as in section 3.6.1. However, in this case, there
is no need to translate to a common Interconnect VNI on the GWs. Each 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 locally GW can translate the VNI received in an EVPN update to a locally
assigned VNI advertised to the Interconnect network. Each GW can use assigned VNI advertised to the Interconnect network. Each GW can use
a different Interconnect VNI, hence this VNI does not need to be a different Interconnect VNI, hence this VNI does not need to be
agreed on all the GWs and PEs of the Interconnect network. agreed on all the GWs and PEs of the Interconnect network.
The procedures described in section 3.4 will be followed, taking the The procedures described in section 3.4 will be followed, taking the
considerations above for the VNI translation. considerations above for the VNI translation.
5. Conventions and Terminology 5. Conventions and Terminology
skipping to change at page 21, line 43 skipping to change at page 21, line 43
RT: Route-Target RT: Route-Target
TOR: Top-Of-Rack switch TOR: Top-Of-Rack switch
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers VNI/VSID: refers to VXLAN/NVGRE virtual identifiers
VSI: Virtual Switch Instance or VPLS instance in a particular PE VSI: Virtual Switch Instance or VPLS instance in a particular PE
6. Security Considerations 6. Security Considerations
This section will be completed in future versions. Security considerations included in [RFC7432], [RFC4761] and
[RFC4762] apply to this document.
7. IANA Considerations 7. IANA Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN [RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN
Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761,
DOI 10.17487/RFC4761, January 2007, <http://www.rfc- DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>. 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,
skipping to change at page 22, line 31 skipping to change at page 22, line 32
"Extensions to the Virtual Private LAN Service (VPLS) Provider Edge "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge
(PE) Model for Provider Backbone Bridging", RFC 7041, DOI (PE) Model for Provider Backbone Bridging", RFC 7041, DOI
10.17487/RFC7041, November 2013, <http://www.rfc- 10.17487/RFC7041, November 2013, <http://www.rfc-
editor.org/info/rfc7041>. 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 Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>. editor.org/info/rfc7432>.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC5512]Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009,
<http://www.rfc-editor.org/info/rfc5512>.
[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc- Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc-
editor.org/info/rfc7623>. editor.org/info/rfc7623>.
8.2. Informative References 8.2. Informative References
[EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-04.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-08.txt,
work in progress, June, 2016 work in progress, March, 2017
[EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless [EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless
Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration- Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration-
00.txt, work in progress, February, 2015 00.txt, work in progress, February, 2015
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Neil Hart for their valuable comments The authors would like to thank Neil Hart, Vinod Prabhu and Kiran
and feedback. Nagaraj for their valuable comments and feedback.
10. Contributors 10. 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
co-authors have also contributed to this document: co-authors have also contributed to this document:
Florin Balus Ravi Shekhar
Anil Lohiya
Wen Lin Wen Lin
Juniper Networks
Florin Balus
Patrice Brissette Patrice Brissette
Cisco
Senad Palislamovic
Nokia
Dennis Cai
Alibaba
11. Authors' Addresses 11. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Senad Palislamovic
Nokia
Email: senad.palislamovic@nokia.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Ravi Shekhar
Juniper
Email: rshekhar@juniper.net
Anil Lohiya
Juniper
Email: alohiya@juniper.net
Dennis Cai
Cisco Systems
Email: dcai@cisco.com
John Drake John Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 47 change blocks. 
96 lines changed or deleted 101 lines changed or added

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