draft-ietf-l2vpn-pbb-evpn-03.txt   draft-ietf-l2vpn-pbb-evpn-04.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: December 20, 2012 June 20, 2012 Expires: August 25, 2013 February 25, 2013
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-03 draft-ietf-l2vpn-pbb-evpn-04
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 1, line 45 skipping to change at page 1, line 45
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 45 skipping to change at page 2, line 45
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5 4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5
4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5 4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5
4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5 4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5
4.4. Per Site Policy Support . . . . . . . . . . . . . . . . . 6 4.4. Per Site Policy Support . . . . . . . . . . . . . . . . . 6
4.5. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6 4.5. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7 6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7
6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7 6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7
6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 7 6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 8
6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 7 6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 8
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 MES 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 MES 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.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 12 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 12
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 12 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 12
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 13 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 13
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 13 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 13
9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 14 9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 14
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 14 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 14
9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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
In addition to the authors listed above, the following individuals In addition to the authors listed above, the following individuals
also contributed to this document. also contributed to this document.
Keyur Patel, Cisco Keyur Patel, Cisco
Sam Aldrin, Huawei Sam Aldrin, Huawei
Himanshu Shah, Ciena
3. Terminology 3. Terminology
BEB: Backbone Edge Bridge BEB: Backbone Edge Bridge
B-MAC: Backbone MAC Address B-MAC: Backbone MAC Address
CE: Customer Edge CE: Customer Edge
C-MAC: Customer/Client MAC Address C-MAC: Customer/Client MAC Address
DHD: Dual-homed Device DHD: Dual-homed Device
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
MES: MPLS Edge Switch
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
PoA: Point of Attachment PoA: Point of Attachment
PW: Pseudowire PW: Pseudowire
E-VPN: Ethernet VPN E-VPN: 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 E-VPN
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] MES sends a BGP MAC Advertisement In typical operation, an [E-VPN] 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 E-VPN is not sufficient in those
environments, as will be discussed next. environments, as will be discussed next.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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 MES nodes participating in the same E-VPN instance In E-VPN, all the PE nodes participating in the same E-VPN instance
are exposed to all the C-MAC addresses learnt by any one of these MES are exposed to all the C-MAC addresses learnt by any one of these PE
nodes because a C-MAC learned by one of the MES nodes is advertise in nodes because a C-MAC learned by one of the PE nodes is advertise in
BGP to other MES nodes in that E-VPN instance. This is the case even BGP to other PE nodes in that E-VPN instance. This is the case even
if some of the MES nodes for that E-VPN instance are not involved in if some of the PE nodes for that E-VPN 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 MES, 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
MES 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 MES 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 MES 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 E-VPN 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 MES nodes similar to PBB-VPLS, where (BEB) functionality on the E-VPN PE nodes similar to PBB-VPLS, where
BEB functionality is incorporated in the VPLS PE nodes. The MES 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 MES, the PBB the frames over the IP/MPLS core. On the egress E-VPN 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|
+----+\ |MES1| | IP/MPLS | |MES3| +----+ +----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+ \ +----+ | Network | +----+
\ | | \ | |
AC2\ +----+ | | AC2\ +----+ | |
\| | | | \| | | |
|MES2| | | | PE2| | |
+----+ | | +----+ | |
/\ +--------------+ /\ +--------------+
|| ||
BEB BEB
<-802.1Q-> <------PBB over MPLS------> <-802.1Q-> <-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 1: PBB-EVPN Network Figure 1: PBB-EVPN Network
The MES nodes perform the following functions:- Learn customer/client The PE nodes perform the following functions:- Learn customer/client
MAC addresses (C-MACs) over the attachment circuits in the data- MAC addresses (C-MACs) over the attachment circuits in the data-
plane, per normal bridge operation. plane, per normal bridge operation.
- Learn remote C-MAC to B-MAC bindings in the data-plane from traffic - Learn remote C-MAC to B-MAC bindings in the data-plane from traffic
ingress from the core per [802.1ah] bridging operation. ingress from the core per [802.1ah] bridging operation.
- Advertise local B-MAC address reach-ability information in BGP to - Advertise local B-MAC address reach-ability information in BGP to
all other MES nodes in the same set of service instances. Note that all other PE nodes in the same set of service instances. Note that
every MES 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 MES 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 MES 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 [E-
VPN], adapted as follows: VPN], 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 E-VPN MAC Advertisement Route is used to distribute B-MAC
addresses of the MES 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
single-homed Segments) or to MAX-ESI (for multi-homed Segments). 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 [E-VPN].
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
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-
ESI indicate that the receiving PE can resolve the path without an
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 [E-VPN]. 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 a new transitive extended community. It
may be advertised along with the MAC Advertisement route. When used
in PBB-EVPN, it indicates that the C-MAC forwarding tables for the I-
SIDs associated with the RT tagging the MAC Advertisement route must
be flushed. This extended community is encoded in 8-bytes as follows:
- Type (1 byte) = Pending IANA assignment. This extended community is defined in [EVPN]. When used in PBB-EVPN,
- Sub-Type (1 byte) = Pending IANA assignment. it indicates that the C-MAC forwarding tables for the I-SIDs
- Reserved (2 bytes) associated with the RT tagging the MAC Advertisement route must be
- Counter (4 bytes) 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 [E-VPN].
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 [E-VPN].
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 MES 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 MES 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.
7.2. Device Multi-homing 7.2. Device Multi-homing
7.2.1 Flow-based Load-balancing 7.2.1 Flow-based Load-balancing
This section describes the procedures for supporting device multi- This section describes the procedures for supporting device multi-
homing in an all-active redundancy model with flow-based load- homing in an all-active redundancy model with flow-based load-
balancing. balancing.
7.2.1.1 MES B-MAC Address Assignment 7.2.1.1 PE B-MAC Address Assignment
In [802.1ah] every BEB is uniquely identified by one or more B-MAC In [802.1ah] every BEB is uniquely identified by one or more B-MAC
addresses. These addresses are usually locally administered by the addresses. These addresses are usually locally administered by the
Service Provider. For PBB-EVPN, the choice of B-MAC address(es) for Service Provider. For PBB-EVPN, the choice of B-MAC address(es) for
the MES nodes must be examined carefully as it has implications on the PE nodes must be examined carefully as it has implications on the
the proper operation of multi-homing. In particular, for the scenario proper operation of multi-homing. In particular, for the scenario
where a CE is multi-homed to a number of MES nodes with all-active where a CE is multi-homed to a number of PE nodes with all-active
redundancy and flow-based load-balancing, a given C-MAC address would redundancy and flow-based load-balancing, a given C-MAC address would
be reachable via multiple MES nodes concurrently. Given that any be reachable via multiple PE nodes concurrently. Given that any given
given remote MES will bind the C-MAC address to a single B-MAC remote PE will bind the C-MAC address to a single B-MAC address, then
address, then the various MES nodes connected to the same CE must the various PE nodes connected to the same CE must share the same B-
share the same B-MAC address. Otherwise, the MAC address table of the MAC address. Otherwise, the MAC address table of the remote PE nodes
remote MES nodes will keep oscillating between the B-MAC addresses of will keep oscillating between the B-MAC addresses of the various PE
the various MES devices. For example, consider the network of Figure devices. For example, consider the network of Figure 1, and assume
1, and assume that MES1 has B-MAC BM1 and MES2 has B-MAC BM2. Also, that PE1 has B-MAC BM1 and PE2 has B-MAC BM2. Also, assume that both
assume that both links from CE1 to the MES nodes are part of an all- links from CE1 to the PE nodes are part of an all-active multi-
active multi-chassis Ethernet link aggregation group. If BM1 is not chassis Ethernet link aggregation group. If BM1 is not equal to BM2,
equal to BM2, the consequence is that the MAC address table on MES3 the consequence is that the MAC address table on PE3 will keep
will keep oscillating such that the C-MAC address CM of CE1 would oscillating such that the C-MAC address CM of CE1 would flip-flop
flip-flop between BM1 or BM2, depending on the load-balancing between BM1 or BM2, depending on the load-balancing decision on CE1
decision on CE1 for traffic destined to the core. for traffic destined to the core.
Considering that there could be multiple sites (e.g. CEs) that are Considering that there could be multiple sites (e.g. CEs) that are
multi-homed to the same set of MES nodes, then it is required for all multi-homed to the same set of PE nodes, then it is required for all
the MES devices in a Redundancy Group to have a unique B-MAC address the PE devices in a Redundancy Group to have a unique B-MAC address
per site. This way, it is possible to achieve fast convergence in the per site. This way, it is possible to achieve fast convergence in the
case where a link or port failure impacts the attachment circuit case where a link or port failure impacts the attachment circuit
connecting a single site to a given MES. connecting a single site to a given PE.
+---------+ +---------+
+-------+ MES1 | IP/MPLS | +-------+ PE1 | IP/MPLS |
/ | | / | |
CE1 | Network | MESr CE1 | Network | PEr
M1 \ | | M1 \ | |
+-------+ MES2 | | +-------+ PE2 | |
/-------+ | | /-------+ | |
/ | | / | |
CE2 | | CE2 | |
M2 \ | | M2 \ | |
\ | | \ | |
+------+ MES3 +---------+ +------+ PE3 +---------+
Figure 2: B-MAC Address Assignment Figure 2: B-MAC Address Assignment
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 MES1/MES2 and corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3,
MES2/MES3, respectively. Assume that BM1 is the B-MAC used for the respectively. Assume that BM1 is the B-MAC used for the site
site corresponding to CE1. Similarly, BM2 is the B-MAC used for the corresponding to CE1. Similarly, BM2 is the B-MAC used for the site
site corresponding to CE2. On MES1, 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 MES2, 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 MES3, addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a
a single B-MAC address (BM2) is required for the site corresponding single B-MAC address (BM2) is required for the site corresponding to
to CE2. All three MES 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 [E-
VPN]. The remote MES, MESr, would learn via BGP that BM1 is reachable VPN]. The remote PE, PEr, would learn via BGP that BM1 is reachable
via MES1 and MES2, whereas BM2 is reachable via both MES2 and MES3. via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3.
Furthermore, MESr 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, MESr can load-balance traffic destined to M1 between MES1 and result, PEr can load-balance traffic destined to M1 between PE1 and
MES2, as well as traffic destined to M2 between both MES2 and MES3. PE2, as well as traffic destined to M2 between both PE2 and PE3. In
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 MES1, 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, MESr 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 MES2 only. all traffic destined to M1 over to PE2 only.
For single-homed sites, it is possible to assign a unique B-MAC For single-homed sites, it is possible to assign a unique B-MAC
address per site, or have all the single-homed sites connected to a address per site, or have all the single-homed sites connected to a
given MES share a single B-MAC address. The advantage of the first given PE share a single B-MAC address. The advantage of the first
model over the second model is the ability to avoid C-MAC destination model over the second model is the ability to avoid C-MAC destination
address lookup on the disposition PE (even though source C-MAC address lookup on the disposition PE (even though source C-MAC
learning is still required in the data-plane). Also, by assigning the learning is still required in the data-plane). Also, by assigning the
B-MAC addresses from a contiguous range, it is possible to advertise B-MAC addresses from a contiguous range, it is possible to advertise
a single B-MAC subnet for all single-homed sites, thereby rendering a single B-MAC subnet for all single-homed sites, thereby rendering
the number of MAC advertisement routes required at par with the the number of MAC advertisement routes required at par with the
second model. second model.
In summary, every MES may use a unicast B-MAC address shared by all In summary, every PE may use a unicast B-MAC address shared by all
single-homed CEs or a unicast B-MAC address per single-homed CE and, single-homed CEs or a unicast B-MAC address per single-homed CE and,
in addition, a unicast B-MAC address per dual-homed CE. In the latter in addition, a unicast B-MAC address per dual-homed CE. In the latter
case, the B-MAC address MUST be the same for all MES nodes in a case, the B-MAC address MUST be the same for all PE nodes in a
Redundancy Group connected to the same CE. Redundancy Group connected to the same CE.
7.2.1.2. Automating B-MAC Address Assignment 7.2.1.2. Automating B-MAC Address Assignment
The MES B-MAC address used for single-homed sites can be The PE B-MAC address used for single-homed sites can be automatically
automatically derived from the hardware (using for e.g. the derived from the hardware (using for e.g. the backplane's address).
backplane's address). However, the B-MAC address used for multi-homed However, the B-MAC address used for multi-homed sites must be
sites must be coordinated among the RG members. To automate the coordinated among the RG members. To automate the assignment of this
assignment of this latter address, the MES can derive this B-MAC latter address, the PE can derive this B-MAC address from the MAC
address from the MAC Address portion of the CE's LACP System Address portion of the CE's LACP System Identifier by flipping the
Identifier by flipping the 'Locally Administered' bit of the CE's 'Locally Administered' bit of the CE's address. This guarantees the
address. This guarantees the uniqueness of the B-MAC address within uniqueness of the B-MAC address within the network, and ensures that
the network, and ensures that all MES nodes connected to the same all PE nodes connected to the same multi-homed CE use the same value
multi-homed CE use the same value for the B-MAC address. for the B-MAC address.
Note that with this automatic provisioning of the B-MAC address Note that with this automatic provisioning of the B-MAC address
associated with multi-homed CEs, it is not possible to support the associated with multi-homed CEs, it is not possible to support the
uncommon scenario where a CE has multiple bundles towards the MES uncommon scenario where a CE has multiple bundles towards the PE
nodes, and the service involves hair-pinning traffic from one bundle nodes, and the service involves hair-pinning traffic from one bundle
to another. This is because the split-horizon filtering relies on B- to another. This is because the split-horizon filtering relies on B-
MAC addresses rather than Site-ID Labels (as will be described in the MAC addresses rather than Site-ID Labels (as will be described in the
next section). The operator must explicitly configure the B-MAC next section). The operator must explicitly configure the B-MAC
address for this fairly uncommon service scenario. address for this fairly uncommon service scenario.
Whenever a B-MAC address is provisioned on the MES, either manually Whenever a B-MAC address is provisioned on the PE, either manually or
or automatically (as an outcome of CE auto-discovery), the MES 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 MES. 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 [E-VPN] 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 MES sets Given that the Segment label is not used in PBB-EVPN, the PE sets the
the Label field in the Ethernet Segment Route to 0. Label field in the Ethernet Segment Route to 0.
The Designated Forwarder election procedures are defined in [I-D- The Designated Forwarder election procedures are defined in [I-D-
Segment-Route]. Segment-Route].
7.2.2 I-SID Based Load-balancing 7.2.2 I-SID Based Load-balancing
This section describes the procedures for supporting device multi- This section describes the procedures for supporting device multi-
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 MES 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 MES 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 MES connected to are allocated per multi-homed Ethernet Segment: Each PE connected to
the multi-homed segment is assigned a unique B-MAC. Every MES 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.
A remote MES 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 MES 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 MES, 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 MES to use for said C-MAC address. When a MES associated next-hop PE to use for said C-MAC address. When a PE
connected to a multi-homed Ethernet Segment loses connectivity to the connected to a multi-homed Ethernet Segment loses connectivity to the
segment, due to link or port failure, it withdraws the B-MAC route segment, due to link or port failure, it withdraws the B-MAC route
previously advertised for that segment. This causes the remote MES previously advertised for that segment. This causes the remote PE
nodes to flush all C-MAC addresses associated with the B-MAC in 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 question. This is done across all I-SIDs that are mapped to the EVI
of the withdrawn MAC route. 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.3. Network Multi-homing 7.3. Network Multi-homing
When an Ethernet network is multi-homed to a set of MES 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 MES 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-
access directions (unlike the multi-homed device scenario where DF access directions (unlike the multi-homed device scenario where DF
filtering is limited to multi-destination frames in the core-to- filtering is limited to multi-destination frames in the core-to-
access direction). Similar to the multi-homed device scenario, with access direction). Similar to the multi-homed device scenario, with
I-SID based load-balancing, a unique B-MAC address is assigned to I-SID based load-balancing, a unique B-MAC address is assigned to
each of the MES nodes connected to the multi-homed network (Segment). each of the PE nodes connected to the multi-homed network (Segment).
7.4. Frame Forwarding 7.4. Frame Forwarding
The frame forwarding functions are divided in between the Bridge The frame forwarding functions are divided in between the Bridge
Module, which hosts the [802.1ah] Backbone Edge Bridge (BEB) Module, which hosts the [802.1ah] Backbone Edge Bridge (BEB)
functionality, and the MPLS Forwarder which handles the MPLS functionality, and the MPLS Forwarder which handles the MPLS
imposition/disposition. The details of frame forwarding for unicast imposition/disposition. The details of frame forwarding for unicast
and multi-destination frames are discussed next. and multi-destination frames are discussed next.
7.4.1. Unicast 7.4.1. Unicast
Known unicast traffic received from the AC will be PBB-encapsulated Known unicast traffic received from the AC will be PBB-encapsulated
by the MES using the B-MAC source address corresponding to the by the PE using the B-MAC source address corresponding to the
originating site. The unicast B-MAC destination address is determined originating site. The unicast B-MAC destination address is determined
based on a lookup of the C-MAC destination address (the binding of based on a lookup of the C-MAC destination address (the binding of
the two is done via transparent learning of reverse traffic). The the two is done via transparent learning of reverse traffic). The
resulting frame is then encapsulated with an LSP tunnel label and the resulting frame is then encapsulated with an LSP tunnel label and the
MPLS label which uniquely identifies the B-MAC destination address on MPLS label which uniquely identifies the B-MAC destination address on
the egress MES. If per flow load-balancing over ECMPs in the MPLS the egress PE. If per flow load-balancing over ECMPs in the MPLS core
core is required, then a flow label is added as the end of stack is required, then a flow label is added as the end of stack label.
label.
For unknown unicast traffic, the MES forwards these frames over MPLS For unknown unicast traffic, the PE forwards these frames over MPLS
core. When these frames are to be forwarded, then the same set of core. When these frames are to be forwarded, then the same set of
options used for forwarding multicast/broadcast frames (as described options used for forwarding multicast/broadcast frames (as described
in next section) are used. in next section) are used.
7.4.2. Multicast/Broadcast 7.4.2. Multicast/Broadcast
Multi-destination frames received from the AC will be PBB- Multi-destination frames received from the AC will be PBB-
encapsulated by the MES 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 E-VPN 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 [E-VPN]. 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 [E-VPN] apply here.
8. Minimizing ARP Broadcast 8. Minimizing ARP Broadcast
The MES nodes implement an ARP-proxy function in order to minimize The PE nodes implement an ARP-proxy function in order to minimize the
the volume of ARP traffic that is broadcasted over the MPLS network. volume of ARP traffic that is broadcasted over the MPLS network. This
This is achieved by having each MES node snoop on ARP request and is achieved by having each PE node snoop on ARP request and response
response messages received over the access interfaces or the MPLS messages received over the access interfaces or the MPLS core. The PE
core. The MES builds a cache of IP / MAC address bindings from these builds a cache of IP / MAC address bindings from these snooped
snooped messages. The MES then uses this cache to respond to ARP messages. The PE then uses this cache to respond to ARP requests
requests ingress on access ports and targeting hosts that are in ingress on access ports and targeting hosts that are in remote sites.
remote sites. If the MES finds a match for the IP address in its ARP If the PE finds a match for the IP address in its ARP cache, it
cache, it responds back to the requesting host and drops the request. responds back to the requesting host and drops the request.
Otherwise, if it does not find a match, then the request is flooded Otherwise, if it does not find a match, then the request is flooded
over the MPLS network using either ingress replication or LSM. over the MPLS network using either ingress replication or LSM.
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|SW1 |--| | |MES1| |MES2| | |--| SW3| |SW1 |--| | | PE1| | PE2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+ +----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4| |SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP |<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------------------------- PBB -------------------------->| DP |<------------------------- PBB -------------------------->| DP
|<----MPLS----->| |<----MPLS----->|
skipping to change at page 15, line 21 skipping to change at page 15, line 21
+------------------+ +------------------+
| Ethernet Payload | | Ethernet Payload |
+------------------+ +------------------+
| Ethernet FCS | | Ethernet FCS |
+------------------+ +------------------+
Figure 8: PBB over MPLS Encapsulation Figure 8: PBB over MPLS Encapsulation
9.3 Operation: 9.3 Operation:
When a MES receives a PBB-encapsulated Ethernet frame from the access When a PE receives a PBB-encapsulated Ethernet frame from the access
side, it performs a lookup on the B-MAC destination address to side, it performs a lookup on the B-MAC destination address to
identify the next hop. If the lookup yields that the next hop is a identify the next hop. If the lookup yields that the next hop is a
remote MES, the local MES would then encapsulate the PBB frame in remote PE, the local PE would then encapsulate the PBB frame in MPLS.
MPLS. The label stack comprises of the VPN label (advertised by the The label stack comprises of the VPN label (advertised by the remote
remote PE), followed by an LSP/IGP label. From that point onwards, PE), followed by an LSP/IGP label. From that point onwards, regular
regular MPLS forwarding is applied. MPLS forwarding is applied.
On the disposition MES, assuming penultimate-hop-popping is employed, On the disposition PE, assuming penultimate-hop-popping is employed,
the MES receives the MPLS-encapsulated PBB frame with a single label: the PE receives the MPLS-encapsulated PBB frame with a single label:
the VPN label. The value of the label indicates to the disposition the VPN label. The value of the label indicates to the disposition PE
MES that this is a PBB frame, so the label is popped, the TTL field that this is a PBB frame, so the label is popped, the TTL field (in
(in the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is
employed from this point onwards. employed from this point onwards.
10. Solution Advantages 10. Solution Advantages
In this section, we discuss the advantages of the PBB-EVPN solution In this section, we discuss the advantages of the PBB-EVPN solution
in the context of the requirements set forth in section 3 above. in the context of the requirements set forth in section 3 above.
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 MESes, hosts/servers. This is because the B-MAC addresses of the PEs, rather
rather than C-MAC addresses (of hosts/servers) are being advertised than C-MAC addresses (of hosts/servers) are being advertised in BGP.
in BGP. And, as discussed above, there's a one-to-one mapping between And, as discussed above, there's a one-to-one mapping between multi-
multi-homed segments and B-MAC addresses, whereas there's a one-to- homed segments and B-MAC addresses, whereas there's a one-to-one or
one or many-to-one mapping between single-homed segments and B-MAC many-to-one mapping between single-homed segments and B-MAC addresses
addresses for a given MES. As a result, the volume of MAC for a given PE. As a result, the volume of MAC Advertisement Routes
Advertisement Routes in PBB-EVPN is multiple orders of magnitude less in PBB-EVPN is multiple orders of magnitude less than E-VPN.
than E-VPN.
10.2. C-MAC Mobility with MAC Sub-netting 10.2. C-MAC Mobility with MAC Sub-netting
In PBB-EVPN, if a MES 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 MES 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 E-VPN, consider the following
example: example:
If a MES running E-VPN advertises reachability for a MAC subnet that If a PE running E-VPN 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 MES 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.
10.3. C-MAC Address Learning and Confinement 10.3. C-MAC Address Learning and Confinement
In PBB-EVPN, C-MAC address reachability information is built via In PBB-EVPN, C-MAC address reachability information is built via
data-plane learning. As such, MES nodes not participating in active data-plane learning. As such, PE nodes not participating in active
conversations involving a particular C-MAC address will purge that conversations involving a particular C-MAC address will purge that
address from their forwarding tables. Furthermore, since C-MAC address from their forwarding tables. Furthermore, since C-MAC
addresses are not distributed in BGP, MES nodes will not maintain any addresses are not distributed in BGP, PE nodes will not maintain any
record of them in control-plane routing table. record of them in control-plane routing table.
10.4. Seamless Interworking with TRILL and 802.1aq Access Networks 10.4. Seamless Interworking with TRILL and 802.1aq Access Networks
Consider the scenario where two access networks, one running MPLS and Consider the scenario where two access networks, one running MPLS and
the other running 802.1aq, are interconnected via an MPLS backbone the other running 802.1aq, are interconnected via an MPLS backbone
network. The figure below shows such an example network. network. The figure below shows such an example network.
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
| CE |--| | |MES1| |MES2| | |--| 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 E-VPN, then the 802.1aq data-
plane encapsulation must be terminated on MES1 or the edge device plane encapsulation must be terminated on PE1 or the edge device
connecting to MES1. Either way, all the MES nodes that are part of connecting to PE1. Either way, all the PE nodes that are part of the
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 MES1. 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 MES2 as well. addresses would be transparent to PE2 as well.
Interoperability with TRILL access network will be described in Interoperability with TRILL access network will be described in
future revision of this draft. future revision of this draft.
10.5. Per Site Policy Support 10.5. Per Site Policy Support
In PBB-EVPN, a unique B-MAC address can be associated with every site In PBB-EVPN, a unique B-MAC address can be associated with every site
(single-homed or multi-homed). Given that the B-MAC addresses are (single-homed or multi-homed). Given that the B-MAC addresses are
sent in BGP MAC Advertisement routes, it is possible to define per sent in BGP MAC Advertisement routes, it is possible to define per
site (i.e. B-MAC) forwarding policies including policies for E-TREE site (i.e. B-MAC) forwarding policies including policies for E-TREE
service. service.
10.6. Avoiding C-MAC Address Flushing 10.6. Avoiding C-MAC Address Flushing
With PBB-EVPN, it is possible to avoid C-MAC address flushing upon With PBB-EVPN, it is possible to avoid C-MAC address flushing upon
topology change affecting a multi-homed device. To illustrate this, topology change affecting a multi-homed device. To illustrate this,
consider the example network of Figure 1. Both MES1 and MES2 consider the example network of Figure 1. Both PE1 and PE2 advertize
advertize the same B-MAC address (BM1) to MES3. MES3 then learns the the same B-MAC address (BM1) to PE3. PE3 then learns the C-MAC
C-MAC addresses of the servers/hosts behind CE1 via data-plane addresses of the servers/hosts behind CE1 via data-plane learning. If
learning. If AC1 fails, then MES3 does not need to flush any of the AC1 fails, then PE3 does not need to flush any of the C-MAC addresses
C-MAC addresses learnt and associated with BM1. This is because MES1 learnt and associated with BM1. This is because PE1 will withdraw the
will withdraw the MAC Advertisement routes associated with BM1, MAC Advertisement routes associated with BM1, thereby leading PE3 to
thereby leading MES3 to have a single adjacency (to MES2) for this B- have a single adjacency (to PE2) for this B-MAC address. Therefore,
MAC address. Therefore, the topology change is communicated to MES3 the topology change is communicated to PE3 and no C-MAC address
and no C-MAC address flushing is required. flushing is required.
11. Acknowledgements 11. Acknowledgements
TBD. TBD.
12. Security Considerations 12. Security Considerations
There are no additional security aspects beyond those of VPLS/H-VPLS There are no additional security aspects beyond those of VPLS/H-VPLS
that need to be discussed here. that need to be discussed here.
 End of changes. 77 change blocks. 
167 lines changed or deleted 170 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/