draft-ietf-l2vpn-pbb-evpn-04.txt   draft-ietf-l2vpn-pbb-evpn-05.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Florin Balus Nabil Bitar Florin Balus Nabil Bitar
Wim Henderickx Verizon Wim Henderickx Verizon
Alcatel-Lucent Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Clarence Filsfils Bloomberg Clarence Filsfils Bloomberg
Dennis Cai Dennis Cai
Cisco Lizhong Jin Cisco Lizhong Jin
ZTE ZTE
Expires: August 25, 2013 February 25, 2013 Expires: January 16, 2014 July 16, 2013
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-04 draft-ietf-l2vpn-pbb-evpn-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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.
Abstract Abstract
This document discusses how Ethernet Provider Backbone Bridging This document discusses how Ethernet Provider Backbone Bridging
[802.1ah] can be combined with E-VPN in order to reduce the number of [802.1ah] can be combined with EVPN in order to reduce the number of
BGP MAC advertisement routes by aggregating Customer/Client MAC (C- BGP MAC advertisement routes by aggregating Customer/Client MAC (C-
MAC) addresses via Provider Backbone MAC address (B-MAC), provide MAC) addresses via Provider Backbone MAC address (B-MAC), provide
client MAC address mobility using C-MAC aggregation and B-MAC sub- client MAC address mobility using C-MAC aggregation and B-MAC sub-
netting, confine the scope of C-MAC learning to only active flows, netting, confine the scope of C-MAC learning to only active flows,
offer per site policies and avoid C-MAC address flushing on topology offer per site policies and avoid C-MAC address flushing on topology
changes. The combined solution is referred to as PBB-EVPN. changes. The combined solution is referred to as PBB-EVPN.
Conventions Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 10 skipping to change at page 3, line 10
7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8 7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8
7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 8 7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 8
7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 8 7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 8
7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 8 7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 8
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 10 7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 10
7.2.1.3 Split Horizon and Designated Forwarder Election . . 11 7.2.1.3 Split Horizon and Designated Forwarder Election . . 11
7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 11 7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 11
7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 11 7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 11
7.2.2.2 Split Horizon and Designated Forwarder Election . . 12 7.2.2.2 Split Horizon and Designated Forwarder Election . . 12
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12 7.2.2.3 Handling Failure Scenarios . . . . . . . . . . . . . 12
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 12 7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 13
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 13 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 14
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 13 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14
9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 14 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 15
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 14 9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 15
9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 15
10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 15 9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 15 10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 16
10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 16 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 16
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 16 10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 17
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 17
10.4. Seamless Interworking with TRILL and 802.1aq Access 10.4. Seamless Interworking with TRILL and 802.1aq Access
Networks . . . . . . . . . . . . . . . . . . . . . . . . 16 Networks . . . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 17 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 18
10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 17 10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Intellectual Property Considerations . . . . . . . . . . . . 18 14. Intellectual Property Considerations . . . . . . . . . . . . 19
15. Normative References . . . . . . . . . . . . . . . . . . . . 18 15. Normative References . . . . . . . . . . . . . . . . . . . . 19
16. Informative References . . . . . . . . . . . . . . . . . . . 18 16. Informative References . . . . . . . . . . . . . . . . . . . 19
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[E-VPN] introduces a solution for multipoint L2VPN services, with [EVPN] introduces a solution for multipoint L2VPN services, with
advanced multi-homing capabilities, using BGP for distributing advanced multi-homing capabilities, using BGP for distributing
customer/client MAC address reach-ability information over the core customer/client MAC address reach-ability information over the core
MPLS/IP network. [802.1ah] defines an architecture for Ethernet MPLS/IP network. [802.1ah] defines an architecture for Ethernet
Provider Backbone Bridging (PBB), where MAC tunneling is employed to Provider Backbone Bridging (PBB), where MAC tunneling is employed to
improve service instance and MAC address scalability in Ethernet as improve service instance and MAC address scalability in Ethernet as
well as VPLS networks [PBB-VPLS]. well as VPLS networks [PBB-VPLS].
In this document, we discuss how PBB can be combined with E-VPN in In this document, we discuss how PBB can be combined with EVPN in
order to: reduce the number of BGP MAC advertisement routes by order to: reduce the number of BGP MAC advertisement routes by
aggregating Customer/Client MAC (C-MAC) addresses via Provider aggregating Customer/Client MAC (C-MAC) addresses via Provider
Backbone MAC address (B-MAC), provide client MAC address mobility Backbone MAC address (B-MAC), provide client MAC address mobility
using C-MAC aggregation and B-MAC sub-netting, confine the scope of using C-MAC aggregation and B-MAC sub-netting, confine the scope of
C-MAC learning to only active flows, offer per site policies and C-MAC learning to only active flows, offer per site policies and
avoid C-MAC address flushing on topology changes. The combined avoid C-MAC address flushing on topology changes. The combined
solution is referred to as PBB-EVPN. solution is referred to as PBB-EVPN.
2. Contributors 2. Contributors
skipping to change at page 4, line 50 skipping to change at page 4, line 50
DHN: Dual-homed Network DHN: Dual-homed Network
LACP: Link Aggregation Control Protocol LACP: Link Aggregation Control Protocol
LSM: Label Switched Multicast LSM: Label Switched Multicast
MDT: Multicast Delivery Tree MDT: Multicast Delivery Tree
MP2MP: Multipoint to Multipoint MP2MP: Multipoint to Multipoint
P2MP: Point to Multipoint P2MP: Point to Multipoint
P2P: Point to Point P2P: Point to Point
PE: Provider Edge PE: Provider Edge
PoA: Point of Attachment PoA: Point of Attachment
PW: Pseudowire PW: Pseudowire
E-VPN: Ethernet VPN EVPN: Ethernet VPN
4. Requirements 4. Requirements
The requirements for PBB-EVPN include all the requirements for E-VPN The requirements for PBB-EVPN include all the requirements for EVPN
that were described in [EVPN-REQ], in addition to the following: that were described in [EVPN-REQ], in addition to the following:
4.1. MAC Advertisement Route Scalability 4.1. MAC Advertisement Route Scalability
In typical operation, an [E-VPN] PE sends a BGP MAC Advertisement In typical operation, an [EVPN] PE sends a BGP MAC Advertisement
Route per customer/client MAC (C-MAC) address. In certain Route per customer/client MAC (C-MAC) address. In certain
applications, this poses scalability challenges, as is the case in applications, this poses scalability challenges, as is the case in
virtualized data center environments where the number of virtual virtualized data center environments where the number of virtual
machines (VMs), and hence the number of C-MAC addresses, can be in machines (VMs), and hence the number of C-MAC addresses, can be in
the millions. In such scenarios, it is required to reduce the number the millions. In such scenarios, it is required to reduce the number
of BGP MAC Advertisement routes by relying on a 'MAC summarization' of BGP MAC Advertisement routes by relying on a 'MAC summarization'
scheme, as is provided by PBB. Note that the MAC summarization scheme, as is provided by PBB. Note that the MAC summarization
capability already built into E-VPN is not sufficient in those capability already built into EVPN is not sufficient in those
environments, as will be discussed next. environments, as will be discussed next.
4.2. C-MAC Mobility with MAC Summarization 4.2. C-MAC Mobility with MAC Summarization
Certain applications, such as virtual machine mobility, require Certain applications, such as virtual machine mobility, require
support for fast C-MAC address mobility. For these applications, it support for fast C-MAC address mobility. For these applications, it
is not possible to use MAC address summarization in E-VPN, i.e. is not possible to use MAC address summarization in EVPN, i.e.
advertise reach-ability to a MAC address prefix. Rather, the exact advertise reach-ability to a MAC address prefix. Rather, the exact
virtual machine MAC address needs to be transmitted in BGP MAC virtual machine MAC address needs to be transmitted in BGP MAC
Advertisement route. Otherwise, traffic would be forwarded to the Advertisement route. Otherwise, traffic would be forwarded to the
wrong segment when a virtual machine moves from one Ethernet segment wrong segment when a virtual machine moves from one Ethernet segment
to another. This hinders the scalability benefits of summarization. to another. This hinders the scalability benefits of summarization.
It is required to support C-MAC address mobility, while retaining the It is required to support C-MAC address mobility, while retaining the
scalability benefits of MAC summarization. This can be achieved by scalability benefits of MAC summarization. This can be achieved by
leveraging PBB technology, which defines a Backbone MAC (B-MAC) leveraging PBB technology, which defines a Backbone MAC (B-MAC)
address space that is independent of the C-MAC address space, and address space that is independent of the C-MAC address space, and
aggregate C-MAC addresses via a B-MAC address and then apply aggregate C-MAC addresses via a B-MAC address and then apply
summarization to B-MAC addresses. summarization to B-MAC addresses.
4.3. C-MAC Address Learning and Confinement 4.3. C-MAC Address Learning and Confinement
In E-VPN, all the PE nodes participating in the same E-VPN instance In EVPN, all the PE nodes participating in the same EVPN instance are
are exposed to all the C-MAC addresses learnt by any one of these PE exposed to all the C-MAC addresses learnt by any one of these PE
nodes because a C-MAC learned by one of the PE nodes is advertise in nodes because a C-MAC learned by one of the PE nodes is advertise in
BGP to other PE nodes in that E-VPN instance. This is the case even BGP to other PE nodes in that EVPN instance. This is the case even if
if some of the PE nodes for that E-VPN instance are not involved in some of the PE nodes for that EVPN instance are not involved in
forwarding traffic to, or from, these C-MAC addresses. Even if an forwarding traffic to, or from, these C-MAC addresses. Even if an
implementation does not install hardware forwarding entries for C-MAC implementation does not install hardware forwarding entries for C-MAC
addresses that are not part of active traffic flows on that PE, the addresses that are not part of active traffic flows on that PE, the
device memory is still consumed by keeping record of the C-MAC device memory is still consumed by keeping record of the C-MAC
addresses in the routing table (RIB). In network applications with addresses in the routing table (RIB). In network applications with
millions of C-MAC addresses, this introduces a non-trivial waste of millions of C-MAC addresses, this introduces a non-trivial waste of
PE resources. As such, it is required to confine the scope of PE resources. As such, it is required to confine the scope of
visibility of C-MAC addresses only to those PE nodes that are visibility of C-MAC addresses only to those PE nodes that are
actively involved in forwarding traffic to, or from, these addresses. actively involved in forwarding traffic to, or from, these addresses.
4.4. Per Site Policy Support 4.4. Per Site Policy Support
In many applications, it is required to be able to enforce In many applications, it is required to be able to enforce
connectivity policy rules at the granularity of a site (or segment). connectivity policy rules at the granularity of a site (or segment).
This includes the ability to control which PE nodes in the network This includes the ability to control which PE nodes in the network
can forward traffic to, or from, a given site. PBB-EVPN is capable of can forward traffic to, or from, a given site. PBB-EVPN is capable of
providing this granularity of policy control. In the case where per providing this granularity of policy control. In the case where per
C-MAC address granularity is required, the EVI can always continue to C-MAC address granularity is required, the EVI can always continue to
operate in E-VPN mode. operate in EVPN mode.
4.5. Avoiding C-MAC Address Flushing 4.5. Avoiding C-MAC Address Flushing
It is required to avoid C-MAC address flushing upon link, port or It is required to avoid C-MAC address flushing upon link, port or
node failure for multi-homed devices and networks. This is in order node failure for multi-homed devices and networks. This is in order
to speed up re-convergence upon failure. to speed up re-convergence upon failure.
5. Solution Overview 5. Solution Overview
The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge
(BEB) functionality on the E-VPN PE nodes similar to PBB-VPLS, where (BEB) functionality on the EVPN PE nodes similar to PBB-VPLS, where
BEB functionality is incorporated in the VPLS PE nodes. The PE BEB functionality is incorporated in the VPLS PE nodes. The PE
devices would then receive 802.1Q Ethernet frames from their devices would then receive 802.1Q Ethernet frames from their
attachment circuits, encapsulate them in the PBB header and forward attachment circuits, encapsulate them in the PBB header and forward
the frames over the IP/MPLS core. On the egress E-VPN PE, the PBB the frames over the IP/MPLS core. On the egress EVPN PE, the PBB
header is removed following the MPLS disposition, and the original header is removed following the MPLS disposition, and the original
802.1Q Ethernet frame is delivered to the customer equipment. 802.1Q Ethernet frame is delivered to the customer equipment.
BEB +--------------+ BEB BEB +--------------+ BEB
|| | | || || | | ||
\/ | | \/ \/ | | \/
+----+ AC1 +----+ | | +----+ +----+ +----+ AC1 +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE2| | CE1|-----| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+ +----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+ \ +----+ | Network | +----+
\ | | \ | |
skipping to change at page 7, line 22 skipping to change at page 7, line 22
all other PE nodes in the same set of service instances. Note that all other PE nodes in the same set of service instances. Note that
every PE has a set of local B-MAC addresses that uniquely identify every PE has a set of local B-MAC addresses that uniquely identify
the device. More on the PE addressing in section 5. the device. More on the PE addressing in section 5.
- Build a forwarding table from remote BGP advertisements received - Build a forwarding table from remote BGP advertisements received
associating remote B-MAC addresses with remote PE IP addresses and associating remote B-MAC addresses with remote PE IP addresses and
the associated MPLS label(s). the associated MPLS label(s).
6. BGP Encoding 6. BGP Encoding
PBB-EVPN leverages the same BGP Routes and Attributes defined in [E- PBB-EVPN leverages the same BGP Routes and Attributes defined in
VPN], adapted as follows: [EVPN], adapted as follows:
6.1. BGP MAC Advertisement Route 6.1. BGP MAC Advertisement Route
The E-VPN MAC Advertisement Route is used to distribute B-MAC The EVPN MAC Advertisement Route is used to distribute B-MAC
addresses of the PE nodes instead of the C-MAC addresses of end- addresses of the PE nodes instead of the C-MAC addresses of end-
stations/hosts. This is because the C-MAC addresses are learnt in the stations/hosts. This is because the C-MAC addresses are learnt in the
data-plane for traffic arriving from the core. The MAC Advertisement data-plane for traffic arriving from the core. The MAC Advertisement
Route is encoded as follows: Route is encoded as follows:
- The MAC address field contains the B-MAC address. - The MAC address field contains the B-MAC address.
- The Ethernet Tag field is set to 0. - The Ethernet Tag field is set to 0.
- The Ethernet Segment Identifier field must be set either to 0 (for - The Ethernet Segment Identifier field must be set either to 0 (for
single-homed Segments) or to MAX-ESI (for multi-homed Segments). All single-homed Segments or multi-homed Segments with per-ISID load-
other values are not permitted. balancing) or to MAX-ESI (for multi-homed Segments with per-flow
load-balancing). All other values are not permitted.
The route is tagged with the RT corresponding to the EVI associated The route is tagged with the RT corresponding to the EVI associated
with the B-MAC address. with the B-MAC address.
All other fields are set as defined in [E-VPN]. All other fields are set as defined in [EVPN].
6.2. Ethernet Auto-Discovery Route 6.2. Ethernet Auto-Discovery Route
This route and all of its associated modes are not needed in PBB- This route and all of its associated modes are not needed in PBB-
EVPN. EVPN.
The receiving PE knows that it need not wait for the receipt of the The receiving PE knows that it need not wait for the receipt of the
Ethernet A-D route for route resolution by means of the reserved ESI Ethernet A-D route for route resolution by means of the reserved ESI
encoded in the MAC Advertisement route: the ESI values of 0 and MAX- encoded in the MAC Advertisement route: the ESI values of 0 and MAX-
ESI indicate that the receiving PE can resolve the path without an ESI indicate that the receiving PE can resolve the path without an
Ethernet A-D route. Ethernet A-D route.
6.3. Per VPN Route Targets 6.3. Per VPN Route Targets
PBB-EVPN uses the same set of route targets defined in [E-VPN]. The PBB-EVPN uses the same set of route targets defined in [EVPN]. The
future revision of this document will describe new RT types. future revision of this document will describe new RT types.
6.4. MAC Mobility Extended Community 6.4. MAC Mobility Extended Community
This extended community is defined in [EVPN]. When used in PBB-EVPN, This extended community is defined in [EVPN]. When used in PBB-EVPN,
it indicates that the C-MAC forwarding tables for the I-SIDs it indicates that the C-MAC forwarding tables for the I-SIDs
associated with the RT tagging the MAC Advertisement route must be associated with the RT tagging the MAC Advertisement route must be
flushed. flushed.
Note that all other BGP messages and/or attributes are used as Note that all other BGP messages and/or attributes are used as
defined in [E-VPN]. defined in [EVPN].
7. Operation 7. Operation
This section discusses the operation of PBB-EVPN, specifically in This section discusses the operation of PBB-EVPN, specifically in
areas where it differs from [E-VPN]. areas where it differs from [EVPN].
7.1. MAC Address Distribution over Core 7.1. MAC Address Distribution over Core
In PBB-EVPN, host MAC addresses (i.e. C-MAC addresses) need not be In PBB-EVPN, host MAC addresses (i.e. C-MAC addresses) need not be
distributed in BGP. Rather, every PE independently learns the C-MAC distributed in BGP. Rather, every PE independently learns the C-MAC
addresses in the data-plane via normal bridging operation. Every PE addresses in the data-plane via normal bridging operation. Every PE
has a set of one or more unicast B-MAC addresses associated with it, has a set of one or more unicast B-MAC addresses associated with it,
and those are the addresses distributed over the core in MAC and those are the addresses distributed over the core in MAC
Advertisement routes. Advertisement routes.
skipping to change at page 9, line 51 skipping to change at page 10, line 4
In the example network shown in Figure 2 above, two sites In the example network shown in Figure 2 above, two sites
corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3, corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3,
respectively. Assume that BM1 is the B-MAC used for the site respectively. Assume that BM1 is the B-MAC used for the site
corresponding to CE1. Similarly, BM2 is the B-MAC used for the site corresponding to CE1. Similarly, BM2 is the B-MAC used for the site
corresponding to CE2. On PE1, a single B-MAC address (BM1) is corresponding to CE2. On PE1, a single B-MAC address (BM1) is
required for the site corresponding to CE1. On PE2, two B-MAC required for the site corresponding to CE1. On PE2, two B-MAC
addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a
single B-MAC address (BM2) is required for the site corresponding to single B-MAC address (BM2) is required for the site corresponding to
CE2. All three PE nodes would advertise their respective B-MAC CE2. All three PE nodes would advertise their respective B-MAC
addresses in BGP using the MAC Advertisement routes defined in [E- addresses in BGP using the MAC Advertisement routes defined in
VPN]. The remote PE, PEr, would learn via BGP that BM1 is reachable [EVPN]. The remote PE, PEr, would learn via BGP that BM1 is reachable
via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3. via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3.
Furthermore, PEr establishes via the normal bridge learning that C- Furthermore, PEr establishes via the normal bridge learning that C-
MAC M1 is reachable via BM1, and C-MAC M2 is reachable via BM2. As a MAC M1 is reachable via BM1, and C-MAC M2 is reachable via BM2. As a
result, PEr can load-balance traffic destined to M1 between PE1 and result, PEr can load-balance traffic destined to M1 between PE1 and
PE2, as well as traffic destined to M2 between both PE2 and PE3. In PE2, as well as traffic destined to M2 between both PE2 and PE3. In
the case of a failure that causes, for example, CE1 to be isolated the case of a failure that causes, for example, CE1 to be isolated
from PE1, the latter can withdraw the route it has advertised for from PE1, the latter can withdraw the route it has advertised for
BM1. This way, PEr would update its path list for BM1, and will send BM1. This way, PEr would update its path list for BM1, and will send
all traffic destined to M1 over to PE2 only. all traffic destined to M1 over to PE2 only.
skipping to change at page 11, line 15 skipping to change at page 11, line 16
Whenever a B-MAC address is provisioned on the PE, either manually or Whenever a B-MAC address is provisioned on the PE, either manually or
automatically (as an outcome of CE auto-discovery), the PE MUST automatically (as an outcome of CE auto-discovery), the PE MUST
transmit an MAC Advertisement Route for the B-MAC address with a transmit an MAC Advertisement Route for the B-MAC address with a
downstream assigned MPLS label that uniquely identifies that address downstream assigned MPLS label that uniquely identifies that address
on the advertising PE. The route is tagged with the RTs of the on the advertising PE. The route is tagged with the RTs of the
associated EVIs as described above. associated EVIs as described above.
7.2.1.3 Split Horizon and Designated Forwarder Election 7.2.1.3 Split Horizon and Designated Forwarder Election
[E-VPN] relies on access split horizon, where the Ethernet Segment [EVPN] relies on access split horizon, where the Ethernet Segment
Label is used for egress filtering on the attachment circuit in order Label is used for egress filtering on the attachment circuit in order
to prevent forwarding loops. In PBB-EVPN, the B-MAC source address to prevent forwarding loops. In PBB-EVPN, the B-MAC source address
can be used for the same purpose, as it uniquely identifies the can be used for the same purpose, as it uniquely identifies the
originating site of a given frame. As such, Segment Labels are not originating site of a given frame. As such, Segment Labels are not
used in PBB-EVPN, and the egress split-horizon filtering is done used in PBB-EVPN, and the egress split-horizon filtering is done
based on the B-MAC source address. It is worth noting here that based on the B-MAC source address. It is worth noting here that
[802.1ah] defines this B-MAC address based filtering function as part [802.1ah] defines this B-MAC address based filtering function as part
of the I-Component options, hence no new functions are required to of the I-Component options, hence no new functions are required to
support split-horizon beyond what is already defined in [802.1ah]. support split-horizon beyond what is already defined in [802.1ah].
Given that the Segment label is not used in PBB-EVPN, the PE sets the Given that the Segment label is not used in PBB-EVPN, the PE sets the
skipping to change at page 11, line 44 skipping to change at page 11, line 45
homing in an all-active redundancy model with per-ISID load- homing in an all-active redundancy model with per-ISID load-
balancing. balancing.
7.2.2.1 PE B-MAC Address Assignment 7.2.2.1 PE B-MAC Address Assignment
In the case where per-ISID load-balancing is desired among the PE In the case where per-ISID load-balancing is desired among the PE
nodes in a given redundancy group, multiple unicast B-MAC addresses nodes in a given redundancy group, multiple unicast B-MAC addresses
are allocated per multi-homed Ethernet Segment: Each PE connected to are allocated per multi-homed Ethernet Segment: Each PE connected to
the multi-homed segment is assigned a unique B-MAC. Every PE then the multi-homed segment is assigned a unique B-MAC. Every PE then
advertises its B-MAC address using the BGP MAC advertisement route. advertises its B-MAC address using the BGP MAC advertisement route.
In this mode of operation, two B-MAC address assignment models are
possible:
- The PE may use a shared B-MAC address for multiple Ethernet
Segments. This includes the single-homed segments as well as the
multi-homed segments operating with per-ISID load-balancing mode.
- The PE may use a dedicated B-MAC address for each Ethernet Segment
operating with per-ISID load-balancing mode.
All PE implementations MUST support the shared B-MAC address model
and MAY support the dedicated B-MAC address model.
A remote PE initially floods traffic to a destination C-MAC address, A remote PE initially floods traffic to a destination C-MAC address,
located in a given multi-homed Ethernet Segment, to all the PE nodes located in a given multi-homed Ethernet Segment, to all the PE nodes
connected to that segment. Then, when reply traffic arrives at the connected to that segment. Then, when reply traffic arrives at the
remote PE, it learns (in the data-path) the B-MAC address and remote PE, it learns (in the data-path) the B-MAC address and
associated next-hop PE to use for said C-MAC address. When a PE associated next-hop PE to use for said C-MAC address.
connected to a multi-homed Ethernet Segment loses connectivity to the
segment, due to link or port failure, it withdraws the B-MAC route
previously advertised for that segment. This causes the remote PE
nodes to flush all C-MAC addresses associated with the B-MAC in
question. This is done across all I-SIDs that are mapped to the EVI
of the withdrawn MAC route.
7.2.2.2 Split Horizon and Designated Forwarder Election The procedures 7.2.2.2 Split Horizon and Designated Forwarder Election The procedures
are similar to the flow-based load-balancing case, with the only are similar to the flow-based load-balancing case, with the only
difference being that the DF filtering must be applied to unicast as difference being that the DF filtering must be applied to unicast as
well as multicast traffic, and in both core-to-segment as well as well as multicast traffic, and in both core-to-segment as well as
segment-to-core directions. segment-to-core directions.
7.2.2.3 Handling Failure Scenarios
When a PE connected to a multi-homed Ethernet Segment loses
connectivity to the segment, due to link or port failure, it needs to
notify the remote PEs to trigger C-MAC address flushing. This can be
achieved in one of two ways, depending on the B-MAC assignment model:
- If the PE uses a shared B-MAC address for multiple Ethernet
Segments, then the C-MAC flushing is signaled by means of having the
failed PE re-advertise the MAC Advertisement route for the associated
B-MAC, tagged with the MAC Mobility Extended Community attribute. The
value of the Counter field in that attribute must be incremented
prior to advertisement. This causes the remote PE nodes to flush all
C-MAC addresses associated with the B-MAC in question. This is done
across all I-SIDs that are mapped to the EVI of the withdrawn MAC
route.
- If the PE uses a dedicated B-MAC address for each Ethernet Segment
operating under per-ISID load-balancing mode, the the failed PE
simply withdraws the B-MAC route previously advertised for that
segment. This causes the remote PE nodes to flush all C-MAC addresses
associated with the B-MAC in question. This is done across all I-SIDs
that are mapped to the EVI of the withdrawn MAC route.
When a PE connected to a multi-homed Ethernet Segment fails (i.e.
node failure) or when the PE becomes completely isolated from the
EVPN network, the remote PEs will start purging the MAC Advertisement
routes that were advertised by the failed PE. This is done either as
an outcome of the remote PEs detecting that the BGP session to the
failed PE has gone down, or by having a Route Reflector withdrawing
all the routes that were advertised by the failed PE. The remote PEs,
in this case, will perform C-MAC address flushing as an outcome of
the MAC Advertisement route withdrawals.
For all failure scenarios (link/port failure, node failure and PE
node isolation), when the fault condition clears, the recovered PE
re-advertises the associated Ethernet Segment route to other members
of its Redundancy Group. This triggers the backup PE(s) in the
Redundancy Group to block the I-SIDs for which the recovered PE is a
DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address
flush notification to the remote PEs by re-advertising the MAC
Advertisement route for the associated B-MAC, with the MAC Mobility
Extended Community attribute. The value of the Counter field in that
attribute must be incremented prior to advertisement. This causes the
remote PE nodes to flush all C-MAC addresses associated with the B-
MAC in question. This is done across all I-SIDs that are mapped to
the EVI of the withdrawn MAC route.
7.3. Network Multi-homing 7.3. Network Multi-homing
When an Ethernet network is multi-homed to a set of PE nodes running When an Ethernet network is multi-homed to a set of PE nodes running
PBB-EVPN, an all-active redundancy model can be supported with per PBB-EVPN, an all-active redundancy model can be supported with per
service instance (i.e. I-SID) load-balancing. In this model, DF service instance (i.e. I-SID) load-balancing. In this model, DF
election is performed to ensure that a single PE node in the election is performed to ensure that a single PE node in the
redundancy group is responsible for forwarding traffic associated redundancy group is responsible for forwarding traffic associated
with a given I-SID. This guarantees that no forwarding loops are with a given I-SID. This guarantees that no forwarding loops are
created. Filtering based on DF state applies to both unicast and created. Filtering based on DF state applies to both unicast and
multicast traffic, and in both access-to-core as well as core-to- multicast traffic, and in both access-to-core as well as core-to-
skipping to change at page 13, line 19 skipping to change at page 14, line 27
Multi-destination frames received from the AC will be PBB- Multi-destination frames received from the AC will be PBB-
encapsulated by the PE using the B-MAC source address corresponding encapsulated by the PE using the B-MAC source address corresponding
to the originating site. The multicast B-MAC destination address is to the originating site. The multicast B-MAC destination address is
selected based on the value of the I-SID as defined in [802.1ah]. The selected based on the value of the I-SID as defined in [802.1ah]. The
resulting frame is then forwarded over the MPLS core using one out of resulting frame is then forwarded over the MPLS core using one out of
the following two options: the following two options:
Option 1: the MPLS Forwarder can perform ingress replication over a Option 1: the MPLS Forwarder can perform ingress replication over a
set of MP2P tunnel LSPs. The frame is encapsulated with a tunnel LSP set of MP2P tunnel LSPs. The frame is encapsulated with a tunnel LSP
label and the E-VPN ingress replication label advertised in the label and the EVPN ingress replication label advertised in the
Inclusive Multicast Route. Inclusive Multicast Route.
Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the
procedures defined in [E-VPN]. This includes either the use of procedures defined in [EVPN]. This includes either the use of
Inclusive or Aggregate Inclusive trees. Inclusive or Aggregate Inclusive trees.
Note that the same procedures for advertising and handling the Note that the same procedures for advertising and handling the
Inclusive Multicast Route defined in [E-VPN] apply here. Inclusive Multicast Route defined in [EVPN] apply here.
8. Minimizing ARP Broadcast 8. Minimizing ARP Broadcast
The PE nodes implement an ARP-proxy function in order to minimize the The PE nodes implement an ARP-proxy function in order to minimize the
volume of ARP traffic that is broadcasted over the MPLS network. This volume of ARP traffic that is broadcasted over the MPLS network. This
is achieved by having each PE node snoop on ARP request and response is achieved by having each PE node snoop on ARP request and response
messages received over the access interfaces or the MPLS core. The PE messages received over the access interfaces or the MPLS core. The PE
builds a cache of IP / MAC address bindings from these snooped builds a cache of IP / MAC address bindings from these snooped
messages. The PE then uses this cache to respond to ARP requests messages. The PE then uses this cache to respond to ARP requests
ingress on access ports and targeting hosts that are in remote sites. ingress on access ports and targeting hosts that are in remote sites.
skipping to change at page 14, line 35 skipping to change at page 15, line 38
For the same reasons cited in the TRILL section, the B-MAC addresses For the same reasons cited in the TRILL section, the B-MAC addresses
need to be globally unique across all the IEEE 802.1aq / 802.1Qbp need to be globally unique across all the IEEE 802.1aq / 802.1Qbp
networks. The same hierarchical address assignment scheme depicted networks. The same hierarchical address assignment scheme depicted
above is proposed for B-MAC addresses as well. above is proposed for B-MAC addresses as well.
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route
B-MAC addresses associated with 802.1aq / 802.1Qbp switches are B-MAC addresses associated with 802.1aq / 802.1Qbp switches are
advertised using the BGP MAC Advertisement route already defined in advertised using the BGP MAC Advertisement route already defined in
[E-VPN]. [EVPN].
The encapsulation for the transport of PBB frames over MPLS is The encapsulation for the transport of PBB frames over MPLS is
similar to that of classical Ethernet, albeit with the additional PBB similar to that of classical Ethernet, albeit with the additional PBB
header, as shown in the figure below: header, as shown in the figure below:
+------------------+ +------------------+
| IP/MPLS Header | | IP/MPLS Header |
+------------------+ +------------------+
| PBB Header | | PBB Header |
+------------------+ +------------------+
skipping to change at page 15, line 51 skipping to change at page 16, line 51
10.1. MAC Advertisement Route Scalability 10.1. MAC Advertisement Route Scalability
In PBB-EVPN the number of MAC Advertisement Routes is a function of In PBB-EVPN the number of MAC Advertisement Routes is a function of
the number of segments (sites), rather than the number of the number of segments (sites), rather than the number of
hosts/servers. This is because the B-MAC addresses of the PEs, rather hosts/servers. This is because the B-MAC addresses of the PEs, rather
than C-MAC addresses (of hosts/servers) are being advertised in BGP. than C-MAC addresses (of hosts/servers) are being advertised in BGP.
And, as discussed above, there's a one-to-one mapping between multi- And, as discussed above, there's a one-to-one mapping between multi-
homed segments and B-MAC addresses, whereas there's a one-to-one or homed segments and B-MAC addresses, whereas there's a one-to-one or
many-to-one mapping between single-homed segments and B-MAC addresses many-to-one mapping between single-homed segments and B-MAC addresses
for a given PE. As a result, the volume of MAC Advertisement Routes for a given PE. As a result, the volume of MAC Advertisement Routes
in PBB-EVPN is multiple orders of magnitude less than E-VPN. in PBB-EVPN is multiple orders of magnitude less than EVPN.
10.2. C-MAC Mobility with MAC Sub-netting 10.2. C-MAC Mobility with MAC Sub-netting
In PBB-EVPN, if a PE allocates its B-MAC addresses from a contiguous In PBB-EVPN, if a PE allocates its B-MAC addresses from a contiguous
range, then it can advertise a MAC prefix rather than individual 48- range, then it can advertise a MAC prefix rather than individual 48-
bit addresses. It should be noted that B-MAC addresses can easily be bit addresses. It should be noted that B-MAC addresses can easily be
assigned from a contiguous range because PE nodes are within the assigned from a contiguous range because PE nodes are within the
provider administrative domain; however, CE devices and hosts are provider administrative domain; however, CE devices and hosts are
typically not within the provider administrative domain. The typically not within the provider administrative domain. The
advantage of such MAC address sub-netting can be maintained even as advantage of such MAC address sub-netting can be maintained even as
C-MAC addresses move from one Ethernet segment to another. This is C-MAC addresses move from one Ethernet segment to another. This is
because the C-MAC address to B-MAC address association is learnt in because the C-MAC address to B-MAC address association is learnt in
the data-plane and C-MAC addresses are not advertised in BGP. To the data-plane and C-MAC addresses are not advertised in BGP. To
illustrate how this compares to E-VPN, consider the following illustrate how this compares to EVPN, consider the following example:
example:
If a PE running E-VPN advertises reachability for a MAC subnet that If a PE running EVPN advertises reachability for a MAC subnet that
spans N addresses via a particular segment, and then 50% of the MAC spans N addresses via a particular segment, and then 50% of the MAC
addresses in that subnet move to other segments (e.g. due to virtual addresses in that subnet move to other segments (e.g. due to virtual
machine mobility), then in the worst case, N/2 additional MAC machine mobility), then in the worst case, N/2 additional MAC
Advertisement routes need to be sent for the MAC addresses that have Advertisement routes need to be sent for the MAC addresses that have
moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on
the other hand, the sub-netting applies to the B-MAC addresses which the other hand, the sub-netting applies to the B-MAC addresses which
are statically associated with PE nodes and are not subject to are statically associated with PE nodes and are not subject to
mobility. As C-MAC addresses move from one segment to another, the mobility. As C-MAC addresses move from one segment to another, the
binding of C-MAC to B-MAC addresses is updated via data-plane binding of C-MAC to B-MAC addresses is updated via data-plane
learning. learning.
skipping to change at page 17, line 17 skipping to change at page 18, line 17
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
| CE |--| | | PE1| | PE2| | |--| CE | | CE |--| | | PE1| | PE2| | |--| CE |
+----+ | 802.1aq |---| | | |--| MPLS | +----+ +----+ | 802.1aq |---| | | |--| MPLS | +----+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
| CE |--| | | Backbone | | |--| CE | | CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
Figure 9: Interoperability with 802.1aq Figure 9: Interoperability with 802.1aq
If the MPLS backbone network employs E-VPN, then the 802.1aq data- If the MPLS backbone network employs EVPN, then the 802.1aq data-
plane encapsulation must be terminated on PE1 or the edge device plane encapsulation must be terminated on PE1 or the edge device
connecting to PE1. Either way, all the PE nodes that are part of the connecting to PE1. Either way, all the PE nodes that are part of the
associated service instances will be exposed to all the C-MAC associated service instances will be exposed to all the C-MAC
addresses of all hosts/servers connected to the access networks. addresses of all hosts/servers connected to the access networks.
However, if the MPLS backbone network employs PBB-EVPN, then the However, if the MPLS backbone network employs PBB-EVPN, then the
802.1aq encapsulation can be extended over the MPLS backbone, thereby 802.1aq encapsulation can be extended over the MPLS backbone, thereby
maintaining C-MAC address transparency on PE1. If PBB-EVPN is also maintaining C-MAC address transparency on PE1. If PBB-EVPN is also
extended over the MPLS access network on the right, then C-MAC extended over the MPLS access network on the right, then C-MAC
addresses would be transparent to PE2 as well. addresses would be transparent to PE2 as well.
skipping to change at page 18, line 32 skipping to change at page 19, line 32
discussions. discussions.
15. Normative References 15. Normative References
[802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider
Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008. Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008.
16. Informative References 16. Informative References
[PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider [PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider
Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop- Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop-
02.txt, work in progress, July, 2011. 05.txt, work in progress, July, 2011.
[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)", [EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (EVPN)",
draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in draft-ietf-l2vpn-evpn-req-04.txt, work in progress, July,
progress, July, 2011. 2011.
[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [EVPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-00.txt, work in progress, February, 2012. l2vpn-evpn-04.txt, work in progress, February, 2012.
17. Authors' Addresses 17. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
595 Burrard Street, Suite 2123 595 Burrard Street, Suite # 2123
Vancouver, BC V7X 1J1, Canada Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com Email: ssalam@cisco.com
Sami Boutros Sami Boutros
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sboutros@cisco.com Email: sboutros@cisco.com
Nabil Bitar Nabil Bitar
 End of changes. 41 change blocks. 
76 lines changed or deleted 131 lines changed or added

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