draft-ietf-bess-dci-evpn-overlay-06.txt   draft-ietf-bess-dci-evpn-overlay-07.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
Nokia Nokia
A. Sajassi A. Sajassi
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
Expires: July 26, 2018 January 22, 2018 Expires: August 2, 2018 January 29, 2018
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-06 draft-ietf-bess-dci-evpn-overlay-07
Abstract Abstract
This document describes how Network Virtualization Overlays (NVO) can This document describes how Network Virtualization Overlays (NVO) can
be connected to a Wide Area Network (WAN) in order to extend the be connected to a Wide Area Network (WAN) in order to extend the
layer-2 connectivity required for some tenants. The solution analyzes layer-2 connectivity required for some tenants. The solution analyzes
the interaction between NVO networks running Ethernet Virtual Private the interaction between NVO networks running Ethernet Virtual Private
Networks (EVPN) and other L2VPN technologies used in the WAN, such as Networks (EVPN) and other L2VPN technologies used in the WAN, such as
Virtual Private LAN Services (VPLS), VPLS extensions for Provider Virtual Private LAN Services (VPLS), VPLS extensions for Provider
Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 July 26, 2018. This Internet-Draft will expire on August 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 21 skipping to change at page 3, line 21
4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 18 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 18
4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 19 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 19
4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 20 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 20
4.5.1. Control/Data Plane setup procedures on the GWs . . . . 20 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 20
4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 20 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 20
4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 21 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 21
4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 21 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 21
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 21 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 21
4.6.1. Globally unique VNIs in the Interconnect network . . . 22 4.6.1. Globally unique VNIs in the Interconnect network . . . 22
4.6.2. Downstream assigned VNIs in the Interconnect network . 22 4.6.2. Downstream assigned VNIs in the Interconnect network . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
1. Conventions and Terminology 1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 8, line 46 skipping to change at page 8, line 46
plane) on the hand-off links will be advertised with the I-ESI plane) on the hand-off links will be advertised with the I-ESI
encoded in the ESI field. encoded in the ESI field.
3.5. Gateway Optimizations 3.5. Gateway Optimizations
The following GW features are optional and optimize the control plane The following GW features are optional and optimize the control plane
and data plane in the DC. and data plane in the DC.
3.5.1. MAC Address Advertisement Control 3.5.1. MAC Address Advertisement Control
The use of EVPN in the NVO networks brings a significant number of The use of EVPN in NVO networks brings a significant number of
benefits as described in [EVPN-Overlays]. However, if multiple DCs benefits as described in [EVPN-Overlays]. However, if multiple DCs
are interconnected into a single EVI, each DC will have to import all are interconnected into a single EVI, each DC will have to import all
of the MAC addresses from each of the other DCs. of the MAC addresses from each of the other DCs.
Even if optimized BGP techniques like RT-constraint [RFC4684] are Even if optimized BGP techniques like RT-constraint [RFC4684] are
used, the number of MAC addresses to advertise or withdraw (in case used, the number of MAC addresses to advertise or withdraw (in case
of failure) by the GWs of a given DC could overwhelm the NVEs within of failure) by the GWs of a given DC could overwhelm the NVEs within
that DC, particularly when the NVEs reside in the hypervisors. that DC, particularly when the NVEs reside in the hypervisors.
The solution specified in this document uses the 'Unknown MAC' route The solution specified in this document uses the 'Unknown MAC' route
skipping to change at page 9, line 24 skipping to change at page 9, line 24
An NVE within that DC that understands and process the Unknown MAC An NVE within that DC that understands and process the Unknown MAC
route will send unknown unicast frames to one of the DCs GWs, which route will send unknown unicast frames to one of the DCs GWs, which
will then forward that packet to the correct egress PE. Note that, will then forward that packet to the correct egress PE. Note that,
because the ESI is set to the DC GW's I-ESI, all-active multi-homing because the ESI is set to the DC GW's I-ESI, all-active multi-homing
can be applied to unknown unicast MAC addresses. can be applied to unknown unicast MAC addresses.
This document proposes that local policy determines whether MAC This document proposes that local policy determines whether MAC
addresses and/or the Unknown MAC route are advertised into a given addresses and/or the Unknown MAC route are advertised into a given
DC. As an example, when all the DC MAC addresses are learned in the DC. As an example, when all the DC MAC addresses are learned in the
control/management plane, it may be appropriate to advertise only the control/management plane, it may be appropriate to advertise only the
Unknown MAC route. Unknown MAC route. Advertising all the DC MAC addresses in the
control/management plane is usually the case when the NVEs reside in
hypervisors. Refer to [EVPN-Overlays] section 7.
3.5.2. ARP/ND flooding control 3.5.2. ARP/ND 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.
skipping to change at page 12, line 13 skipping to change at page 12, line 16
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 composed As far as BUM flooding is concerned, a flooding list will be composed
of the sub-list created by the inclusive multicast routes and the of 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 (AC) will be forwarded to the flooding list. local Attachment Circuit (AC) will be forwarded to the flooding list.
BUM frames received from the DC or the WAN will be forwarded to the BUM 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, so that loops and packet
packet duplication. This is described in [EVPN-VPLS-INTEGRATION] and, duplication are avoided. In case a GW can successfully establish
in case a GW can successfully establish both, an EVPN binding and a both, an EVPN binding and a PW to the same far-end PE, the EVPN
PW to the same far-end PE, the EVPN binding will prevail and the PW binding will prevail and the PW will be brought operationally down.
will be brought operationally down.
The optimizations procedures described in section 3.5 can also be The optimizations procedures described in section 3.5 can also be
applied to this model. applied to this model.
4.2.2. Multi-homing procedures on the GWs 4.2.2. Multi-homing procedures on the GWs
This model supports single-active multi-homing on the GWs. All-active This model supports single-active multi-homing on the GWs. All-active
multi-homing is not supported by VPLS, therefore it cannot be used on multi-homing is not supported by VPLS, therefore it cannot be used on
the GWs. the GWs.
skipping to change at page 15, line 36 skipping to change at page 15, line 39
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-WAN 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-DC 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-WAN a higher priority. As with the Inclusive multicast set-WAN a higher priority. As with the Inclusive multicast
routes, 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
higher priority than VPLS AD routes as indicated in [EVPN-VPLS-
INTEGRATION].
4.4.2. Data Plane setup procedures on the GWs 4.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 EVPN-Overlay network (for frames generated from local ACs) since same EVPN-Overlay network (for frames generated from local ACs) since
only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN-
aware bundle services) will be setup in the data plane between the 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 two nodes. That binding will by default be added to the EVPN-MPLS
flooding list. flooding list.
skipping to change at page 24, line 36 skipping to change at page 24, line 35
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>. 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<http://www.rfc-editor.org/info/rfc8174>.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress,
January 11, 2018. January 11, 2018.
[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>.
[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-11.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt,
work in progress, January, 2018 work in progress, January, 2018
7.2. Informative References 7.2. Informative References
[EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless
Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration-
00.txt, work in progress, February, 2015.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route Distribution for R., Patel, K., and J. Guichard, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
DOI 10.17487/RFC4684, November 2006, <http://www.rfc- DOI 10.17487/RFC4684, November 2006, <http://www.rfc-
editor.org/info/rfc4684>. editor.org/info/rfc4684>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible
Local Area Network (VXLAN): A Framework for Overlaying Virtualized Local Area Network (VXLAN): A Framework for Overlaying Virtualized
skipping to change at page 26, line 4 skipping to change at page 25, line 47
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire [RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870,
February 2013, <http://www.rfc-editor.org/info/rfc6870>. February 2013, <http://www.rfc-editor.org/info/rfc6870>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031,
January 2001, <http://www.rfc-editor.org/info/rfc3031>. January 2001, <http://www.rfc-editor.org/info/rfc3031>.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Neil Hart, Vinod Prabhu and Kiran The authors would like to thank Neil Hart, Vinod Prabhu and Kiran
Nagaraj for their valuable comments and feedback. We would also like Nagaraj for their valuable comments and feedback. We would also like
to thank Martin Vigoureux for his detailed review and comments. to thank Martin Vigoureux and Alvaro Retana for his detailed review
and comments.
9. Contributors 9. 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:
Ravi Shekhar Ravi Shekhar
Anil Lohiya Anil Lohiya
Wen Lin Wen Lin
Juniper Networks Juniper Networks
 End of changes. 13 change blocks. 
21 lines changed or deleted 20 lines changed or added

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