draft-ietf-bess-evpn-usage-00.txt   draft-ietf-bess-evpn-usage-01.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Alcatel-Lucent Alcatel-Lucent
J. Uttaro K. Patel J. Uttaro K. Patel
AT&T A. Sajassi AT&T A. Sajassi
Cisco Cisco
A. Isaac A. Isaac
T. Boyes T. Boyes
Bloomberg Bloomberg
Expires: May 17, 2015 November 13, 2014 Expires: January 5, 2016 July 4, 2015
Usage and applicability of BGP MPLS based Ethernet VPN Usage and applicability of BGP MPLS based Ethernet VPN
draft-ietf-bess-evpn-usage-00.txt draft-ietf-bess-evpn-usage-01.txt
Abstract Abstract
This document discusses the usage and applicability of BGP MPLS based This document discusses the usage and applicability of BGP MPLS based
Ethernet VPN (EVPN) in a simple and fairly common deployment Ethernet VPN (EVPN) in a simple and fairly common deployment
scenario. The different EVPN procedures will be explained on the scenario. The different EVPN procedures will be explained on the
example scenario, analyzing the benefits and trade-offs of each example scenario, analyzing the benefits and trade-offs of each
option. Along with [EVPN], this document is intended to provide a option. Along with [RFC7432], this document is intended to provide a
simplified guide for the deployment of EVPN in Service Provider simplified guide for the deployment of EVPN in Service Provider
networks. networks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
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 May 17, 2015. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 9 skipping to change at page 3, line 9
5.3.2. Packet Walkthrough . . . . . . . . . . . . . . . . . . 16 5.3.2. Packet Walkthrough . . . . . . . . . . . . . . . . . . 16
5.4. VLAN-aware bundling service procedures . . . . . . . . . . 16 5.4. VLAN-aware bundling service procedures . . . . . . . . . . 16
5.4.1. Service startup procedures . . . . . . . . . . . . . . 17 5.4.1. Service startup procedures . . . . . . . . . . . . . . 17
5.4.2. Packet Walkthrough . . . . . . . . . . . . . . . . . . 17 5.4.2. Packet Walkthrough . . . . . . . . . . . . . . . . . . 17
6. MPLS-based forwarding model use-case . . . . . . . . . . . . . 18 6. MPLS-based forwarding model use-case . . . . . . . . . . . . . 18
6.1. Impact of MPLS-based forwarding on the EVPN network 6.1. Impact of MPLS-based forwarding on the EVPN network
startup . . . . . . . . . . . . . . . . . . . . . . . . . . 19 startup . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Impact of MPLS-based forwarding on the VLAN-based service 6.2. Impact of MPLS-based forwarding on the VLAN-based service
procedures . . . . . . . . . . . . . . . . . . . . . . . . 19 procedures . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Impact of MPLS-based forwarding on the VLAN-bundle 6.3. Impact of MPLS-based forwarding on the VLAN-bundle
service procedures . . . . . . . . . . . . . . . . . . . . 19 service procedures . . . . . . . . . . . . . . . . . . . . 20
6.4. Impact of MPLS-based forwarding on the VLAN-aware service 6.4. Impact of MPLS-based forwarding on the VLAN-aware service
procedures . . . . . . . . . . . . . . . . . . . . . . . . 20 procedures . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Comparison between MAC-based and MPLS-based forwarding models . 21 7. Comparison between MAC-based and MPLS-based forwarding models . 21
8. Traffic flow optimization . . . . . . . . . . . . . . . . . . . 22 8. Traffic flow optimization . . . . . . . . . . . . . . . . . . . 22
8.1. Control Plane Procedures . . . . . . . . . . . . . . . . . 22 8.1. Control Plane Procedures . . . . . . . . . . . . . . . . . 22
8.1.1. MAC learning options . . . . . . . . . . . . . . . . . 22 8.1.1. MAC learning options . . . . . . . . . . . . . . . . . 22
8.1.2. Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . 23 8.1.2. Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . 23
8.1.3. Unknown Unicast flooding suppression . . . . . . . . . 23 8.1.3. Unknown Unicast flooding suppression . . . . . . . . . 23
8.1.4. Optimization of Inter-subnet forwarding . . . . . . . . 24 8.1.4. Optimization of Inter-subnet forwarding . . . . . . . . 24
8.2. Packet Walkthrough Examples . . . . . . . . . . . . . . . . 25 8.2. Packet Walkthrough Examples . . . . . . . . . . . . . . . . 25
8.2.1. Proxy-ARP example for CE2 to CE3 traffic . . . . . . . 25 8.2.1. Proxy-ARP example for CE2 to CE3 traffic . . . . . . . 25
8.2.2. Flood suppression example for CE1 to CE3 traffic . . . 25 8.2.2. Flood suppression example for CE1 to CE3 traffic . . . 25
8.2.3. Optimization of inter-subnet forwarding example for 8.2.3. Optimization of inter-subnet forwarding example for
CE3 to CE2 traffic . . . . . . . . . . . . . . . . . . 26 CE3 to CE2 traffic . . . . . . . . . . . . . . . . . . 26
9. Conventions used in this document . . . . . . . . . . . . . . . 27 9. Conventions used in this document . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document complements [EVPN] by discussing the applicability of This document complements [RFC7432] by discussing the applicability
the technology in a simple and fairly common deployment scenario, of the technology in a simple and fairly common deployment scenario,
which is described in section 2. which is described in section 2.
After describing the topology of the use-case scenario and the After describing the topology of the use-case scenario and the
characteristics of the service to be deployed, section 3 will characteristics of the service to be deployed, section 3 will
describe the provisioning model, comparing the EVPN procedures with describe the provisioning model, comparing the EVPN procedures with
the provisioning tasks required for other VPN technologies, such as the provisioning tasks required for other VPN technologies, such as
VPLS or IP-VPN. VPLS or IP-VPN.
Once the provisioning model is analyzed, sections 4, 5 and 6 will Once the provisioning model is analyzed, sections 4, 5 and 6 will
describe the control plane and data plane procedures in the example describe the control plane and data plane procedures in the example
scenario, for the two potential disposition/forwarding models: MAC- scenario, for the two potential disposition/forwarding models:
based and MPLS-based models. While both models can interoperate in MAC-based and MPLS-based models. While both models can interoperate
the same network, each one has different trade-offs that are analyzed in the same network, each one has different trade-offs that are
in section 7. analyzed in section 7.
Finally, EVPN provides some potential traffic flow optimization tools Finally, EVPN provides some potential traffic flow optimization tools
that are also described in section 8, in the context of the example that are also described in section 8, in the context of the example
scenario. scenario.
2. Use-case scenario description 2. Use-case scenario description
The following figure depicts the scenario that will be referenced The following figure depicts the scenario that will be referenced
throughout the rest of the document. throughout the rest of the document.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
contexts in the core. The following three services are required in contexts in the core. The following three services are required in
this example: this example:
EVI100 - It will use VLAN-based service interfaces in the three CEs EVI100 - It will use VLAN-based service interfaces in the three CEs
with a 1:1 mapping (VLAN-to-EVI). The CE-VIDs at the three CEs can with a 1:1 mapping (VLAN-to-EVI). The CE-VIDs at the three CEs can
be the same, e.g.: VID 100, or different at each CE, e.g.: VID 101 be the same, e.g.: VID 100, or different at each CE, e.g.: VID 101
in CE1, VID 102 in CE2 and VID 103 in CE3. A single broadcast in CE1, VID 102 in CE2 and VID 103 in CE3. A single broadcast
domain needs to be created for EVI100 in any case; therefore CE- domain needs to be created for EVI100 in any case; therefore CE-
VIDs will require translation at the egress PEs if they are not VIDs will require translation at the egress PEs if they are not
consistent across the three CEs. The case when the same CE-VID is consistent across the three CEs. The case when the same CE-VID is
used across the three CEs for EVI100 is referred in [EVPN] as the used across the three CEs for EVI100 is referred in [RFC7432] as
"Unique VLAN" EVPN case. This term will be used throughout this the "Unique VLAN" EVPN case. This term will be used throughout this
document too. document too.
EVI200 - It will use VLAN-bundle service interfaces in CE1, CE2 and EVI200 - It will use VLAN-bundle service interfaces in CE1, CE2 and
CE3, based on an N:1 VLAN-to-EVI mapping. In this case, the service CE3, based on an N:1 VLAN-to-EVI mapping. In this case, the service
provider just needs to assign a pre-configured number of CE-VIDs on provider just needs to assign a pre-configured number of CE-VIDs on
the ingress PE to EVI200, and send the customer frames with the the ingress PE to EVI200, and send the customer frames with the
original CE-VIDs. The Service Provider will build a single original CE-VIDs. The Service Provider will build a single
broadcast domain for the customer. The customer will be responsible broadcast domain for the customer. The customer will be responsible
for the CE-VID handling. for the CE-VID handling.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
by all the MAC-VRFs in the node using the multi-homing capabilities. by all the MAC-VRFs in the node using the multi-homing capabilities.
In our use-case, these parameters are only provisioned in PE1 and In our use-case, these parameters are only provisioned in PE1 and
PE2, and are listed below: PE2, and are listed below:
o Ethernet Segment Identifier (ESI): only the ESI associated to CE2 o Ethernet Segment Identifier (ESI): only the ESI associated to CE2
needs to be considered in our example. Single-homed CEs such as CE1 needs to be considered in our example. Single-homed CEs such as CE1
and CE3 do not require the provisioning of an ESI (the ESI will be and CE3 do not require the provisioning of an ESI (the ESI will be
coded as zero in the BGP NLRIs). In our example, a LAG is used coded as zero in the BGP NLRIs). In our example, a LAG is used
between CE2 and PE1-PE2 (since all-active multi-homing is a between CE2 and PE1-PE2 (since all-active multi-homing is a
requirement) therefore the ESI can be auto-derived from the LACP requirement) therefore the ESI can be auto-derived from the LACP
information as described in [EVPN]. Note that the ESI MUST be information as described in [RFC7432]. Note that the ESI MUST be
unique across all the PEs in the network, therefore the unique across all the PEs in the network, therefore the
auto-provisioning of the ESI is only recommended in case the CEs auto-provisioning of the ESI is only recommended in case the CEs
are managed by the Service Provider. Otherwise the ESI should be are managed by the Service Provider. Otherwise the ESI should be
manually provisioned (type 0 as in [EVPN]) in order to avoid manually provisioned (type 0 as in [RFC7432]) in order to avoid
potential conflicts. potential conflicts.
o ES-Import Route Target (ES-Import RT): this is the RT that will be o ES-Import Route Target (ES-Import RT): this is the RT that will be
sent by PE1 and PE2, along with the ES route. Regardless of how the sent by PE1 and PE2, along with the ES route. Regardless of how the
ESI is provisioned in PE1 and PE2, the ES-Import RT must always be ESI is provisioned in PE1 and PE2, the ES-Import RT must always be
auto-derived from the 6-byte MAC address portion of the ESI value. auto-derived from the 6-byte MAC address portion of the ESI value.
o Ethernet Segment Route Distinguisher (ES RD): this is the RD to be o Ethernet Segment Route Distinguisher (ES RD): this is the RD to be
encoded in the ES route and Ethernet Auto-Discovery (A-D) route to encoded in the ES route and Ethernet Auto-Discovery (A-D) route to
be sent by PE1 and PE2 for the CE2 ESI. This RD should always be be sent by PE1 and PE2 for the CE2 ESI. This RD should always be
auto-derived from the PE IP address, as described in [EVPN]. auto-derived from the PE IP address, as described in [RFC7432].
o Multi-homing type: the user must be able to provision the o Multi-homing type: the user must be able to provision the
multi-homing type to be used in the network. In our use-case, the multi-homing type to be used in the network. In our use-case, the
multi-homing type will be set to all-active for the CE2 ESI. This multi-homing type will be set to all-active for the CE2 ESI. This
piece of information is encoded in the ESI Label extended community piece of information is encoded in the ESI Label extended community
flags and sent by PE1 and PE2 along with the Ethernet A-D route for flags and sent by PE1 and PE2 along with the Ethernet A-D route for
the CE2 ESI. the CE2 ESI.
In our use-case, besides the above parameters, the same LACP In our use-case, besides the above parameters, the same LACP
parameters will be configured in PE1 and PE2 for the ESI, so that CE2 parameters will be configured in PE1 and PE2 for the ESI, so that CE2
skipping to change at page 9, line 6 skipping to change at page 9, line 6
In our use-case, EVI100 is a VLAN-based service interface EVI. In our use-case, EVI100 is a VLAN-based service interface EVI.
EVI100 can be a "unique-VLAN" EVPN if the CE-VID being used for this EVI100 can be a "unique-VLAN" EVPN if the CE-VID being used for this
service in CE1, CE2 and CE3 is equal, e.g. VID 100. In that case, the service in CE1, CE2 and CE3 is equal, e.g. VID 100. In that case, the
VID 100 binding must be provisioned in PE1, PE2 and PE3 for EVI100 VID 100 binding must be provisioned in PE1, PE2 and PE3 for EVI100
and the associated port or LAG. The MAC-VRF RD and RT can be auto- and the associated port or LAG. The MAC-VRF RD and RT can be auto-
derived from the CE-VID: derived from the CE-VID:
o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in
[EVPN], and it will be comprised of [PE-IP]:[zero-padded-VID]; [RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID];
where PE-IP is the IP address of the PE (a loopback address) and where PE-IP is the IP address of the PE (a loopback address) and
[zero-padded-VID] is a 2-byte value where the low order 12 bits are [zero-padded-VID] is a 2-byte value where the low order 12 bits are
the VID (VID 100 in our example) and the high order 4 bits are the VID (VID 100 in our example) and the high order 4 bits are
zero. zero.
o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded- o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded-
VID]; where AS is the Autonomous System that the PE belongs to and VID]; where AS is the Autonomous System that the PE belongs to and
[zero-padded-VID] is a 4-byte value where the low order 12 bits are [zero-padded-VID] is a 4-byte value where the low order 12 bits are
the VID (VID 100 in our example) and the high order 20 bits are the VID (VID 100 in our example) and the high order 20 bits are
zero. Note that auto-deriving the RT implies supporting a basic zero. Note that auto-deriving the RT implies supporting a basic
skipping to change at page 9, line 49 skipping to change at page 9, line 49
broadcast domain, i.e. Ethernet Tag, which will be encoded in the BGP broadcast domain, i.e. Ethernet Tag, which will be encoded in the BGP
EVPN routes. EVPN routes.
Therefore, besides the CE-VID bundle range bound to EVI300 in each Therefore, besides the CE-VID bundle range bound to EVI300 in each
PE, associations between each individual CE-VID and the EVPN Ethernet PE, associations between each individual CE-VID and the EVPN Ethernet
Tag must be provisioned by the user. No auto-derived EVI RDs/RTs are Tag must be provisioned by the user. No auto-derived EVI RDs/RTs are
possible. possible.
4. BGP EVPN NLRI usage 4. BGP EVPN NLRI usage
[EVPN] defines four different types of routes and four different [RFC7432] defines four different types of routes and four different
extended communities advertised along with the different routes. extended communities advertised along with the different routes.
However not all the PEs in a network must generate and process all However not all the PEs in a network must generate and process all
the different routes and extended communities. The following table the different routes and extended communities. The following table
shows the routes that must be exported and imported in the use-case shows the routes that must be exported and imported in the use-case
described in this document. "Export", in this context, means that the described in this document. "Export", in this context, means that the
PE must be capable of generating and exporting a given route, PE must be capable of generating and exporting a given route,
assuming there are no BGP policies to prevent it. In the same way, assuming there are no BGP policies to prevent it. In the same way,
"Import" means the PE must be capable of importing and processing a "Import" means the PE must be capable of importing and processing a
given route, assuming the right RTs and policies. "N/A" means neither given route, assuming the right RTs and policies. "N/A" means neither
import nor export actions are required. import nor export actions are required.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
5.1. EVPN Network Startup procedures 5.1. EVPN Network Startup procedures
Before any EVI is provisioned in the network, the following Before any EVI is provisioned in the network, the following
procedures are required: procedures are required:
o Infrastructure setup: the proper MPLS infrastructure must be setup o Infrastructure setup: the proper MPLS infrastructure must be setup
among PE1, PE2 and PE3 so that the EVPN services can make use of among PE1, PE2 and PE3 so that the EVPN services can make use of
P2P, P2MP and/or MP2MP LSPs. In addition to the MPLS transport, PE1 P2P, P2MP and/or MP2MP LSPs. In addition to the MPLS transport, PE1
and PE2 must be properly configured with the same LACP and PE2 must be properly configured with the same LACP
configuration to CE2. Details are provided in [EVPN]. Once the LAG configuration to CE2. Details are provided in [RFC7432]. Once the
is properly setup, the ESI for the CE2 Ethernet Segment, e.g. LAG is properly setup, the ESI for the CE2 Ethernet Segment, e.g.
ESI12, can be auto-generated by PE1 and PE2 from the LACP ESI12, can be auto-generated by PE1 and PE2 from the LACP
information exchanged with CE2 (ESI type 1), as discussed in information exchanged with CE2 (ESI type 1), as discussed in
section 3.1. Alternatively, the ESI can also be manually section 3.1. Alternatively, the ESI can also be manually
provisioned on PE1 and PE2 (ESI type 0). PE1 and PE2 will auto- provisioned on PE1 and PE2 (ESI type 0). PE1 and PE2 will auto-
configure a BGP policy that will import any ES route matching the configure a BGP policy that will import any ES route matching the
auto-derived ES-import RT for ESI12. auto-derived ES-import RT for ESI12.
o Ethernet Segment route exchange and DF election: PE1 and PE2 will o Ethernet Segment route exchange and DF election: PE1 and PE2 will
advertise a BGP Ethernet Segment route for ESI12, where the ESI RD advertise a BGP Ethernet Segment route for ESI12, where the ESI RD
and ES-Import RT will be auto-generated as discussed in section and ES-Import RT will be auto-generated as discussed in section
skipping to change at page 11, line 51 skipping to change at page 11, line 51
o Flooding tree setup per EVI (4k routes): Each PE will send one o Flooding tree setup per EVI (4k routes): Each PE will send one
Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per
PE) so that the flooding tree per EVI can be setup. Note that PE) so that the flooding tree per EVI can be setup. Note that
ingress replication, P2MP LSPs or MP2MP LSPs can optionally be ingress replication, P2MP LSPs or MP2MP LSPs can optionally be
signaled in the PMSI Tunnel attribute and the corresponding tree be signaled in the PMSI Tunnel attribute and the corresponding tree be
created. created.
o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of
A-D routes with a list of 4k RTs (one per EVI) for ESI12 will be A-D routes with a list of 4k RTs (one per EVI) for ESI12 will be
issued from PE1 and PE2 (it has to be a set of routes so that the issued from PE1 and PE2 (it has to be a set of routes so that the
total number of RTs can be conveyed). This set will also include total number of RTs can be conveyed). As per [RFC7432], each
ESI Label extended communities with the active-standby flag set to Ethernet A-D route per ESI is differentiated from the other routes
zero (all-active multi-homing type) and an ESI Label different from in the set by a different Route Distinguisher (ES RD. This set will
zero (used for split-horizon functions). These routes will be also include ESI Label extended communities with the active-standby
imported by the three PEs, since the RTs match the EVI RTs locally flag set to zero (all-active multi-homing type) and an ESI Label
configured. The A-D routes per ESI will be used for fast different from zero (used for split-horizon functions). These
convergence and split-horizon functions, as discussed in [EVPN]. routes will be imported by the three PEs, since the RTs match the
EVI RTs locally configured. The A-D routes per ESI will be used for
fast convergence and split-horizon functions, as discussed in
[RFC7432].
o Ethernet A-D routes per EVI (4k routes): An A-D route per EVI will o Ethernet A-D routes per EVI (4k routes): An A-D route per EVI will
be sent by PE1 and PE2 for ESI12. Each individual route includes be sent by PE1 and PE2 for ESI12. Each individual route includes
the corresponding EVI RT and an MPLS label to be used by PE3 for the corresponding EVI RT and an MPLS label to be used by PE3 for
the aliasing function. These routes will be imported by the three the aliasing function. These routes will be imported by the three
PEs. PEs.
5.2.2. Packet walkthrough 5.2.2. Packet walkthrough
Once the services are setup, the traffic can start flowing. Assuming Once the services are setup, the traffic can start flowing. Assuming
skipping to change at page 14, line 4 skipping to change at page 14, line 7
MPLS label assigned from the PE2 label space (one label per MAC- MPLS label assigned from the PE2 label space (one label per MAC-
VRF). Again, depending on the implementation, the MAC FIB and VRF). Again, depending on the implementation, the MAC FIB and
proxy-ARP learning processes can independently send two BGP MAC proxy-ARP learning processes can independently send two BGP MAC
advertisements instead of one. advertisements instead of one.
Note that, since PE3 is not part of ESI12, it will install a Note that, since PE3 is not part of ESI12, it will install a
forwarding state for CE2-MAC as long as the A-D routes for ESI12 forwarding state for CE2-MAC as long as the A-D routes for ESI12
are also active on PE3. On the contrary, PE1 is part of ESI12, are also active on PE3. On the contrary, PE1 is part of ESI12,
therefore PE1 will not modify the forwarding state for CE2-MAC if therefore PE1 will not modify the forwarding state for CE2-MAC if
it has previously learnt CE2-MAC locally attached to ESI12. it has previously learnt CE2-MAC locally attached to ESI12.
Otherwise it will add forwarding state for CE2-MAC associated to Otherwise it will add forwarding state for CE2-MAC associated to
the local ESI12 port. the local ESI12 port.
c) Assuming PE2 does not have the ARP information for CE3-IP yet, and c) Assuming PE2 does not have the ARP information for CE3-IP yet, and
since the ARP is a broadcast frame and PE2 the non-DF for EVI1 on since the ARP is a broadcast frame and PE2 the non-DF for EVI1 on
ESI12, the frame is forwarded by PE2 in the Inclusive multicast ESI12, the frame is forwarded by PE2 in the Inclusive multicast
tree for EVI1, adding the ESI label for ESI12 at the bottom of the tree for EVI1, adding the ESI label for ESI12 at the bottom of the
stack. The ESI label has been previously allocated and signaled by stack. The ESI label has been previously allocated and signaled by
the A-D routes for ESI12. Note that, as per [EVPN], if the result the A-D routes for ESI12. Note that, as per [RFC7432], if the
of the CE2 hashing is different and the frame sent to PE1, PE1 result of the CE2 hashing is different and the frame sent to PE1,
SHOULD add the ESI label too (PE1 is the DF for EVI1 on ESI12). PE1 SHOULD add the ESI label too (PE1 is the DF for EVI1 on
ESI12).
d) The MPLS-encapsulated frame gets to PE1 and PE3. PE1 d) The MPLS-encapsulated frame gets to PE1 and PE3. PE1
de-encapsulate the Inclusive multicast tree label(s) and based on de-encapsulate the Inclusive multicast tree label(s) and based on
the ESI label at the bottom of the stack, it decides to not the ESI label at the bottom of the stack, it decides to not
forward the frame to the ESI12. It will pop the ESI label and will forward the frame to the ESI12. It will pop the ESI label and will
replicate it to CE1 though, since CE1 is not part of the ESI replicate it to CE1 though, since CE1 is not part of the ESI
identified by the ESI label. At PE3, the Inclusive multicast tree identified by the ESI label. At PE3, the Inclusive multicast tree
label is popped and the frame forwarded to CE3. If a P2MP LSP is label is popped and the frame forwarded to CE3. If a P2MP LSP is
used as Inclusive multicast tree for EVI1, PE3 will find an ESI used as Inclusive multicast tree for EVI1, PE3 will find an ESI
label after popping the P2MP LSP label. The ESI label will simply label after popping the P2MP LSP label. The ESI label will simply
skipping to change at page 16, line 13 skipping to change at page 16, line 18
tree be created. tree be created.
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D o Ethernet A-D routes per ESI (one route for ESI12): A single A-D
route for ESI12 will be issued from PE1 and PE2. This route will route for ESI12 will be issued from PE1 and PE2. This route will
include a single RT (RT for EVI200), an ESI Label extended include a single RT (RT for EVI200), an ESI Label extended
community with the active-standby flag set to zero (all-active community with the active-standby flag set to zero (all-active
multi-homing type) and an ESI Label different from zero (used by multi-homing type) and an ESI Label different from zero (used by
the non-DF for split-horizon functions). This route will be the non-DF for split-horizon functions). This route will be
imported by the three PEs, since the RT matches the EVI200 RT imported by the three PEs, since the RT matches the EVI200 RT
locally configured. The A-D routes per ESI will be used for fast locally configured. The A-D routes per ESI will be used for fast
convergence and split-horizon functions, as described in [EVPN]. convergence and split-horizon functions, as described in
[RFC7432].
o Ethernet A-D routes per EVI (one route): An A-D route (EVI200) will o Ethernet A-D routes per EVI (one route): An A-D route (EVI200) will
be sent by PE1 and PE2 for ESI12. This route includes the EVI200 be sent by PE1 and PE2 for ESI12. This route includes the EVI200
RT and an MPLS label to be used by PE3 for the aliasing function. RT and an MPLS label to be used by PE3 for the aliasing function.
This route will be imported by the three PEs. This route will be imported by the three PEs.
5.3.2. Packet Walkthrough 5.3.2. Packet Walkthrough
The packet walkthrough for the VLAN-bundle case is similar to the one The packet walkthrough for the VLAN-bundle case is similar to the one
described for EVI1 in the VLAN-based case except for the way the described for EVI1 in the VLAN-based case except for the way the
skipping to change at page 17, line 29 skipping to change at page 17, line 36
make sense in order to save forwarding states. make sense in order to save forwarding states.
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D o Ethernet A-D routes per ESI (one route for ESI12): A single A-D
route for ESI12 will be issued from PE1 and PE2. This route will route for ESI12 will be issued from PE1 and PE2. This route will
include a single RT (RT for EVI300), an ESI Label extended include a single RT (RT for EVI300), an ESI Label extended
community with the active-standby flag set to zero (all-active community with the active-standby flag set to zero (all-active
multi-homing type) and an ESI Label different than zero (used by multi-homing type) and an ESI Label different than zero (used by
the non-DF for split-horizon functions). This route will be the non-DF for split-horizon functions). This route will be
imported by the three PEs, since the RT matches the EVI300 RT imported by the three PEs, since the RT matches the EVI300 RT
locally configured. The A-D routes per ESI will be used for fast locally configured. The A-D routes per ESI will be used for fast
convergence and split-horizon functions, as described in [EVPN]. convergence and split-horizon functions, as described in
[RFC7432].
o Ethernet A-D routes per EVI (one route): An A-D route (EVI300) will o Ethernet A-D routes per EVI (one route): An A-D route (EVI300) will
be sent by PE1 and PE2 for ESI12. This route includes the EVI300 be sent by PE1 and PE2 for ESI12. This route includes the EVI300
RT and an MPLS label to be used by PE3 for the aliasing function. RT and an MPLS label to be used by PE3 for the aliasing function.
This route will be imported by the three PEs. This route will be imported by the three PEs.
5.4.2. Packet Walkthrough 5.4.2. Packet Walkthrough
The packet walkthrough for the VLAN-aware case is similar to the one The packet walkthrough for the VLAN-aware case is similar to the one
described before. Compared to the other two cases, VLAN-aware described before. Compared to the other two cases, VLAN-aware
skipping to change at page 22, line 26 skipping to change at page 22, line 33
+-----------------------------+----------------+----------------+ +-----------------------------+----------------+----------------+
The egress forwarding model is an implementation local to the egress The egress forwarding model is an implementation local to the egress
PE and is independent of the model supported on the rest of the PEs, PE and is independent of the model supported on the rest of the PEs,
i.e. in our use-case, PE1, PE2 and PE3 could have either egress i.e. in our use-case, PE1, PE2 and PE3 could have either egress
forwarding model without any dependencies. forwarding model without any dependencies.
8. Traffic flow optimization 8. Traffic flow optimization
In addition to the procedures described across sections 1 through 7, In addition to the procedures described across sections 1 through 7,
EVPN [EVPN] procedures allow for optimized traffic handling in order EVPN [RFC7432] procedures allow for optimized traffic handling in
to minimize unnecessary flooding across the entire infrastructure. order to minimize unnecessary flooding across the entire
Optimization is provided through specific ARP termination and the infrastructure. Optimization is provided through specific ARP
ability to block unknown unicast flooding. Additionally, EVPN termination and the ability to block unknown unicast flooding.
procedures allow for intelligent, close to the source, inter-subnet Additionally, EVPN procedures allow for intelligent, close to the
forwarding and solves the commonly known sub-optimal routing problem. source, inter-subnet forwarding and solves the commonly known sub-
Besides the traffic efficiency, ingress based inter-subnet forwarding optimal routing problem. Besides the traffic efficiency, ingress
also optimizes packet forwarding rules and implementation at the based inter-subnet forwarding also optimizes packet forwarding rules
egress nodes as well. Details of these procedures are outlined in and implementation at the egress nodes as well. Details of these
sections 8.1 and 8.2. procedures are outlined in sections 8.1 and 8.2.
8.1. Control Plane Procedures 8.1. Control Plane Procedures
8.1.1. MAC learning options 8.1.1. MAC learning options
The fundamental premise of [EVPN] is the notion of a different The fundamental premise of [RFC7432] is the notion of a different
approach to MAC address learning compared to traditional IEEE 802.1 approach to MAC address learning compared to traditional IEEE 802.1
bridge learning methods; specifically EVPN differentiates between bridge learning methods; specifically EVPN differentiates between
data and control plane driven learning mechanisms. data and control plane driven learning mechanisms.
Data driven learning implies that there is no separate communication Data driven learning implies that there is no separate communication
channel used to advertise and propagate MAC addresses. Rather, MAC channel used to advertise and propagate MAC addresses. Rather, MAC
addresses are learned through IEEE defined bridge-learning procedures addresses are learned through IEEE defined bridge-learning procedures
as well as by snooping on DHCP and ARP requests. As different MAC as well as by snooping on DHCP and ARP requests. As different MAC
addresses show up on different ports, the L2 FIB is populated with addresses show up on different ports, the L2 FIB is populated with
the appropriate MAC addresses. the appropriate MAC addresses.
skipping to change at page 23, line 19 skipping to change at page 23, line 26
o Local learning defines the procedures used for learning the MAC o Local learning defines the procedures used for learning the MAC
addresses of network elements locally connected to a MAC-VRF. addresses of network elements locally connected to a MAC-VRF.
Local learning could be implemented through all three learning Local learning could be implemented through all three learning
procedures: control plane, management plane as well as data plane. procedures: control plane, management plane as well as data plane.
However, the expectation is that for most of the use cases, local However, the expectation is that for most of the use cases, local
learning through data plane should be sufficient. learning through data plane should be sufficient.
o Remote learning defines the procedures used for learning MAC o Remote learning defines the procedures used for learning MAC
addresses of network elements remotely connected to a MAC-VRF, addresses of network elements remotely connected to a MAC-VRF,
i.e. far-end PEs. Remote learning procedures defined in [EVPN] i.e. far-end PEs. Remote learning procedures defined in [RFC7432]
advocate using only control plane learning; specifically BGP. advocate using only control plane learning; specifically BGP.
Through the use of BGP EVPN NLRIs, the remote PE has the Through the use of BGP EVPN NLRIs, the remote PE has the
capability of advertising all the MAC addresses present in its capability of advertising all the MAC addresses present in its
local FIB. local FIB.
8.1.2. Proxy-ARP/ND 8.1.2. Proxy-ARP/ND
In EVPN, MAC addresses are advertised via the MAC/IP Advertisement In EVPN, MAC addresses are advertised via the MAC/IP Advertisement
Route, as discussed in [EVPN]. Optionally an IP address can be Route, as discussed in [RFC7432]. Optionally an IP address can be
advertised along with the MAC address announcement. However, there advertised along with the MAC address announcement. However, there
are certain rules put in place in terms of IP address usage: if the are certain rules put in place in terms of IP address usage: if the
MAC Advertisement Route contains an IP address, and the IP Address MAC Advertisement Route contains an IP address, and the IP Address
Length is 32 bits (or 128 in the IPv6 case), this particular IP Length is 32 bits (or 128 in the IPv6 case), this particular IP
address correlates directly with the advertised MAC address. Such address correlates directly with the advertised MAC address. Such
advertisement allows us to build a proxy-ARP/ND table populated with advertisement allows us to build a proxy-ARP/ND table populated with
the IP<>MAC bindings received from all the remote nodes. the IP<>MAC bindings received from all the remote nodes.
Furthermore, based on these bindings, a local MAC-VRF can now provide Furthermore, based on these bindings, a local MAC-VRF can now provide
Proxy-ARP/ND functionality for all ARP requests and ND solicitations Proxy-ARP/ND functionality for all ARP requests and ND solicitations
skipping to change at page 28, line 11 skipping to change at page 28, line 18
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
10. Security Considerations 10. Security Considerations
Please refer to the "Security Considerations" section in [RFC7432].
11. IANA Considerations 11. IANA Considerations
No new IANA considerations are needed.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN [RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN
Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761,
January 2007, <http://www.rfc-editor.org/info/rfc4761>. DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>.
[RFC4762]Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC4762]Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007, <http://www.rfc- Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
editor.org/info/rfc4762>. <http://www.rfc-editor.org/info/rfc4762>.
[RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo, [RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual
Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc- Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January
editor.org/info/rfc6074>. 2011, <http://www.rfc-editor.org/info/rfc6074>.
[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, February 2006, <http://www.rfc- Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[RFC7209]Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., [RFC7209]Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)",
RFC 7209, May 2014, <http://www.rfc-editor.org/info/rfc7209>. RFC 7209, DOI 10.17487/RFC7209, May 2014, <http://www.rfc-
editor.org/info/rfc7209>.
[RFC7117]Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117]Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C.
Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)",
RFC 7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>. RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-
editor.org/info/rfc7117>.
[RFC709] A. Sajassi, R. Aggarwal et al., "Requirements for Ethernet [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
VPN", RFC7209, May 2014 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>.
12.2. Informative References 12.2. Informative References
[EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-10.txt, work in progress, October, 2014
[EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in
EVPN", draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05.txt EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-00.txt
13. Acknowledgments 13. Acknowledgments
The authors want to thank Giles Heron for his detailed review of the The authors want to thank Giles Heron for his detailed review of the
document. We also thank Stefan Plug for his comments. document. We also thank Stefan Plug for his comments.
This document was prepared using 2-Word-v2.0.template.dot.
14. Authors' Addresses 14. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Alcatel-Lucent
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@alcatel-lucent.com
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@alcatel-lucent.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.com
Florin Balus Florin Balus
Alcatel-Lucent Alcatel-Lucent
Email: Florin.Balus@alcatel-lucent.com Email: Florin.Balus@alcatel-lucent.com
Keyur Patel Keyur Patel
Cisco Cisco
Email: keyupate@cisco.com Email: keyupate@cisco.com
Ali Sajassi Ali Sajassi
 End of changes. 38 change blocks. 
66 lines changed or deleted 75 lines changed or added

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