draft-ietf-l2vpn-pbb-evpn-06.txt   draft-ietf-l2vpn-pbb-evpn-07.txt 
Internet Working Group Ali Sajassi Internet Working Group Ali Sajassi, Ed.
Internet Draft Samer Salam Internet Draft Samer Salam
Category: Standards Track Sami Boutros Category: Standards Track Cisco
Cisco Nabil Bitar
Verizon
Florin Balus Nabil Bitar
Wim Henderickx Verizon
Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Clarence Filsfils Bloomberg Bloomberg
Dennis Cai Wim Henderickx
Cisco Lizhong Jin Alcatel-Lucent
Lizhong Jin
ZTE ZTE
Expires: December 18, 2014 June 18, 2014
Expires: April 18, 2014 October 18, 2013
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-06 draft-ietf-l2vpn-pbb-evpn-07
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 35 skipping to change at page 2, line 32
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7 6.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7
6.2. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7 6.2. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 8
6.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 8 6.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 8
6.4. Ethernet Segment Route . . . . . . . . . . . . . . . . . . 8 6.4. Ethernet Segment Route . . . . . . . . . . . . . . . . . . 8
6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 8 6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 9
6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 8 6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 9
6.7. MAC Mobility Extended Community . . . . . . . . . . . . . 8 6.7. MAC Mobility Extended Community . . . . . . . . . . . . . 9
6.8. Default Gateway Extended Community . . . . . . . . . . . . 9 6.8. Default Gateway Extended Community . . . . . . . . . . . . 9
7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. MAC Address Distribution over Core . . . . . . . . . . . . 9 7.1. MAC Address Distribution over Core . . . . . . . . . . . . 9
7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 9 7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 9
7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 9 7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 10
7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 9 7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 10
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 11 7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 12
7.2.1.3 Split Horizon and Designated Forwarder Election . . 12 7.2.1.3 Split Horizon and Designated Forwarder Election . . 12
7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 12 7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 13
7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 12 7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 13
7.2.2.2 Split Horizon and Designated Forwarder Election . . 13 7.2.2.2 Split Horizon and Designated Forwarder Election . . 13
7.2.2.3 Handling Failure Scenarios . . . . . . . . . . . . . 13 7.2.2.3 Handling Failure Scenarios . . . . . . . . . . . . . 13
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 14 7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 14
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 14 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 15
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 14 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 15
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 15 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 16
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 15 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 16
9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 16 9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 16
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 16 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 17
9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 17 10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 17
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 17 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18
10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 18 10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 18
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 18 10.3. C-MAC Address Learning and Confinement . . . . . . . . . 18
10.4. Seamless Interworking with TRILL and 802.1aq Access 10.4. Seamless Interworking with TRILL and 802.1aq Access
Networks . . . . . . . . . . . . . . . . . . . . . . . . 18 Networks . . . . . . . . . . . . . . . . . . . . . . . . 19
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 19 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 19
10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 19 10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Intellectual Property Considerations . . . . . . . . . . . . 20 14. Intellectual Property Considerations . . . . . . . . . . . . 20
15. Normative References . . . . . . . . . . . . . . . . . . . . 20 15. Normative References . . . . . . . . . . . . . . . . . . . . 20
16. Informative References . . . . . . . . . . . . . . . . . . . 20 16. Informative References . . . . . . . . . . . . . . . . . . . 20
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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
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.
Sami Boutros, Cisco
Dennis Cai, Cisco
Keyur Patel, Cisco Keyur Patel, Cisco
Clarence Filsfils, Cisco
Sam Aldrin, Huawei Sam Aldrin, Huawei
Himanshu Shah, Ciena Himanshu Shah, Ciena
Florin Balus, ALU
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
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
EVPN: Ethernet VPN EVPN: Ethernet VPN
Single-Active Redundancy Mode: When only a single PE, among a group
of PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet Segment, then the Ethernet segment is defined
to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward traffic to/from that Ethernet Segment,
then the Ethernet segment is defined to be operating in All-Active
redundancy mode.
4. Requirements 4. Requirements
The requirements for PBB-EVPN include all the requirements for EVPN 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 [EVPN] 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 data center interconnect (DCI) scenarios 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.
capability already built into EVPN is not sufficient in those
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, the
is not possible to use MAC address summarization in EVPN, i.e. exact virtual machine MAC address needs to be transmitted in BGP MAC
advertise reach-ability to a MAC address prefix. Rather, the exact
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 means MAC address prefixes cannot be used in data
center applications.
It is required to support C-MAC address mobility, while retaining the In order to support C-MAC address mobility, while retaining the
scalability benefits of MAC summarization. This can be achieved by scalability benefits of MAC summarization, PBB technology is used. It
leveraging PBB technology, which defines a Backbone MAC (B-MAC) defines a Backbone MAC (B-MAC) address space that is independent of
address space that is independent of the C-MAC address space, and the C-MAC address space, and aggregate C-MAC addresses via a B-MAC
aggregate C-MAC addresses via a B-MAC address and then apply 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 EVPN, all the PE nodes participating in the same EVPN instance are In EVPN, all the PE nodes participating in the same EVPN instance 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 EVPN instance. This is the case even if BGP to other PE nodes in that EVPN instance. This is the case even if
some of the PE nodes for that EVPN 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
skipping to change at page 6, line 20 skipping to change at page 6, line 31
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 EVPN 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 All-Active multi-homed devices and networks. This is
to speed up re-convergence upon failure. in order to speed up re-convergence upon failure.
5. Solution Overview 5. Solution Overview
The solution involves incorporating IEEE Backbone Edge Bridge (BEB) The solution involves incorporating IEEE Backbone Edge Bridge (BEB)
functionality on the EVPN 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 devices functionality is incorporated in the VPLS PE nodes. The PE devices
would then receive 802.1Q Ethernet frames from their attachment would then receive 802.1Q Ethernet frames from their attachment
circuits, encapsulate them in the PBB header and forward the frames circuits, encapsulate them in the PBB header and forward the frames
over the IP/MPLS core. On the egress EVPN PE, the PBB header is over the IP/MPLS core. On the egress EVPN PE, the PBB header is
removed following the MPLS disposition, and the original 802.1Q removed following the MPLS disposition, and the original 802.1Q
skipping to change at page 7, line 4 skipping to change at page 7, line 23
AC2\ +----+ | | AC2\ +----+ | |
\| | | | \| | | |
| PE2| | | | 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 PE 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 for traffic
ingress from the core per [PBB] bridging operation. received from the core per [PBB] 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 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).
skipping to change at page 8, line 32 skipping to change at page 9, line 4
- The Ethernet Tag field is set with the appropriate I-SID value. - The Ethernet Tag field is set with the appropriate I-SID value.
- All other fields are set as defined in [EVPN]. - All other fields are set as defined in [EVPN].
This route is tagged with an RT. This RT SHOULD be set to a value This route is tagged with an RT. This RT SHOULD be set to a value
corresponding to its EVI (which is analogous to a B-VID). The RT for corresponding to its EVI (which is analogous to a B-VID). The RT for
this route MAY also be auto-derived from the corresponding Ethernet this route MAY also be auto-derived from the corresponding Ethernet
Tag (I-SID) based on the procedure specified in section 9.4.1.1.1 of Tag (I-SID) based on the procedure specified in section 9.4.1.1.1 of
[EVPN]. [EVPN].
6.4. Ethernet Segment Route 6.4. Ethernet Segment Route
This route is used as defined in [EVPN]. This route is used as defined in [EVPN].
6.5. ESI Label Extended Community 6.5. ESI Label Extended Community
This extended community is not used in PBB-EVPN. In [EVPN], this This extended community is not used in PBB-EVPN. In [EVPN], this
extended community is used along with the Ethernet AD route to extended community is used along with the Ethernet AD route to
advertise an MPLS label for the purpose of split-horizon filtering. advertise an MPLS label for the purpose of split-horizon filtering.
Since in PBB-EVPN, the split-horizon filtering is performed natively Since in PBB-EVPN, the split-horizon filtering is performed natively
using BMAC SA, there is no need for this extended community. using B-MAC SA, there is no need for this extended community.
6.6. ES-Import Route Target 6.6. ES-Import Route Target
This RT is used as defined in [EVPN]. This RT is used as defined in [EVPN].
6.7. MAC Mobility Extended Community 6.7. MAC Mobility Extended Community
This extended community is defined in [EVPN] and it is used with a This extended community is defined in [EVPN] and it is used with a
MAC route (BMAC route in case of PBB-EVPN). The BMAC route is tagged MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is
with the RT corresponding to its EVI (which is analogous to a B-VID). tagged with the RT corresponding to its EVI (which is analogous to a
When this extended community is used along with a BMAC rotue in PBB- B-VID). When this extended community is used along with a B-MAC route
EVPN, it indicates that the C-MAC forwarding tables for all the I- in PBB-EVPN, it indicates that all C-MAC addresses associated with
SIDs associated with the RT tagging this BMAC Advertisement route that B-MAC address across all corresponding I-SIDs must be flushed.
must be flushed.
6.8. Default Gateway Extended Community 6.8. Default Gateway Extended Community
This extended community is not used in PBB-EVPN. This extended community is not used in PBB-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 [EVPN]. areas where it differs from [EVPN].
skipping to change at page 9, line 31 skipping to change at page 10, line 4
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.
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 mode (i.e., flow-based load-
balancing. balancing).
7.2.1.1 PE B-MAC Address Assignment 7.2.1.1 PE B-MAC Address Assignment
In [PBB] every BEB is uniquely identified by one or more B-MAC In [PBB] 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 PE nodes must be examined carefully as it has implications on the the PE nodes must be examined carefully as it has implications on 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 PE 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 mode, a given C-MAC address would be reachable via
be reachable via multiple PE nodes concurrently. Given that any given multiple PE nodes concurrently. Given that any given remote PE will
remote PE will bind the C-MAC address to a single B-MAC address, then bind the C-MAC address to a single B-MAC address, then the various PE
the various PE nodes connected to the same CE must share the same B- nodes connected to the same CE must share the same B-MAC address.
MAC address. Otherwise, the MAC address table of the remote PE nodes Otherwise, the MAC address table of the remote PE nodes will keep
will keep oscillating between the B-MAC addresses of the various PE oscillating between the B-MAC addresses of the various PE devices.
devices. For example, consider the network of Figure 1, and assume For example, consider the network of Figure 1, and assume that PE1
that PE1 has B-MAC BM1 and PE2 has B-MAC BM2. Also, assume that both has B-MAC BM1 and PE2 has B-MAC BM2. Also, assume that both links
links from CE1 to the PE nodes are part of an all-active multi- from CE1 to the PE nodes are part of the same Ethernet link
chassis Ethernet link aggregation group. If BM1 is not equal to BM2, aggregation group. If BM1 is not equal to BM2, the consequence is
the consequence is that the MAC address table on PE3 will keep that the MAC address table on PE3 will keep oscillating such that the
oscillating such that the C-MAC address CM of CE1 would flip-flop C-MAC address M1 of CE1 would flip-flop between BM1 or BM2, depending
between BM1 or BM2, depending on the load-balancing decision on CE1 on the load-balancing decision on CE1 for traffic destined to the
for traffic destined to the core. 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 PE nodes, then it is required for all multi-homed to the same set of PE nodes, then it is required for all
the PE 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 PE. connecting a single site to a given PE.
+---------+ +---------+
+-------+ PE1 | IP/MPLS | +-------+ PE1 | IP/MPLS |
skipping to change at page 10, line 49 skipping to change at page 11, line 32
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 addresses in BGP using the MAC Advertisement routes defined in
[EVPN]. 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 PBB bridge learning procedure,
MAC M1 is reachable via BM1, and C-MAC M2 is reachable via BM2. As a that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via
result, PEr can load-balance traffic destined to M1 between PE1 and BM2. As a result, PEr can load-balance traffic destined to M1 between
PE2, as well as traffic destined to M2 between both PE2 and PE3. In PE1 and PE2, as well as traffic destined to M2 between both PE2 and
the case of a failure that causes, for example, CE1 to be isolated PE3. In the case of a failure that causes, for example, CE1 to be
from PE1, the latter can withdraw the route it has advertised for isolated from PE1, the latter can withdraw the route it has
BM1. This way, PEr would update its path list for BM1, and will send advertised for BM1. This way, PEr would update its path list for BM1,
all traffic destined to M1 over to PE2 only. and will send 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 PE 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 PE 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 All-Active multi-homed CE.
case, the B-MAC address MUST be the same for all PE nodes in a In the latter case, the B-MAC address MUST be the same for all PE
Redundancy Group connected to the same CE. nodes in a 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 PE B-MAC address used for single-homed sites can be automatically The PE B-MAC address used for single-homed sites can be automatically
derived from the hardware (using for e.g. the backplane's address). derived from the hardware (using for e.g. the backplane's address).
However, the B-MAC address used for multi-homed sites must be However, the B-MAC address used for multi-homed sites must be
coordinated among the RG members. To automate the assignment of this coordinated among the RG members. To automate the assignment of this
latter address, the PE can derive this B-MAC address from the MAC latter address, the PE can derive this B-MAC address from the MAC
Address portion of the CE's LACP System Identifier by flipping the Address portion of the CE's LACP System Identifier by flipping the
'Locally Administered' bit of the CE's address. This guarantees the 'Locally Administered' bit of the CE's address. This guarantees the
skipping to change at page 12, line 14 skipping to change at page 12, line 44
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
[EVPN] 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, Ethernet Segment (ES)
used in PBB-EVPN, and the egress split-horizon filtering is done Labels are not used in PBB-EVPN, and the egress split-horizon
based on the B-MAC source address. It is worth noting here that [PBB] filtering is done based on the B-MAC source address. It is worth
defines this B-MAC address based filtering function as part of the I- noting here that [PBB] defines this B-MAC address based filtering
Component options, hence no new functions are required to support function as part of the I-Component options, hence no new functions
split-horizon beyond what is already defined in [PBB]. Given that the are required to support split-horizon beyond what is already defined
Segment label is not used in PBB-EVPN, the PE sets the Label field in in [PBB]. Given that the ES label is not used in PBB-EVPN, the PE
the Ethernet Segment Route to 0. sets the 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 [EVPN].
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 a single-active redundancy model with per-ISID load- homing in a Single-Active redundancy mode 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 In this mode of operation, two B-MAC address assignment models are
skipping to change at page 13, line 7 skipping to change at page 13, line 35
multi-homed segments operating with per-ISID load-balancing mode. multi-homed segments operating with per-ISID load-balancing mode.
- The PE may use a dedicated B-MAC address for each Ethernet Segment - The PE may use a dedicated B-MAC address for each Ethernet Segment
operating with per-ISID load-balancing mode. operating with per-ISID load-balancing mode.
All PE implementations MUST support the shared B-MAC address model All PE implementations MUST support the shared B-MAC address model
and MAY support the dedicated 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 configured with that I-SID. 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. associated next-hop PE to use for said C-MAC address.
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 7.2.2.3 Handling Failure Scenarios
skipping to change at page 21, line 19 skipping to change at page 21, line 21
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
Cisco
170 West Tasman Drive
San Jose, CA 95134, US
Email: sboutros@cisco.com
Nabil Bitar Nabil Bitar
Verizon Communications Verizon Communications
Email : nabil.n.bitar@verizon.com Email : nabil.n.bitar@verizon.com
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
Email: aisaac71@bloomberg.net Email: aisaac71@bloomberg.net
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.be
Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com
Dennis Cai
Cisco
Email: dcai@cisco.com
Lizhong Jin Lizhong Jin
ZTE Corporation ZTE Corporation
889, Bibo Road 889, Bibo Road
Shanghai, 201203, China Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn Email: lizhong.jin@zte.com.cn
 End of changes. 45 change blocks. 
118 lines changed or deleted 103 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/