draft-ietf-bess-dci-evpn-overlay-02.txt   draft-ietf-bess-dci-evpn-overlay-03.txt 
BESS Workgroup J. Rabadan BESS Workgroup J. Rabadan
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
Juniper J. Drake
A. Sajassi Juniper A. Sajassi
D. Cai D. Cai
Cisco Cisco
Expires: September 1, 2016 February 29, 2016 Expires: January 8, 2017 July 7, 2016
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-02 draft-ietf-bess-dci-evpn-overlay-03
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 September 1, 2016. This Internet-Draft will expire on January 8, 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 32 skipping to change at page 2, line 32
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Decoupled Interconnect solution for EVPN overlay networks . . . 3 2. Decoupled Interconnect solution for EVPN overlay networks . . . 3
2.1. Interconnect requirements . . . . . . . . . . . . . . . . . 4 2.1. Interconnect requirements . . . . . . . . . . . . . . . . . 4
2.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 5 2.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 5
2.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 5 2.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 5
2.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 6 2.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 6
2.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 6 2.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 6
2.5.1 Use of the Unknown MAC route to reduce unknown 2.5.1. MAC Address Advertisement Control . . . . . . . . . . . 6
flooding . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5.2. ARP flooding control . . . . . . . . . . . . . . . . . 7
2.5.2. MAC address advertisement control . . . . . . . . . . . 7 2.5.3. Handling failures between GW and WAN Edge routers . . . 7
2.5.3. ARP flooding control . . . . . . . . . . . . . . . . . 7
2.5.4. Handling failures between GW and WAN Edge routers . . . 8
3. Integrated Interconnect solution for EVPN overlay networks . . 8 3. Integrated Interconnect solution for EVPN overlay networks . . 8
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 9 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 8
3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 10 3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 9
3.2.1. Control/Data Plane setup procedures on the GWs . . . . 10 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 . . . . . . 11 3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 10
3.3.1. Control/Data Plane setup procedures on the GWs . . . . 11 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 . . . . . 12 3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 11
3.4.1. Control Plane setup procedures on the GWs . . . . . . . 12 3.4.1. Control Plane setup procedures on the GWs . . . . . . . 11
3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 14 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 procedures on the GWs . . . . . . . . . . 14
3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15 3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15
3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 16 3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 15
3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 16 3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 16
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 17 3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 16
3.5.1. Control/Data Plane setup procedures on the GWs . . . . 17 3.5.1. Control/Data Plane setup procedures on the GWs . . . . 17
3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18 3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 17
3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18 3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 17
3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 18 3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 17
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 18 3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 18
3.6.1. Globally unique VNIs in the Interconnect network . . . 19 3.6.1. Globally unique VNIs in the Interconnect network . . . 18
3.6.2. Downstream assigned VNIs in the Interconnect network . 19 3.6.2. Downstream assigned VNIs in the Interconnect network . 19
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
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 6, line 41 skipping to change at page 6, line 41
i.e. Ethernet A-D routes per ESI and per EVI will be advertised to i.e. Ethernet A-D routes per ESI and per EVI will be advertised to
the DC NVEs. The MAC addresses learned (in the data plane) on the the DC NVEs. The MAC addresses learned (in the data plane) on the
hand-off links will be advertised with the I-ESI encoded in the ESI hand-off links will be advertised with the I-ESI encoded in the ESI
field. field.
2.5. Gateway Optimizations 2.5. Gateway Optimizations
The following features MAY be supported on the GW in order to The following features MAY be supported on the GW in order to
optimize the control plane and data plane in the DC. optimize the control plane and data plane in the DC.
2.5.1 Use of the Unknown MAC route to reduce unknown flooding 2.5.1. MAC Address Advertisement Control
The use of EVPN in the NVO networks brings a significant number of The use of EVPN in the NVO networks brings a significant number of
benefits as described in [EVPN-Overlays]. There are however some benefits as described in [EVPN-Overlays]. However, if multiple DCs
potential issues that SHOULD be addressed when the DC EVIs are are interconnected into a single EVI, each DC will have to import all
connected to the WAN VPN instances. of the MAC addresses from each of the other DCs.
The first issue is the additional unknown unicast flooding created in
the DC due to the unknown MACs existing beyond the GW. In virtualized
DCs where all the MAC addresses are learned in the control/management
plane, unknown unicast flooding is significantly reduced. This is no
longer true if the GW is connected to a layer-2 domain with data
plane learning.
The solution suggested in this document is based on the use of an
"Unknown MAC route" that is advertised by the Designated Forwarder
GW. The Unknown MAC route is a regular EVPN MAC/IP Advertisement
route where the MAC Address Length is set to 48 and the MAC address
to 00:00:00:00:00:00 (IP length is set to 0).
If this procedure is used, when an EVI is created in the GWs and the Even if optimized BGP techniques like RT-constraint are used, the
Designated Forwarder (DF) is elected, the DF will send the Unknown number of MAC addresses to advertise or withdraw (in case of failure)
MAC route. The NVEs supporting this concept will prune their unknown by the GWs of a given DC could overwhelm the NVEs within that DC,
unicast flooding list and will only send the unknown unicast packets particularly when the NVEs reside in the hypervisors.
to the owner of the Unknown MAC route. Note that the I-ESI will be
encoded in the ESI field of the NLRI so that regular multi-homing
procedures can be applied to this unknown MAC too (e.g. backup-path).
2.5.2. MAC address advertisement control The solution specified in this document uses the 'Unknown MAC' route
which is advertised into a given DC by each of the DC's GWs. This
route is a regular EVPN MAC/IP Advertisement route in which the MAC
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
set to the DC GW's I-ESI.
Another issue derived from the EVI interconnect to the WAN layer-2 An NVE within that DC that understands the Unknown MAC route will
domain is the potential massive MAC advertisement into the DC. All send (unicast) a packet with an unknown unicast MAC address to one of
the MAC addresses learned from the WAN on the hand-off attachment the DCs GWs which will then forward that packet to the correct egress
circuits or PWs must be advertised by BGP EVPN. Even if optimized BGP PE. I.e., because the ESI is set to the DC GW's I-ESI, all-active
techniques like RT-constraint are used, the amount of MAC addresses multi-homing can be applied to unknown unicast MAC addresses.
to advertise or withdraw (in case of failure) from the GWs can be
difficult to control and overwhelming for the DC network, especially
when the NVEs reside in the hypervisors.
This document proposes the addition of administrative options so that This document proposes that administrative policy determines whether
the user can enable/disable the advertisement of MAC addresses and which external MAC addresses and/or the Unknown MAC route are to
learned from the WAN as well as the advertisement of the Unknown MAC be advertised into a given DC. E.g., when all the DC MAC addresses
route from the DF GW. In cases where all the DC MAC addresses are are learned in the control/management plane, it may be appropriate to
learned in the control/management plane, the GW may disable the advertise the Unknown MAC route.
advertisement of WAN MAC addresses. Any frame with unknown
destination MAC will be exclusively sent to the Unknown MAC route
owner(s).
2.5.3. 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.4. 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 MUST be handled on the GWs as specified in
[RFC7432]. The GW detecting the failure will withdraw the EVPN routes [RFC7432]. The GW detecting the failure will withdraw the EVPN routes
as per [RFC7432]. as per [RFC7432].
Individual AC/PW failures should be detected by OAM mechanisms. For Individual AC/PW failures should 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
skipping to change at page 12, line 21 skipping to change at page 11, line 33
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
required on the [RFC7432] procedures. required on the [RFC7432] procedures.
3.4.1. Control Plane setup procedures on the GWs 3.4.1. Control Plane setup procedures on the GWs
The GWs MUST establish separate BGP sessions for sending/receiving The GWs MUST establish separate BGP sessions for sending/receiving
EVPN routes to/from the DC and to/from the WAN. Normally each GW will EVPN routes to/from the DC and to/from the WAN. Normally each GW will
setup one (two) BGP EVPN session(s) to the DC RR(s) and one(two) setup one (two) BGP EVPN session(s) to the DC RR(s) and one(two)
session(s) to the WAN RR(s). The same route-distinguisher (RD) per session(s) to the WAN RR(s).
MAC-VRF MAY be used for the EVPN service routes sent to both, WAN and
DC RRs. On the contrary, although reusing the same value is possible, In order to facilitate separate BGP processes for DC and WAN, EVPN
different route-targets are expected to be handled for the same EVI routes sent to the WAN SHOULD carry a different route-distinguisher
in the WAN and the DC. Note that the EVPN service routes sent to the (RD) than the EVPN routes sent to the DC. In addition, although
DC RRs will normally include a [RFC5512] BGP encapsulation extended reusing the same value is possible, different route-targets are
community with a different tunnel type than the one sent to the WAN expected to be handled for the same EVI in the WAN and the DC. Note
RRs. that the EVPN service routes sent to the DC RRs will normally include
a [RFC5512] BGP encapsulation extended community with a different
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. 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
values are consistently configured on the redundant GWs and the same
GW becomes DF for both I-ESIs.
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 13, line 48 skipping to change at page 13, line 16
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-overlay flooding list (by default) and not the EVPN-
MPLS flooding list. That is, GW2 will import two Inclusive MPLS 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-DC route higher
priority. priority. An administrative option MAY change this preference so
that the set-WAN 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. set-DC a higher priority. As for the Inclusive multicast routes,
an administrative option MAY change this priority.
Note that, irrespective of the encapsulation, EVPN routes always have
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 DC (for frames generated from local ACs) since only one EVPN
binding per EVI will be setup in the data plane between the two binding per EVI will be setup in the data plane between the two
nodes. That binding will by default be added to the EVPN-overlay nodes. That binding will by default be added to the EVPN-overlay
flooding list. flooding list.
skipping to change at page 16, line 16 skipping to change at page 15, line 39
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.
3.4.5. Gateway optimizations 3.4.5. Gateway optimizations
All the Gateway optimizations described in section 2.5 MAY be applied All the Gateway optimizations described in section 2.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 2.5.1, reduces the unknown flooding in the DC but also solves section 2.5.1, solves some transient packet duplication issues in
some transient packet duplication issues in cases of all-active cases of all-active multi-homing, as explained below.
multi-homing. This is explained in the following paragraph.
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 multi-homing, and the following sequence: active multi-homing, 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.
d) Before NVE1 learns M1, a packet arrives to NVE1 with d) Before NVE1 learns M1, a packet arrives at NVE1 with
destination M1. The packet is subsequently flooded. destination M1. If the Unknown MAC route had not been
advertised into the DC, NVE1 would have flooded the packet
e) Since both GW1 and GW2 know M1, they both forward the packet to throughout the DC, in particular to both GW1 and GW2. If the
the WAN (hence creating packet duplication), unless there is an same VNI/VSID is used for both known unicast and BUM traffic,
indication in the data plane that the packet from NVE1 has been as is typically the case, there is no indication in the packet
flooded. If the GWs signal the same VNI/VSID for MAC/IP that it is a BUM packet and both GW1 and GW2 would have
advertisement and inclusive multicast routes for EVI-1, such forwarded it. However, because the Unknown MAC route had been
data plane indication does not exist. advertised into the DC, NVE1 will unicast the packet to either
GW1 or GW2.
This undesired situation can be avoided by the use of the Unknown- e) Since both GW1 and GW2 know M1, the GW receiving the packet
MAC-route. If this route is used, the NVEs will prune their unknown will forward it to either GW3 or GW4.
unicast flooding list, and the non-DF GW will not received unknown
packets, only the DF will. This solves the MAC duplication issue
described above.
3.4.6. Benefits of the EVPN-MPLS Interconnect solution 3.4.6. Benefits of the EVPN-MPLS Interconnect solution
Besides retaining the EVPN attributes between Data Centers and Besides retaining the EVPN attributes between Data Centers and
throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs
has some benefits compared to pure BGP EVPN RR or Inter-AS model B has some benefits compared to pure BGP EVPN RR or Inter-AS model B
solutions without a gateway: solutions without a gateway:
o The solution supports the connectivity of local attachment o The solution supports the connectivity of local attachment
circuits on the GWs. circuits on the GWs.
skipping to change at page 22, line 27 skipping to change at page 21, line 46
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
John Drake Wen Lin
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
skipping to change at line 1042 skipping to change at page 22, line 37
Juniper Juniper
Email: rshekhar@juniper.net Email: rshekhar@juniper.net
Anil Lohiya Anil Lohiya
Juniper Juniper
Email: alohiya@juniper.net Email: alohiya@juniper.net
Dennis Cai Dennis Cai
Cisco Systems Cisco Systems
Email: dcai@cisco.com Email: dcai@cisco.com
John Drake
Juniper
Email: jdrake@juniper.net
 End of changes. 31 change blocks. 
106 lines changed or deleted 93 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/