< draft-ietf-nvo3-evpn-applicability-01.txt   draft-ietf-nvo3-evpn-applicability-02.txt >
NVO3 Workgroup J. Rabadan, Ed. NVO3 Workgroup J. Rabadan, Ed.
Internet Draft M. Bocci Internet Draft M. Bocci
Intended status: Informational Nokia Intended status: Informational Nokia
S. Boutros S. Boutros
WMware VMware
A. Sajassi A. Sajassi
Cisco Cisco
Expires: April 25, 2019 October 22, 2018 Expires: January 9, 2020 July 8, 2019
Applicability of EVPN to NVO3 Networks Applicability of EVPN to NVO3 Networks
draft-ietf-nvo3-evpn-applicability-01 draft-ietf-nvo3-evpn-applicability-02
Abstract Abstract
In NVO3 networks, Network Virtualization Edge (NVE) devices sit at In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
the edge of the underlay network and provide Layer-2 and Layer-3 the edge of the underlay network and provide Layer-2 and Layer-3
connectivity among Tenant Systems (TSes) of the same tenant. The NVEs connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
need to build and maintain mapping tables so that they can deliver need to build and maintain mapping tables so that they can deliver
encapsulated packets to their intended destination NVE(s). While encapsulated packets to their intended destination NVE(s). While
there are different options to create and disseminate the mapping there are different options to create and disseminate the mapping
table entries, NVEs may exchange that information directly among table entries, NVEs may exchange that information directly among
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 25, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 14 skipping to change at page 3, line 14
4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 18 4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 18
4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 19 4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 19
4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast 4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast
Forwarding . . . . . . . . . . . . . . . . . . . . . . 20 Forwarding . . . . . . . . . . . . . . . . . . . . . . 20
4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 21 4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 21
4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 21 4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 21
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Conventions used in this document . . . . . . . . . . . . . . . 22 6. Conventions used in this document . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
In NVO3 networks, Network Virtualization Edge (NVE) devices sit at In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
the edge of the underlay network and provide Layer-2 and Layer-3 the edge of the underlay network and provide Layer-2 and Layer-3
connectivity among Tenant Systems (TSes) of the same tenant. The NVEs connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
need to build and maintain mapping tables so that they can deliver need to build and maintain mapping tables so that they can deliver
encapsulated packets to their intended destination NVE(s). While encapsulated packets to their intended destination NVE(s). While
there are different options to create and disseminate the mapping there are different options to create and disseminate the mapping
table entries, NVEs may exchange that information directly among table entries, NVEs may exchange that information directly among
themselves via a control-plane protocol, such as EVPN. EVPN provides themselves via a control-plane protocol, such as EVPN. EVPN provides
an efficient, flexible and unified control-plane option that can be an efficient, flexible and unified control-plane option that can be
used for Layer-2 and Layer-3 Virtual Network (VN) service used for Layer-2 and Layer-3 Virtual Network (VN) service
connectivity. connectivity.
In this document, we assume that the EVPN control-plane module In this document, we assume that the EVPN control-plane module
resides in the NVEs. The NVEs can be virtual switches in hypervisors, resides in the NVEs. The NVEs can be virtual switches in hypervisors,
TOR/Leaf switches or Data Center Gateways. Note that Network TOR/Leaf switches or Data Center Gateways. As described in [RFC7365],
Virtualization Authorities (NVAs) may be used to provide the Network Virtualization Authorities (NVAs) may be used to provide the
forwarding information to the NVEs, and in that case, EVPN could be forwarding information to the NVEs, and in that case, EVPN could be
used to disseminate the information across multiple federated NVAs. used to disseminate the information across multiple federated NVAs.
The applicability of EVPN would then be similar to the one described The applicability of EVPN would then be similar to the one described
in this document. However, for simplicity, the description assumes in this document. However, for simplicity, the description assumes
control-plane communication among NVE(s). control-plane communication among NVE(s).
2. EVPN and NVO3 Terminology 2. EVPN and NVO3 Terminology
o EVPN: Ethernet Virtual Private Networks, as described in [RFC7432]. o EVPN: Ethernet Virtual Private Networks, as described in [RFC7432].
skipping to change at page 6, line 34 skipping to change at page 6, line 34
o PTA: Provider Multicast Service Interface Tunnel Attribute. o PTA: Provider Multicast Service Interface Tunnel Attribute.
o RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the o RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the
type number as defined in the IANA registry for EVPN route types. type number as defined in the IANA registry for EVPN route types.
o TS: Tenant System. o TS: Tenant System.
o ARP and ND: they refer to Address Resolution Protocol and Neighbor o ARP and ND: they refer to Address Resolution Protocol and Neighbor
Discovery protocol. Discovery protocol.
o Ethernet Tag: Used to represent a BD that is configured on a given
ES for the purpose of DF election. Note that any of the following
may be used to represent a BD: VIDs (including Q-in-Q tags),
configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN)
Network Identifiers), normalized VIDs, I-SIDs (Service Instance
Identifiers), etc., as long as the representation of the BDs is
configured consistently across the multihomed PEs attached to that
ES. The Ethernet Tag value MUST be different from zero.
3. Why Is EVPN Needed In NVO3 Networks? 3. Why Is EVPN Needed In NVO3 Networks?
Data Centers have adopted NVO3 architectures mostly due to the issues Data Centers have adopted NVO3 architectures mostly due to the issues
discussed in [RFC7364]. The architecture of a Data Center is nowadays discussed in [RFC7364]. The architecture of a Data Center is nowadays
based on a CLOS design, where every Leaf is connected to a layer of based on a CLOS design, where every Leaf is connected to a layer of
Spines, and there is a number of ECMP paths between any two leaf Spines, and there is a number of ECMP paths between any two leaf
nodes. All the links between Leaf and Spine nodes are routed links, nodes. All the links between Leaf and Spine nodes are routed links,
forming what we also know as an underlay IP Fabric. The underlay IP forming what we also know as an underlay IP Fabric. The underlay IP
Fabric does not have issues with loops or flooding (like old Spanning Fabric does not have issues with loops or flooding (like old Spanning
Tree Data Center designs did), convergence is fast and ECMP provides Tree Data Center designs did), convergence is fast and ECMP provides
skipping to change at page 9, line 26 skipping to change at page 9, line 26
| |Ethernet Tag |setup | | |Ethernet Tag |setup |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|4 |Ethernet Segment |Multi-homing: ES auto-discovery and | |4 |Ethernet Segment |Multi-homing: ES auto-discovery and |
| | |DF Election | | | |DF Election |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|5 |IP Prefix |IP Prefix dissemination | |5 |IP Prefix |IP Prefix dissemination |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|6 |Selective Multicast |Indicate interest for a multicast | |6 |Selective Multicast |Indicate interest for a multicast |
| |Ethernet Tag |S,G or *,G | | |Ethernet Tag |S,G or *,G |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|7 |IGMP Join Synch |Multi-homing: S,G or *,G state synch | |7 |Multicast Join Synch |Multi-homing: S,G or *,G state synch |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|8 |IGMP Leave Synch |Multi-homing: S,G or *,G leave synch | |8 |Multicast Leave Synch |Multi-homing: S,G or *,G leave synch |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|9 |Per-Region I-PMSI A-D |BUM tree creation across regions | |9 |Per-Region I-PMSI A-D |BUM tree creation across regions |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|10 |S-PMSI A-D |Multicast tree for S,G or *,G states | |10 |S-PMSI A-D |Multicast tree for S,G or *,G states |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|11 |Leaf A-D |Used for responses to explicit | |11 |Leaf A-D |Used for responses to explicit |
| | |tracking | | | |tracking |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
Table 1 EVPN route types Table 1 EVPN route types
skipping to change at page 10, line 40 skipping to change at page 10, line 40
o BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2 and o BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2 and
TS3 are connected to it. The five represented NVEs are attached to TS3 are connected to it. The five represented NVEs are attached to
BD1 and are connected to the same underlay IP network. That is, BD1 and are connected to the same underlay IP network. That is,
each NVE learns the remote NVEs' loopback addresses via underlay each NVE learns the remote NVEs' loopback addresses via underlay
routing protocol. routing protocol.
o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as
underlay loopback IP address. The rest of the NVEs in Figure 1 are underlay loopback IP address. The rest of the NVEs in Figure 1 are
physical switches and TS2/TS3 are multi-homed to them. TS1 is a physical switches and TS2/TS3 are multi-homed to them. TS1 is a
virtual machine, identified by MAC1 and IP1. virtual machine, identified by MAC1 and IP1. TS2 and TS3 are
physically dual-connected to NVEs, hence they are normally not
considered virtual machines.
4.2.1. Auto-Discovery and Auto-Provisioning of ES, Multi-Homing PEs and 4.2.1. Auto-Discovery and Auto-Provisioning of ES, Multi-Homing PEs and
NVE services NVE services
Auto-discovery is one of the basic capabilities of EVPN. The Auto-discovery is one of the basic capabilities of EVPN. The
provisioning of EVPN components in NVEs is significantly automated, provisioning of EVPN components in NVEs is significantly automated,
simplifying the deployment of services and minimizing manual simplifying the deployment of services and minimizing manual
operations that are prone to human error. operations that are prone to human error.
These are some of the Auto-Discovery and Auto-Provisioning These are some of the Auto-Discovery and Auto-Provisioning
skipping to change at page 20, line 7 skipping to change at page 20, line 7
and then the TS. As an example, in Figure 1, assuming NVE4 is the and then the TS. As an example, in Figure 1, assuming NVE4 is the
DF for ES-2 in BD1, BUM frames sent from TS3 to NVE5 will be DF for ES-2 in BD1, BUM frames sent from TS3 to NVE5 will be
received at NVE4 and, since NVE4 is the DF for DB1, it will received at NVE4 and, since NVE4 is the DF for DB1, it will
forward them back to TS3. Split-horizon allows NVE4 (and any forward them back to TS3. Split-horizon allows NVE4 (and any
multi-homed NVE for that matter) to identify if an EVPN BUM frame multi-homed NVE for that matter) to identify if an EVPN BUM frame
is coming from the same ES or different, and if the frame belongs is coming from the same ES or different, and if the frame belongs
to the same ES2, NVE4 will not forward the BUM frame to TS3, in to the same ES2, NVE4 will not forward the BUM frame to TS3, in
spite of being the DF. spite of being the DF.
While [RFC7432] describes the default algorithm for the DF Election, While [RFC7432] describes the default algorithm for the DF Election,
[DF] and [PREF-DF] specify other algorithms and procedures that [RFC8584] and [PREF-DF] specify other algorithms and procedures that
optimize the DF Election. optimize the DF Election.
The Split-horizon function is specified in [RFC7432] and it is The Split-horizon function is specified in [RFC7432] and it is
carried out by using a special ESI-label that it identifies in the carried out by using a special ESI-label that it identifies in the
data path, all the BUM frames being originated from a given NVE and data path, all the BUM frames being originated from a given NVE and
ES. Since the ESI-label is an MPLS label, it cannot be used in all ES. Since the ESI-label is an MPLS label, it cannot be used in all
the non-MPLS NVO3 encapsulations, therefore [RFC8365] defines a the non-MPLS NVO3 encapsulations, therefore [RFC8365] defines a
modified Split-horizon procedure that is based on the IP SA of the modified Split-horizon procedure that is based on the IP SA of the
NVO3 tunnel, known as "Local-Bias". It is worth noting that Local- NVO3 tunnel, known as "Local-Bias". It is worth noting that Local-
Bias only works for all-active multi-homing, and not for single- Bias only works for all-active multi-homing, and not for single-
skipping to change at page 22, line 37 skipping to change at page 22, line 37
6. Conventions used in this document 6. Conventions used in this document
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
7. Security Considerations 7. Security Considerations
This section will be added in future versions. This document does not introduce any new procedure or additional
signaling in EVPN, and relies on the security considerations of the
individual specifications used as a reference throughout the
document. In particular, and as mentioned in [RFC7432], control plane
and forwarding path protection are aspects to secure in any EVPN
domain, when applied to NVO3 networks.
[RFC7432] mentions security techniques such as those discussed in
[RFC5925] to authenticate BGP messages, and those included in
[RFC4271], [RFC4272] and [RFC6952] to secure BGP are relevant for
EVPN in NVO3 networks as well.
8. IANA Considerations 8. IANA Considerations
None. None.
9. References 9. References
9.1 Normative References 9.1 Normative References
[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>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network Virtualization", Rekhter, "Framework for Data Center (DC) Network Virtualization",
RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc- RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc-
skipping to change at page 23, line 33 skipping to change at page 23, line 40
1997, <https://www.rfc-editor.org/info/rfc2119>. 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>. 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2 Informative References 9.2 Informative References
[IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", [IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
draft-ietf-bess-evpn-prefix-advertisement-11, work in progress, May, draft-ietf-bess-evpn-prefix-advertisement-11, work in progress, May,
2018 2018.
[INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", [INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN",
draft-ietf-bess-evpn-inter-subnet-forwarding-05, work in progress, draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in progress,
July, 2018 March, 2019.
[RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay [RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay
Solution using EVPN", RFC 8365, March 2017, <http://www.rfc- Solution using EVPN", RFC 8365, March 2017, <http://www.rfc-
editor.org/info/rfc8365> editor.org/info/rfc8365>.
[GENEVE] Gross et al., "Geneve: Generic Network Virtualization [GENEVE] Gross et al., "Geneve: Generic Network Virtualization
Encapsulation", draft-ietf-nvo3-geneve-08, work in progress, October Encapsulation", draft-ietf-nvo3-geneve-13, work in progress, March
2018 2019.
[NVO3-ENCAP] Boutros et al., "NVO3 Encapsulation Considerations", [NVO3-ENCAP] Boutros et al., "NVO3 Encapsulation Considerations",
draft-ietf-nvo3-encap-02, work in progress, September 2018 draft-ietf-nvo3-encap-03, work in progress, July 2019.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-10, work in progress, August Attribute", draft-ietf-idr-tunnel-encaps-12, work in progress, May
2018 2019.
[EVPN-LSP-PING] Jain et al., "LSP-Ping Mechanisms for EVPN and PBB- [EVPN-LSP-PING] Jain et al., "LSP-Ping Mechanisms for EVPN and PBB-
EVPN", draft-jain-bess-evpn-lsp-ping-07, work in progress, June 2018 EVPN", draft-ietf-bess-evpn-lsp-ping-00, work in progress, May 2019.
[LOOP] Rabadan et al., "Loop Protection in EVPN networks", draft- [LOOP] Rabadan et al., "Loop Protection in EVPN networks", draft-
snr-bess-evpn-loop-protect-02, work in progress, August 2018 snr-bess-evpn-loop-protect-02, work in progress, August 2018.
[PROXY-ARP-ND] Rabadan et al., "Operational Aspects of Proxy-ARP/ND [PROXY-ARP-ND] Rabadan et al., "Operational Aspects of Proxy-ARP/ND
in EVPN Networks", draft-ietf-bess-evpn-proxy-arp-nd-05, work in in EVPN Networks", draft-ietf-bess-evpn-proxy-arp-nd-07, work in
progress, October 2018 progress, July 2019.
[IGMP-MLD-PROXY] Sajassi et al., "IGMP and MLD Proxy for EVPN", [IGMP-MLD-PROXY] Sajassi et al., "IGMP and MLD Proxy for EVPN",
draft-ietf-bess-evpn-igmp-mld-proxy-02, work in progress, June 2018 draft-ietf-bess-evpn-igmp-mld-proxy-03, work in progress, June 2019.
[PIM-PROXY] Rabadan et al., "PIM Proxy in EVPN Networks", draft-skr- [PIM-PROXY] Rabadan et al., "PIM Proxy in EVPN Networks", draft-skr-
bess-evpn-pim-proxy-01, work in progress, October 2017 bess-evpn-pim-proxy-01, work in progress, October 2017.
[OPT-IR] Rabadan et al., "Optimized Ingress Replication solution for [OPT-IR] Rabadan et al., "Optimized Ingress Replication solution for
EVPN", draft-ietf-bess-evpn-optimized-ir-06, work in progress, EVPN", draft-ietf-bess-evpn-optimized-ir-06, work in progress,
October 2018 October 2018.
[DF] Rabadan-Mohanty et al., "Framework for EVPN Designated [RFC8584] Rabadan-Mohanty et al., "Framework for EVPN Designated
Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election- Forwarder Election Extensibility", <https://rfc-
04, work in progress, October 2018 editor.org/rfc/rfc8584.txt>, April 2019.
[PREF-DF] Rabadan et al., "Preference-based EVPN DF Election", [PREF-DF] Rabadan et al., "Preference-based EVPN DF Election",
draft-ietf-bess-evpn-pref-df-02, work in progress, October 2018 draft-ietf-bess-evpn-pref-df-04, work in progress, June 2019.
[OISM] Lin at al., "EVPN Optimized Inter-Subnet Multicast (OISM) [OISM] Lin at al., "EVPN Optimized Inter-Subnet Multicast (OISM)
Forwarding", draft-ietf-bess-evpn-irb-mcast-01, work in progress, Forwarding", draft-ietf-bess-evpn-irb-mcast-02, work in progress,
July 2018 January 2019.
[EVPN-DCI] Rabadan et al., "Interconnect Solution for EVPN Overlay [EVPN-DCI] Rabadan et al., "Interconnect Solution for EVPN Overlay
networks", draft-ietf-bess-dci-evpn-overlay-10, work in progress, networks", draft-ietf-bess-dci-evpn-overlay-10, work in progress,
March 2018 March 2018.
[BUM-UPDATE] Zhang et al., "Updates on EVPN BUM Procedures", draft- [BUM-UPDATE] Zhang et al., "Updates on EVPN BUM Procedures", draft-
ietf-bess-evpn-bum-procedure-updates-04, work in progress, June 2018 ietf-bess-evpn-bum-procedure-updates-06, work in progress, June 2019.
[EVPN-IPVPN] Rabadan-Sajassi et al., "EVPN Interworking with IPVPN", [EVPN-IPVPN] Rabadan-Sajassi et al., "EVPN Interworking with IPVPN",
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-01, work in draft-ietf-sajassi-bess-evpn-ipvpn-interworking-01, work in progress,
progress, July 2018 March 2019.
[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
Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI
10.17487/RFC7348, August 2014, <http://www.rfc- 10.17487/RFC7348, August 2014, <http://www.rfc-
editor.org/info/rfc7348>. editor.org/info/rfc7348>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April
skipping to change at page 25, line 22 skipping to change at page 25, line 29
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<http://www.rfc-editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks", [CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538- The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538-
7305.1953.tb01433.x, March 1953. 7305.1953.tb01433.x, March 1953.
[EVPN-GENEVE] Boutros et al., "EVPN control plane for Geneve", [EVPN-GENEVE] Boutros et al., "EVPN control plane for Geneve",
draft-boutros-bess-evpn-geneve-03, work in progress, September 2018. draft-boutros-bess-evpn-geneve-04, work in progress, March 2019.
[EVPN-MVPN] Sajassi et al., "Seamless Multicast Interoperability [EVPN-MVPN] Sajassi et al., "Seamless Multicast Interoperability
between EVPN and MVPN PEs", draft-sajassi-bess-evpn-mvpn-seamless- between EVPN and MVPN PEs", draft-sajassi-bess-evpn-mvpn-seamless-
interop-02, work in progress, July 2018. interop-04, work in progress, July 2019.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010,
<https://www.rfc-editor.org/info/rfc5925>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271,
January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-
editor.org/info/rfc4272>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying and
Authentication for Routing Protocols (KARP) Design Guide", RFC 6952,
DOI 10.17487/RFC6952, May 2013, <https://www.rfc-
editor.org/info/rfc6952>.
10. Acknowledgments 10. Acknowledgments
The authors want to thank Aldrin Isaac for his comments. The authors want to thank Aldrin Isaac for his comments.
11. Contributors 11. Contributors
12. Authors' Addresses 12. Authors' Addresses
Jorge Rabadan (Editor) Jorge Rabadan (Editor)
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
Sami Boutros Sami Boutros
VMware VMware
Email: sboutros@vmware.com Email: boutross@vmware.com
Matthew Bocci Matthew Bocci
Nokia Nokia
Email: matthew.bocci@nokia.com Email: matthew.bocci@nokia.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
 End of changes. 36 change blocks. 
46 lines changed or deleted 86 lines changed or added

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