draft-ietf-bess-dci-evpn-overlay-03.txt   draft-ietf-bess-dci-evpn-overlay-04.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track W. Henderickx
S. Palislamovic S. Palislamovic
R. Shekhar Nokia R. Shekhar Nokia
A. Lohiya A. Lohiya
J. Drake J. Drake
Juniper A. Sajassi Juniper A. Sajassi
D. Cai D. Cai
Cisco Cisco
Expires: January 8, 2017 July 7, 2016 Expires: March 12, 2017 September 8, 2016
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-03 draft-ietf-bess-dci-evpn-overlay-04
Abstract Abstract
This document describes how Network Virtualization Overlay networks This document describes how Network Virtualization Overlay networks
(NVO) can be connected to a Wide Area Network (WAN) in order to (NVO) can be connected to a Wide Area Network (WAN) in order to
extend the layer-2 connectivity required for some tenants. The extend the layer-2 connectivity required for some tenants. The
solution analyzes the interaction between NVO networks running EVPN solution analyzes the interaction between NVO networks running EVPN
and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS
or EVPN/PBB-EVPN, and proposes a solution for the interworking or EVPN/PBB-EVPN, and proposes a solution for the interworking
between both. between both.
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 January 8, 2017. This Internet-Draft will expire on March 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 8 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 8
3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 9 3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 9
3.2.1. Control/Data Plane setup procedures on the GWs . . . . 9 3.2.1. Control/Data Plane setup procedures on the GWs . . . . 9
3.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 10 3.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 10
3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 10 3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 10
3.3.1. Control/Data Plane setup procedures on the GWs . . . . 10 3.3.1. Control/Data Plane setup procedures on the GWs . . . . 10
3.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 11 3.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 11
3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 11 3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 11
3.4.1. Control Plane setup procedures on the GWs . . . . . . . 11 3.4.1. Control Plane setup procedures on the GWs . . . . . . . 11
3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 13 3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 13
3.4.3. Multi-homing procedures on the GWs . . . . . . . . . . 14 3.4.3. Multi-homing procedure extensions on the GWs . . . . . 14
3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15 3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 16
3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 15 3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 16
3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 16 3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 17
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 16 3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 18
3.5.1. Control/Data Plane setup procedures on the GWs . . . . 17 3.5.1. Control/Data Plane setup procedures on the GWs . . . . 18
3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 17 3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18
3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 17 3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18
3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 17 3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 19
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 18 3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 19
3.6.1. Globally unique VNIs in the Interconnect network . . . 18 3.6.1. Globally unique VNIs in the Interconnect network . . . 20
3.6.2. Downstream assigned VNIs in the Interconnect network . 19 3.6.2. Downstream assigned VNIs in the Interconnect network . 20
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 19 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 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 Overlay (NVO) networks, where VXLAN, NVGRE or
MPLS over GRE can be used as possible data plane encapsulation MPLS 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
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 must be mapped to a S/C-TAG
VLAN ID combination at both, GW and WAN Edge routers. 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][PBB-EVPN]. [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 and security/QoS policies may be applied on a per PW basis. This
model provides better scalability than a C-TAG based hand-off and model provides better scalability than a C-TAG based hand-off and
skipping to change at page 11, line 47 skipping to change at page 11, line 47
(RD) than the EVPN routes sent to the DC. In addition, although (RD) than the EVPN routes sent to the DC. In addition, although
reusing the same value is possible, different route-targets are reusing the same value is possible, different route-targets are
expected to be handled for the same EVI in the WAN and the DC. Note expected to be handled for the same EVI in the WAN and the DC. Note
that the EVPN service routes sent to the DC RRs will normally include that the EVPN service routes sent to the DC RRs will normally include
a [RFC5512] BGP encapsulation extended community with a different a [RFC5512] BGP encapsulation extended community with a different
tunnel type than the one sent to the WAN RRs. tunnel type than the one sent to the WAN RRs.
As in the other discussed options, an I-ESI will be configured on the As in the other discussed options, an I-ESI will be configured on the
GWs for multi-homing. This I-ESI represents the WAN to the DC but GWs for multi-homing. This I-ESI represents the WAN to the DC but
also the DC to the WAN. Optionally, different I-ESI values MAY be also the DC to the WAN. Optionally, different I-ESI values MAY be
configured for representing the WAN and the DC, as long as the I-ESI configured for representing the WAN and the DC. If different EVPN-
values are consistently configured on the redundant GWs and the same Overlay networks are connected to the same group of GWs, each EVPN-
GW becomes DF for both I-ESIs. 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 MAC FIB, the information will
skipping to change at page 12, line 33 skipping to change at page 12, line 33
WAN) or a DC-global 24-bit value (when sent to the DC). WAN) or a DC-global 24-bit value (when sent to the DC).
+ The appropriate Route-Targets (RTs) and [RFC5512] BGP + The appropriate Route-Targets (RTs) and [RFC5512] BGP
Encapsulation extended community will be used according to Encapsulation extended community will be used according to
[EVPN-Overlays]. [EVPN-Overlays].
The GWs will also generate the following local EVPN routes that will The GWs will also generate the following local EVPN routes that will
be sent to the DC and WAN, with their corresponding RTs and [RFC5512] be sent to the DC and WAN, with their corresponding RTs and [RFC5512]
BGP Encapsulation extended community values: BGP Encapsulation extended community values:
o ES route for the I-ESI. o ES route(s) for the I-ESI(s).
o Ethernet A-D routes per ESI and EVI for the I-ESI. The A-D per- o Ethernet A-D routes per ESI and EVI for the I-ESI(s). The A-D
EVI routes sent to the WAN and the DC will have a consistent per-EVI routes sent to the WAN and the DC will have consistent
Ethernet-Tag values. Ethernet-Tag values.
o Inclusive Multicast routes with independent tunnel type value o Inclusive Multicast routes with independent tunnel type value
for the WAN and DC. E.g. a P2MP LSP may be used in the WAN for the WAN and DC. E.g. a P2MP LSP may be used in the WAN
whereas ingress replication may be used in the DC. The routes whereas ingress replication may be used in the DC. The routes
sent to the WAN and the DC will have a consistent Ethernet-Tag. sent to the WAN and the DC will have a consistent Ethernet-Tag.
o MAC/IP advertisement routes for MAC addresses learned in local o 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 Ethernet Segments I-ESI, but ESI=0 or different from 0 for local multi-homed
(ES). The routes sent to the WAN and the DC will have a Ethernet Segments (ES). The routes sent to the WAN and the DC
consistent Ethernet-Tag. 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 local service routes: Set-DC will be sent to the generate two sets of local service routes: Set-DC will be sent to the
DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP
routes for the DC encapsulation and RT. Set-WAN will be sent to the routes for the DC encapsulation and RT. Set-WAN will be sent to the
WAN RRs and will include the same routes but using the WAN RT and WAN RRs and will include the same routes but using the WAN RT and
encapsulation. GW1 and GW2 will receive each other's set-DC and set- encapsulation. GW1 and GW2 will receive each other's set-DC and set-
WAN. This is the expected behavior on GW1 and GW2 for locally WAN. This is the expected behavior on GW1 and GW2 for locally
generated routes: generated routes:
o Inclusive multicast routes: when setting up the flooding lists o Inclusive multicast routes: when setting up the flooding lists
for a given MAC-VRF, each GW will include its DC peer GW only in for a given MAC-VRF, each GW will include its DC peer GW only in
the EVPN-overlay flooding list (by default) and not the EVPN- the EVPN-MPLS flooding list (by default) and not the EVPN-
MPLS flooding list. That is, GW2 will import two Inclusive Overlay flooding list. That is, GW2 will import two Inclusive
Multicast routes from GW1 (from set-DC and set-WAN) but will Multicast routes from GW1 (from set-DC and set-WAN) but will
only consider one of the two, having the set-DC route higher only consider one of the two, having the set-WAN route higher
priority. An administrative option MAY change this preference so priority. An administrative option MAY change this preference so
that the set-WAN route is selected first. that the set-DC route is selected first.
o MAC/IP advertisement routes for local attachment circuits: as o MAC/IP advertisement routes for local attachment circuits: as
above, the GW will select only one, having the route from the above, the GW will select only one, having the route from the
set-DC a higher priority. As for the Inclusive multicast routes, set-WAN a higher priority. As for the Inclusive multicast
an administrative option MAY change this priority. routes, an administrative option MAY change this priority.
Note that, irrespective of the encapsulation, EVPN routes always have Note that, irrespective of the encapsulation, EVPN routes always have
higher priority than VPLS AD routes as per [EVPN-VPLS-INTEGRATION]. higher priority than VPLS AD routes as per [EVPN-VPLS-INTEGRATION].
3.4.2. Data Plane setup procedures on the GWs 3.4.2. Data Plane setup procedures on the GWs
The procedure explained at the end of the previous section will make The procedure explained at the end of the previous section will make
sure there are no loops or packet duplication between the GWs of the sure there are no loops or packet duplication between the GWs of the
same DC (for frames generated from local ACs) since only one EVPN same EVPN-Overlay network (for frames generated from local ACs) since
binding per EVI will be setup in the data plane between the two only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN-
nodes. That binding will by default be added to the EVPN-overlay aware bundle services) will be setup in the data plane between the
two nodes. That binding will by default be added to the EVPN-MPLS
flooding list. flooding list.
As for the rest of the EVPN tunnel bindings, they will be added to As for the rest of the EVPN tunnel bindings, they will be added to
one of the two flooding lists that each GW sets up for the same MAC- one of the two flooding lists that each GW sets up for the same MAC-
VRF: VRF:
o EVPN-overlay flooding list (composed of bindings to the remote o EVPN-overlay flooding list (composed of bindings to the remote
NVEs or multicast tunnel to the NVEs). NVEs or multicast tunnel to the NVEs).
o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the
remote PEs) remote PEs)
Each flooding list will be part of a separate split-horizon-group: Each flooding list will be part of a separate split-horizon-group:
the WAN split-horizon-group or the DC split-horizon-group. Traffic the WAN split-horizon-group or the DC split-horizon-group. Traffic
generated from a local AC can be flooded to both generated from a local AC can be flooded to both
split-horizon-groups. Traffic from a binding of a split-horizon-group split-horizon-groups. Traffic from a binding of a split-horizon-group
can be flooded to the other split-horizon-group and local ACs, but can be flooded to the other split-horizon-group and local ACs, but
never to a member of its own split-horizon-group. never to a member of its own split-horizon-group.
When either GW1 or GW2 receive a BUM frame on an overlay tunnel, they When either GW1 or GW2 receive a BUM frame on an MPLS tunnel
will perform a tunnel IP SA lookup to determine if the packet's including an ESI label at the bottom of the stack, they will perform
origin is the peer DC GW, i.e. GW2 or GW1 respectively. If the packet an ESI label lookup and split-horizon filtering as per [RFC7432] in
is coming from the peer DC GW, it MUST only be flooded to local case the ESI label identifies a local ESI (I-ESI or any other non-
attachment circuits and not to the WAN split-horizon-group (the zero ESI).
assumption is that the peer GW would have sent the BUM packet to the
WAN directly).
3.4.3. Multi-homing procedures on the GWs 3.4.3. Multi-homing procedure extensions on the GWs
Single-active as well as all-active multi-homing MUST be supported. Single-active as well as all-active multi-homing MUST be supported.
All the multi-homing procedures as described by [RFC7432] will be All the [RFC7432] multi-homing procedures for the DF election on I-
followed for the DF election for I-ESI, as well as the backup-path ESI(s) as well as the backup-path (single-active) and aliasing (all-
(single-active) and aliasing (all-active) procedures on the remote active) procedures will be followed on the GWs. Remote PEs in the
PEs/NVEs. The following changes are required at the GW with respect EVPN-MPLS network will follow regular [RFC7432] aliasing or backup-
to the I-ESI: path procedures for MAC/IP routes received from the GWs for the same
I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes
received with the same I-ESI.
o Single-active multi-homing; assuming a WAN split-horizon-group, As far as the forwarding plane is concerned, by default, the EVPN-
a DC split-horizon-group and local ACs on the GWs: Overlay network will have an analogous behavior to the access ACs in
[RFC7432] multi-homed Ethernet Segments.
+ Forwarding behavior on the non-DF: the non-DF MUST NOT forward The forwarding behavior on the GWs is described below:
BUM or unicast traffic received from a given split-horizon-
group to a member of its own split-horizon-group or to the o Single-active multi-homing; assuming a WAN split-horizon-group
other split-horizon-group. Only forwarding to local ACs is (comprised of EVPN-MPLS bindings), a DC split-horizon-group
allowed (as long as they are not part of an ES for which the (comprised of EVPN-Overlay bindings) and local ACs on the GWs:
node is non-DF).
+ Forwarding behavior on the non-DF: the non-DF MUST block
ingress and egress forwarding on the EVPN-Overlay bindings
associated to the I-ESI. The EVPN-MPLS network is considered
to be the core network and the EVPN-MPLS bindings to the
remote PEs and GWs will be active.
+ Forwarding behavior on the DF: the DF MUST NOT forward BUM or + Forwarding behavior on the DF: the DF MUST NOT forward BUM or
unicast traffic received from a given split-horizon-group to a unicast traffic received from a given split-horizon-group to a
member of his own split-horizon group or to the non-DF. member of his own split-horizon group. Forwarding to other
Forwarding to the other split-horizon-group (except the non- split-horizon-groups and local ACs is allowed (as long as the
DF) and local ACs is allowed (as long as the ACs are not part ACs are not part of an ES for which the node is non-DF). As
of an ES for which the node is non-DF). per [RFC7432] and for split-horizon purposes, when receiving
BUM traffic on the EVPN-Overlay bindings associated to an I-
ESI, the DF GW SHOULD add the I-ESI label when forwarding to
the peer GW over EVPN-MPLS.
o All-active multi-homing; assuming a WAN split-horizon-group, a + When receiving EVPN MAC/IP routes from the WAN, the non-DF
DC split-horizon-group and local ACs on the GWs: MUST NOT re-originate the EVPN routes and advertise them to
the DC peers. In the same way, EVPN MAC/IP routes received
from the DC MUST NOT be advertised to the WAN peers. This is
consistent with [RFC7432] and allows the remote PE/NVEs know
who the primary GW is, based on the reception of the MAC/IP
routes.
o All-active multi-homing; assuming a WAN split-horizon-group
(comprised of EVPN-MPLS bindings), a DC split-horizon-group
(comprised of EVPN-Overlay bindings) and local ACs on the GWs:
+ Forwarding behavior on the non-DF: the non-DF follows the same + Forwarding behavior on the non-DF: the non-DF follows the same
behavior as the non-DF in the single-active case but only for behavior as the non-DF in the single-active case but only for
BUM traffic. Unicast traffic received from a split-horizon- BUM traffic. Unicast traffic received from a split-horizon-
group MUST NOT be forwarded to a member of its own split- group MUST NOT be forwarded to a member of its own split-
horizon-group but can be forwarded normally to the other horizon-group but can be forwarded normally to the other
split-horizon-group and local ACs. If a known unicast packet split-horizon-groups and local ACs. If a known unicast packet
is identified as a "flooded" packet, the procedures for BUM is identified as a "flooded" packet, the procedures for BUM
traffic MUST be followed. traffic MUST be followed.
+ Forwarding behavior on the DF: the DF follows the same + Forwarding behavior on the DF: the DF follows the same
behavior as the DF in the single-active case but only for BUM behavior as the DF in the single-active case but only for BUM
traffic. Unicast traffic received from a split-horizon-group traffic. Unicast traffic received from a split-horizon-group
MUST NOT be forwarded to a member of its own split-horizon- MUST NOT be forwarded to a member of its own split-horizon-
group but can be forwarded normally to the other split- group but can be forwarded normally to the other split-
horizon-group and local ACs. If a known unicast packet is horizon-group and local ACs. If a known unicast packet is
identified as a "flooded" packet, the procedures for BUM identified as a "flooded" packet, the procedures for BUM
traffic MUST be followed. traffic MUST be followed. As per [RFC7432] and for split-
horizon purposes, when receiving BUM traffic on the EVPN-
Overlay bindings associated to an I-ESI, the DF GW MUST add
the I-ESI label when forwarding to the peer GW over EVPN-MPLS.
o No ESI label is required to be signaled for I-ESI for its use by + Contrary to the single-active multi-homing case, both DF and
the non-DF in the data path. This is possible because the non-DF non-DF re-originate and advertise MAC/IP routes received from
and the DF will never forward BUM traffic (coming from a split- the WAN/DC peers, adding the corresponding I-ESI so that the
horizon-group) to each other. remote PE/NVEs can perform regular aliasing as per [RFC7432].
The example in Figure 3 illustrates the forwarding of BUM traffic
originated from an NVE on a pair of all-active multi-homing GWs.
|<--EVPN-Overlay--->|<--EVPN-MPLS-->|
+---------+ +--------------+
+----+ BUM +---+ |
|NVE1+----+----> | +-+-----+ |
+----+ | | DF |GW1| | | |
| | +-+-+ | | ++--+
| | | | +--> |PE1|
| +--->X +-+-+ | ++--+
| NDF| | | |
+----+ | |GW2<-+ |
|NVE2+--+ +-+-+ |
+----+ +--------+ | +------------+
v
+--+
|CE|
+--+
Figure 3 Multi-homing BUM forwarding
GW2 is the non-DF for the I-ESI and blocks the BUM forwarding. GW1 is
the DF and forwards the traffic to PE1 and GW2. GW2 will only forward
the packets to local ACs (CE in the example).
3.4.4. Impact on MAC Mobility procedures 3.4.4. Impact on MAC Mobility procedures
MAC Mobility procedures described in [RFC7432] are not modified by MAC Mobility procedures described in [RFC7432] are not modified by
this document. this document.
Note that an intra-DC MAC move still leaves the MAC attached to the Note that an intra-DC MAC move still leaves the MAC attached to the
same I-ESI, so under the rules of [RFC7432] this is not considered a same I-ESI, so under the rules of [RFC7432] this is not considered a
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) the MAC will be learned the DC domain (or from one DC to another) the MAC will be learned
skipping to change at page 17, line 5 skipping to change at page 18, line 15
o The GW will not propagate MAC mobility for the MACs moving o 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 within 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 DC. The MAC Mobility procedures on the GWs are only required in
case of mobility across DCs. case of mobility across DCs.
o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce
ARP/ND flooding in the DC or/and in the WAN. ARP/ND flooding in the DC or/and in the WAN.
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks 3.5. PBB-EVPN Interconnect for EVPN-Overlay networks
[PBB-EVPN] is yet another Interconnect option. It requires the use of PBB-EVPN [RFC7623] is yet another Interconnect option. It requires
GWs where I-components and associated B-components are EVI the use of GWs where I-components and associated B-components are
instances. part of EVI instances.
3.5.1. Control/Data Plane setup procedures on the GWs 3.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 [PBB-EVPN], the DC C-MACs VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are
are no longer learned in the data plane on the GW but in the control no longer learned in the data plane on the GW but in the control
plane through EVPN running on the I-component. Remote C-MACs coming plane through EVPN running on the I-component. Remote C-MACs coming
from remote PEs are still learned in the data plane. B-MACs in the B- from remote PEs are still learned in the data plane. B-MACs in the B-
component will be assigned and advertised following the procedures component will be assigned and advertised following the procedures
described in [PBB-EVPN]. described in [RFC7623].
An I-ESI will be configured on the GWs for multi-homing, but it will An I-ESI will be configured on the GWs for multi-homing, but it will
only be used in the EVPN control plane for the I-component EVI. No only be used in the EVPN control plane for the I-component EVI. No
non-reserved ESIs will be used in the control plane of the B- non-reserved ESIs will be used in the control plane of the B-
component EVI as per [PBB-EVPN]. component EVI as per [RFC7623].
The rest of the control plane procedures will follow [RFC7432] for The rest of the control plane procedures will follow [RFC7432] for
the I-component EVI and [PBB-EVPN] for the B-component EVI. the I-component EVI and [RFC7623] for the B-component EVI.
From the data plane perspective, the I-component and B-component EVPN From the data plane perspective, the I-component and B-component EVPN
bindings established to the same far-end will be compared and the I- bindings established to the same far-end will be compared and the I-
component EVPN-overlay binding will be kept down following the rules component EVPN-overlay binding will be kept down following the rules
described in section 3.3.1. described in section 3.3.1.
3.5.2. Multi-homing procedures on the GWs 3.5.2. Multi-homing procedures on the GWs
Single-active as well as all-active multi-homing MUST be supported. Single-active as well as all-active multi-homing MUST be supported.
skipping to change at page 21, line 28 skipping to change at page 22, line 38
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>.
[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-02.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-04.txt,
work in progress, October, 2015 work in progress, June, 2016
[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 for their valuable comments
and feedback. and feedback.
skipping to change at page 21, line 41 skipping to change at page 23, line 4
[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 for their valuable comments
and feedback. 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 Florin Balus
Wen Lin Wen Lin
Patrice Brissette
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
 End of changes. 33 change blocks. 
87 lines changed or deleted 137 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/