draft-ietf-bess-evpn-usage-01.txt   draft-ietf-bess-evpn-usage-02.txt 
L2VPN Workgroup J. Rabadan BESS Workgroup J. Rabadan, Ed.
Internet Draft S. Palislamovic Internet Draft S. Palislamovic
W. Henderickx W. Henderickx
Intended status: Informational F. Balus Intended status: Informational Nokia
Alcatel-Lucent
J. Uttaro K. Patel J. Uttaro K. Patel
AT&T A. Sajassi AT&T A. Sajassi
Cisco Cisco
A. Isaac T. Boyes A. Isaac
T. Boyes Bloomberg Juniper
Bloomberg
Expires: January 5, 2016 July 4, 2015 Expires: September 20, 2016 March 19, 2016
Usage and applicability of BGP MPLS based Ethernet VPN Usage and applicability of BGP MPLS based Ethernet VPN
draft-ietf-bess-evpn-usage-01.txt draft-ietf-bess-evpn-usage-02
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 [RFC7432], 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.
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 January 5, 2015. This Internet-Draft will expire on September 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use-case scenario description . . . . . . . . . . . . . . . . . 4 2. Use-case scenario description . . . . . . . . . . . . . . . . . 4
3. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 6 3. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Common provisioning tasks . . . . . . . . . . . . . . . . . 7 3.1. Common provisioning tasks . . . . . . . . . . . . . . . . . 6
3.1.1. Non-service specific parameters . . . . . . . . . . . . 7 3.1.1. Non-service specific parameters . . . . . . . . . . . . 7
3.1.2. Service specific parameters . . . . . . . . . . . . . . 8 3.1.2. Service specific parameters . . . . . . . . . . . . . . 7
3.2. Service interface dependent provisioning tasks . . . . . . 8 3.2. Service interface dependent provisioning tasks . . . . . . 8
3.2.1. VLAN-based service interface EVI . . . . . . . . . . . 8 3.2.1. VLAN-based service interface EVI . . . . . . . . . . . 8
3.2.2. VLAN-bundle service interface EVI . . . . . . . . . . . 9 3.2.2. VLAN-bundle service interface EVI . . . . . . . . . . . 9
3.2.3. VLAN-aware bundling service interface EVI . . . . . . . 9 3.2.3. VLAN-aware bundling service interface EVI . . . . . . . 9
4. BGP EVPN NLRI usage . . . . . . . . . . . . . . . . . . . . . . 9 4. BGP EVPN NLRI usage . . . . . . . . . . . . . . . . . . . . . . 9
5. MAC-based forwarding model use-case . . . . . . . . . . . . . . 10 5. MAC-based forwarding model use-case . . . . . . . . . . . . . . 10
5.1. EVPN Network Startup procedures . . . . . . . . . . . . . . 10 5.1. EVPN Network Startup procedures . . . . . . . . . . . . . . 10
5.2. VLAN-based service procedures . . . . . . . . . . . . . . . 11 5.2. VLAN-based service procedures . . . . . . . . . . . . . . . 11
5.2.1. Service startup procedures . . . . . . . . . . . . . . 11 5.2.1. Service startup procedures . . . . . . . . . . . . . . 11
5.2.2. Packet walkthrough . . . . . . . . . . . . . . . . . . 12 5.2.2. Packet walkthrough . . . . . . . . . . . . . . . . . . 12
5.3. VLAN-bundle service procedures . . . . . . . . . . . . . . 15 5.3. VLAN-bundle service procedures . . . . . . . . . . . . . . 15
5.3.1. Service startup procedures . . . . . . . . . . . . . . 15 5.3.1. Service startup procedures . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . 20 service procedures . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document complements [RFC7432] by discussing the applicability This document complements [RFC7432] by discussing the applicability
of 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
skipping to change at page 6, line 17 skipping to change at page 6, line 17
NOTE: in section 3.2.1, only EVI100 is used as an example of NOTE: in section 3.2.1, only EVI100 is used as an example of
VLAN-based service provisioning. In sections 5.2 and 6.2, 4k VLAN-based service provisioning. In sections 5.2 and 6.2, 4k
VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC
vs. MPLS disposition models in the control plane can be evaluated. In vs. MPLS disposition models in the control plane can be evaluated. In
the same way, EVI200 and EVI300 will be described with a 4k:1 mapping the same way, EVI200 and EVI300 will be described with a 4k:1 mapping
(CE-VIDs-to-EVI mapping) in sections 5.3-4 and 6.3-4. (CE-VIDs-to-EVI mapping) in sections 5.3-4 and 6.3-4.
o BUM (Broadcast, Unknown unicast, Multicast) optimization o BUM (Broadcast, Unknown unicast, Multicast) optimization
requirements: The solution must be able to support ingress requirements: The solution must be able to support ingress
replication, P2MP MPLS LSPs and MP2MP MPLS LSPs and the user must replication and P2MP MPLS LSPs and the user must be able to decide
be able to decide what kind of provider tree will be used by each what kind of provider tree will be used by each EVI service. For
EVI service. For example, if we assume that EVI100 and EVI200 will example, if we assume that EVI100 and EVI200 will not carry much
not carry much BUM traffic, we can use ingress replication for BUM traffic, we can use ingress replication for those service
those service instances. The benefit is that the core will not need instances. The benefit is that the core will not need to maintain
to maintain any states for the multicast trees associated to EVI100 any states for the multicast trees associated to EVI100 and EVI200.
and EVI200. On the contrary, if EVI300 is presumably carrying a On the contrary, if EVI300 is presumably carrying a significant
significant amount of multicast traffic, P2MP MPLS LSPs or MP2MP amount of multicast traffic, P2MP MPLS LSPs can be used for this
LSPs can be used for this service. Note that ingress replication service.
and P2MP LSPs are supported by VPLS solutions (see [VPLS-MCAST]),
however VPLS solutions do not support MP2MP LSPs, since the source
of the tree must be identified for the data plane MAC learning, and
that identification is challenging when using MP2MP LSPs. Since
EVPN uses the control plane for MAC learning, any type of provider
multicast tree is supported in the core.
As already outlined above, the current VPLS solutions, based on The current VPLS solutions, based on [RFC4761][RFC4762][RFC6074],
[RFC4761][RFC4762][RFC6074], cannot meet all the above set of cannot meet all the above set of requirements and therefore a new
requirements and therefore a new solution is needed. The rest of the solution is needed. The rest of the document will describe how EVPN
document will describe how EVPN can be used to meet those service can be used to meet those service requirements and even optimize the
requirements and even optimize the network further by: network further by:
o Providing the user with an option to reduce (and even suppress) the o Providing the user with an option to reduce (and even suppress) the
ARP-flooding. ARP-flooding.
o Supporting ARP termination for inter-subnet forwarding o Supporting ARP termination for inter-subnet forwarding
3. Provisioning Model 3. Provisioning Model
One of the requirements stated in [RFC7209] is the ease of One of the requirements stated in [RFC7209] is the ease of
provisioning. BGP parameters and service context parameters should be provisioning. BGP parameters and service context parameters should be
skipping to change at page 9, line 14 skipping to change at page 9, line 7
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
[RFC7432], 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 2 or 4-byte value where the low order 12
the VID (VID 100 in our example) and the high order 20 bits are bits are the VID (VID 100 in our example) and the high order bits
zero. Note that auto-deriving the RT implies supporting a basic are zero. Note that auto-deriving the RT implies supporting a basic
any-to-any topology in the EVI and using the same import and export any-to-any topology in the EVI and using the same import and export
RT in the EVI. RT in the EVI.
If EVI100 is not a "unique-VLAN" EVPN, each individual CE-VID must be If EVI100 is not a "unique-VLAN" EVPN, each individual CE-VID must be
configured in each PE, and MAC-VRF RDs and RTs cannot be auto- configured in each PE, and MAC-VRF RDs and RTs cannot be auto-
derived, hence they must be provisioned by the user. derived, hence they must be provisioned by the user.
3.2.2. VLAN-bundle service interface EVI 3.2.2. VLAN-bundle service interface EVI
Assuming EVI200 is a VLAN-bundle service interface EVI, and VIDs Assuming EVI200 is a VLAN-bundle service interface EVI, and VIDs
skipping to change at page 10, line 46 skipping to change at page 10, line 39
different service types, we will assume that CE1, CE2 and CE3 need to different service types, we will assume that CE1, CE2 and CE3 need to
exchange traffic for up to 4k CE-VIDs. exchange traffic for up to 4k CE-VIDs.
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 and P2MP LSPs. In addition to the MPLS transport, PE1 and PE2
and PE2 must be properly configured with the same LACP must be properly configured with the same LACP configuration to
configuration to CE2. Details are provided in [RFC7432]. Once the CE2. Details are provided in [RFC7432]. Once the LAG is properly
LAG is properly setup, the ESI for the CE2 Ethernet Segment, e.g. setup, the ESI for the CE2 Ethernet Segment, e.g. ESI12, can be
ESI12, can be auto-generated by PE1 and PE2 from the LACP auto-generated by PE1 and PE2 from the LACP information exchanged
information exchanged with CE2 (ESI type 1), as discussed in with CE2 (ESI type 1), as discussed in section 3.1. Alternatively,
section 3.1. Alternatively, the ESI can also be manually the ESI can also be manually provisioned on PE1 and PE2 (ESI type
provisioned on PE1 and PE2 (ESI type 0). PE1 and PE2 will auto- 0). PE1 and PE2 will auto-configure a BGP policy that will import
configure a BGP policy that will import any ES route matching the 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
3.1.1. PE1 and PE2 will import the ES routes of each other and will 3.1.1. PE1 and PE2 will import the ES routes of each other and will
run the DF election algorithm for any existing EVI (if any, at this run the DF election algorithm for any existing EVI (if any, at this
point). PE3 will simply discard the route. Note that the DF point). PE3 will simply discard the route. Note that the DF
election algorithm can support service carving, so that the election algorithm can support service carving, so that the
downstream BUM traffic from the network to CE2 can be load-balanced downstream BUM traffic from the network to CE2 can be load-balanced
across PE1 and PE2 on a per-service basis. across PE1 and PE2 on a per-service basis.
skipping to change at page 11, line 44 skipping to change at page 11, line 35
is provisioned in the network. is provisioned in the network.
5.2.1. Service startup procedures 5.2.1. Service startup procedures
As soon as the EVIs are created in PE1, PE2 and PE3, the following As soon as the EVIs are created in PE1, PE2 and PE3, the following
control plane actions are carried out: control plane actions are carried out:
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 or P2MP LSPs can optionally be signaled in the
signaled in the PMSI Tunnel attribute and the corresponding tree be 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). As per [RFC7432], each total number of RTs can be conveyed). As per [RFC7432], each
Ethernet A-D route per ESI is differentiated from the other routes Ethernet A-D route per ESI is differentiated from the other routes
in the set by a different Route Distinguisher (ES RD. This set will in the set by a different Route Distinguisher (ES RD). This set
also include ESI Label extended communities with the active-standby will also include ESI Label extended communities with the active-
flag set to zero (all-active multi-homing type) and an ESI Label standby flag set to zero (all-active multi-homing type) and an ESI
different from zero (used for split-horizon functions). These Label different from zero (used for split-horizon functions). These
routes will be imported by the three PEs, since the RTs match the 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 EVI RTs locally configured. The A-D routes per ESI will be used for
fast convergence and split-horizon functions, as discussed in fast convergence and split-horizon functions, as discussed in
[RFC7432]. [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.
skipping to change at page 16, line 6 skipping to change at page 15, line 44
VID translation in the Provider network. VID translation in the Provider network.
5.3.1. Service startup procedures 5.3.1. Service startup procedures
As soon as the EVI200 is created in PE1, PE2 and PE3, the following As soon as the EVI200 is created in PE1, PE2 and PE3, the following
control plane actions are carried out: control plane actions are carried out:
o Flooding tree setup per EVI (one route): Each PE will send one o Flooding tree setup per EVI (one route): Each PE will send one
Inclusive Multicast Ethernet Tag route per EVI (hence only one Inclusive Multicast Ethernet Tag route per EVI (hence only one
route per PE) so that the flooding tree per EVI can be setup. Note route per PE) so that the flooding tree per EVI can be setup. Note
that ingress replication, P2MP LSPs or MP2MP LSPs can optionally that ingress replication or P2MP LSPs can optionally be signaled
be signaled in the PMSI Tunnel attribute and the corresponding in the PMSI Tunnel attribute and the corresponding tree be
tree be created. 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 convergence and split-horizon functions, as described in
skipping to change at page 17, line 14 skipping to change at page 17, line 4
VLAN-bundle service type in the previous section, is that each VLAN-bundle service type in the previous section, is that each
incoming CE-VID will also be mapped to a different "normalized" incoming CE-VID will also be mapped to a different "normalized"
Ethernet-Tag in addition to EVI300. If no translation is required, Ethernet-Tag in addition to EVI300. If no translation is required,
the Ethernet-tag will match the CE-VID. Otherwise a translation the Ethernet-tag will match the CE-VID. Otherwise a translation
between CE-VID and Ethernet-tag will be needed at the imposition PE between CE-VID and Ethernet-tag will be needed at the imposition PE
and at the disposition PE. The main advantage of this approach is the and at the disposition PE. The main advantage of this approach is the
ability to control customer broadcast domains while providing a ability to control customer broadcast domains while providing a
single EVI to the customer. single EVI to the customer.
5.4.1. Service startup procedures 5.4.1. Service startup procedures
As soon as the EVI300 is created in PE1, PE2 and PE3, the following As soon as the EVI300 is created in PE1, PE2 and PE3, the following
control plane actions are carried out: control plane actions are carried out:
o Flooding tree setup per EVI per Ethernet-Tag (4k routes): Each PE o Flooding tree setup per EVI per Ethernet-Tag (4k routes): Each PE
will send one Inclusive Multicast Ethernet Tag route per EVI and will send one Inclusive Multicast Ethernet Tag route per EVI and
per Ethernet-Tag (hence 4k routes per PE) so that the flooding per Ethernet-Tag (hence 4k routes per PE) so that the flooding
tree per customer broadcast domain can be setup. Note that ingress tree per customer broadcast domain can be setup. Note that ingress
replication, P2MP LSPs or MP2MP LSPs can optionally be signaled in replication or P2MP LSPs can optionally be signaled in the PMSI
the PMSI Tunnel attribute and the corresponding tree be created. Tunnel attribute and the corresponding tree be created. In the
In the described use-case, since all the CE-VIDs and Ethernet-Tags described use-case, since all the CE-VIDs and Ethernet-Tags are
are defined on the three PEs, multicast tree aggregation might defined on the three PEs, multicast tree aggregation might make
make sense in order to save forwarding states. 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 convergence and split-horizon functions, as described in
skipping to change at page 23, line 42 skipping to change at page 23, line 31
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 [RFC7432]. 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
directed to the IP address pool learned through BGP. Therefore, the directed to the IP address pool learned through BGP. Therefore, the
amount of unnecessary L2 flooding, ARP/ND requests/solicitations in amount of unnecessary L2 flooding, ARP/ND requests/solicitations in
this case, can be further reduced by the introduction of Proxy-ARP/ND this case, can be further reduced by the introduction of Proxy-ARP/ND
functionality across all EVI MAC-VRFs. functionality across all EVI MAC-VRFs.
8.1.3. Unknown Unicast flooding suppression 8.1.3. Unknown Unicast flooding suppression
Given that all locally learned MAC addresses are advertised through Given that all locally learned MAC addresses are advertised through
BGP to all remote PEs, suppressing flooding of any Unknown Unicast BGP to all remote PEs, suppressing flooding of any Unknown Unicast
traffic towards the remote PEs is a feasible network optimization. traffic towards the remote PEs is a feasible network optimization.
The assumption in the use case is made that any network device that The assumption in the use case is made that any network device that
appears on a remote MAC-VRF will somehow signal its presence to the appears on a remote MAC-VRF will somehow signal its presence to the
network. This signaling can be done through e.g. gratuitous ARPs. network. This signaling can be done through e.g. gratuitous ARPs.
Once the remote PE acknowledges the presence of the node in the MAC- Once the remote PE acknowledges the presence of the node in the MAC-
VRF, it will do two things: install its MAC address in its local FIB VRF, it will do two things: install its MAC address in its local FIB
and advertise this MAC address to all other BGP speakers via EVPN and advertise this MAC address to all other BGP speakers via EVPN
skipping to change at page 29, line 18 skipping to change at page 29, line 8
editor.org/info/rfc7117>. editor.org/info/rfc7117>.
[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>.
12.2. Informative References 12.2. Informative References
[EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-00.txt EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-01.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, and Eric Wunan for their
comments.
14. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Florin Balus
14. Authors' Addresses 14. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Nokia
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@nokia.com
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Nokia
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@nokia.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Florin Balus
Alcatel-Lucent
Email: Florin.Balus@alcatel-lucent.com
Keyur Patel Keyur Patel
Cisco Cisco
Email: keyupate@cisco.com Email: keyupate@cisco.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
James Uttaro James Uttaro
AT&T AT&T
Email: uttaro@att.com Email: uttaro@att.com
Aldrin Isaac Aldrin Isaac
Bloomberg Juniper Networks
Email: aisaac71@bloomberg.net Email: aisaac@juniper.net
Truman Boyes Truman Boyes
Bloomberg Bloomberg
Email: tboyes@bloomberg.net Email: tboyes@bloomberg.net
 End of changes. 31 change blocks. 
79 lines changed or deleted 73 lines changed or added

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