< draft-ietf-l2vpn-pbb-evpn-08.txt   draft-ietf-l2vpn-pbb-evpn-09.txt >
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft Samer Salam Internet Draft Samer Salam
Category: Standards Track Cisco Category: Standards Track Cisco
Nabil Bitar Nabil Bitar
Verizon Verizon
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Lizhong Jin Lizhong Jin
ZTE ZTE
Expires: April 18, 2015 October 18, 2014 Expires: April 24, 2015 October 24, 2014
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-08 draft-ietf-l2vpn-pbb-evpn-09
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 3, line 33 skipping to change at page 3, line 33
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18
10.2. C-MAC Mobility Independent of B-MAC Advertisements . . . 18 10.2. C-MAC Mobility Independent of B-MAC Advertisements . . . 18
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 19 10.3. C-MAC Address Learning and Confinement . . . . . . . . . 19
10.4. Seamless Interworking with 802.1aq Access Networks . . . 19 10.4. Seamless Interworking with 802.1aq Access Networks . . . 19
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 20 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 20
10.6. No C-MAC Address Flushing for All-Active Multi-Homing . . 20 10.6. No C-MAC Address Flushing for All-Active Multi-Homing . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Normative References . . . . . . . . . . . . . . . . . . . . 20 14. Normative References . . . . . . . . . . . . . . . . . . . . 20
15. Informative References . . . . . . . . . . . . . . . . . . . 20 15. Informative References . . . . . . . . . . . . . . . . . . . 21
16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[EVPN] introduces a solution for multipoint L2VPN services, with [EVPN] introduces a solution for multipoint L2VPN services, with
advanced multi-homing capabilities, using BGP for distributing advanced multi-homing capabilities, using BGP for distributing
customer/client MAC address reach-ability information over the core customer/client MAC address reach-ability information over the core
MPLS/IP network. [PBB] defines an architecture for Ethernet Provider MPLS/IP network. [PBB] defines an architecture for Ethernet Provider
Backbone Bridging (PBB), where MAC tunneling is employed to improve Backbone Bridging (PBB), where MAC tunneling is employed to improve
service instance and MAC address scalability in Ethernet as well as service instance and MAC address scalability in Ethernet as well as
VPLS networks [RFC7080]. VPLS networks [RFC7080].
In this document, we discuss how PBB can be combined with EVPN in In this document, we discuss how PBB can be combined with EVPN in
order to: reduce the number of BGP MAC advertisement routes by order to: reduce the number of BGP MAC advertisement routes by
aggregating Customer/Client MAC (C-MAC) addresses via Provider aggregating Customer/Client MAC (C-MAC) addresses via Provider
Backbone MAC address (B-MAC), provide client MAC address mobility Backbone MAC address (B-MAC), provide client MAC address mobility
using C-MAC aggregation and B-MAC sub-netting, confine the scope of using C-MAC aggregation, confine the scope of C-MAC learning to only
C-MAC learning to only active flows, offer per site policies and active flows, offer per site policies and avoid C-MAC address
avoid C-MAC address flushing on topology changes. The combined flushing on topology changes. The combined solution is referred to as
solution is referred to as PBB-EVPN. 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 Sami Boutros, Cisco
Dennis Cai, Cisco Dennis Cai, Cisco
Keyur Patel, Cisco Keyur Patel, Cisco
Clarence Filsfils, Cisco Clarence Filsfils, Cisco
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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 PBB bridge learning procedure, Furthermore, PEr establishes, via the PBB bridge learning procedure,
that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via
BM2. As a result, PEr can load-balance traffic destined to M1 between BM2. As a result, PEr can load-balance traffic destined to M1 between
PE1 and PE2, as well as traffic destined to M2 between both PE2 and PE1 and PE2, as well as traffic destined to M2 between both PE2 and
PE3. In the case of a failure that causes, for example, CE1 to be PE3. In the case of a failure that causes, for example, CE1 to be
isolated from PE1, the latter can withdraw the route it has isolated from PE1, the latter can withdraw the route it has
advertised for BM1. This way, PEr would update its path list for BM1, advertised for BM1. This way, PEr would update its path list for BM1,
and will send 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 or Single-Active sites, it is possible to assign a
address per site, or have all the single-homed sites connected to a unique B-MAC address per site, or have all the Single-Homed sites or
given PE share a single B-MAC address. The advantage of the first Single-Active sites connected to a given PE share a single B-MAC
model over the second model is the ability to avoid C-MAC destination address. The advantage of the first model over the second model is
address lookup on the disposition PE (even though source C-MAC the ability to avoid C-MAC destination address lookup on the
learning is still required in the data-plane). Also, by assigning the disposition PE (even though source C-MAC learning is still required
B-MAC addresses from a contiguous range, it is possible to advertise in the data-plane). The disadvantage of the first model over the
a single B-MAC subnet for all single-homed sites, thereby rendering second model is additional B-MAC advertisements in BGP.
the number of MAC advertisement routes required at par with the
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 sites or a unicast B-MAC address per single-homed site single-homed sites or a unicast B-MAC address per single-homed site
and, in addition, a unicast B-MAC address per All-Active multi-homed and, in addition, a unicast B-MAC address per All-Active multi-homed
site. In the latter case, the B-MAC address MUST be the same for all site. In the latter case, the B-MAC address MUST be the same for all
PE nodes in a Redundancy Group connected to the same site. PE nodes in a Redundancy Group connected to the same site.
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 or Single-Active sites can
derived from the hardware (using for e.g. the backplane's address). be automatically derived from the hardware (using for e.g. the
However, the B-MAC address used for multi-homed sites must be backplane's address and/or PE's reserved MAC pool ). However, the B-
coordinated among the RG members. To automate the assignment of this MAC address used for All-Active sites must be coordinated among the
latter address, the PE can derive this B-MAC address from the MAC RG members. To automate the assignment of this latter address, the PE
Address portion of the CE's Link Aggregation Control Protocol (LACP) can derive this B-MAC address from the MAC Address portion of the
System Identifier by flipping the 'Locally Administered' bit of the CE's Link Aggregation Control Protocol (LACP) System Identifier by
CE's address. This guarantees the uniqueness of the B-MAC address flipping the 'Locally Administered' bit of the CE's address. This
within the network, and ensures that all PE nodes connected to the guarantees the uniqueness of the B-MAC address within the network,
same multi-homed CE use the same value for the B-MAC address. and ensures that all PE nodes connected to the same All-Active CE use
the same value 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 All-Active CEs, it is not possible to support the
uncommon scenario where a CE has multiple link bundles within the uncommon scenario where a CE has multiple link bundles within the
same LACP session towards the PE nodes, and the service involves same LACP session towards the PE nodes, and the service involves
hair-pinning traffic from one bundle to another. This is because the hair-pinning traffic from one bundle to another. This is because the
split-horizon filtering relies on B-MAC addresses rather than Site-ID split-horizon filtering relies on B-MAC addresses rather than Site-ID
Labels (as will be described in the next section). The operator must Labels (as will be described in the next section). The operator must
explicitly configure the B-MAC address for this fairly uncommon explicitly configure the B-MAC address for this fairly uncommon
service scenario. service scenario.
Whenever a B-MAC address is provisioned on the PE, either manually or Whenever a B-MAC address is provisioned on the PE, either manually or
automatically (as an outcome of CE auto-discovery), the PE MUST automatically (as an outcome of CE auto-discovery), the PE MUST
skipping to change at page 13, line 30 skipping to change at page 13, line 30
In this mode of operation, two B-MAC address assignment models are In this mode of operation, two B-MAC address assignment models are
possible: possible:
- The PE may use a shared B-MAC address for multiple Ethernet - The PE may use a shared B-MAC address for multiple Ethernet
Segments (ES's). This includes the single-homed segments as well as Segments (ES's). This includes the single-homed segments as well as
the multi-homed segments operating with per-ISID load-balancing mode. the multi-homed segments operating with per-ISID load-balancing mode.
- The PE may use a dedicated B-MAC address for each ES operating with - The PE may use a dedicated B-MAC address for each ES operating with
per-ISID load-balancing mode. per-ISID load-balancing mode.
All PE implementations MUST support the shared B-MAC address model A PE implementation MAY choose to support either the shared B-MAC
and MAY support the dedicated B-MAC address model. address model or the dedicated B-MAC address model without causing
any interoperability issues.
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
configured with that I-SID. 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
skipping to change at page 14, line 46 skipping to change at page 14, line 48
Advertisement route for the associated B-MAC, with the MAC Mobility Advertisement route for the associated B-MAC, with the MAC Mobility
Extended Community attribute. The value of the Counter field in that Extended Community attribute. The value of the Counter field in that
attribute must be incremented prior to advertisement. This causes the attribute must be incremented prior to advertisement. This causes the
remote PE nodes to flush all C-MAC addresses associated with the B- remote PE nodes to flush all C-MAC addresses associated with the B-
MAC in question. This is done across all I-SIDs that are mapped to MAC in question. This is done across all I-SIDs that are mapped to
the EVI of the withdrawn/readvertised MAC route. the EVI of the withdrawn/readvertised MAC route.
7.3. Network Multi-homing 7.3. Network Multi-homing
When an Ethernet network is multi-homed to a set of PE nodes running When an Ethernet network is multi-homed to a set of PE nodes running
PBB-EVPN, a single-active redundancy model can be supported with per PBB-EVPN, Single-Active redundancy model can be supported with per
service instance (i.e. I-SID) load-balancing. In this model, DF service instance (i.e. I-SID) load-balancing. In this model, DF
election is performed to ensure that a single PE node in the election is performed to ensure that a single PE node in the
redundancy group is responsible for forwarding traffic associated redundancy group is responsible for forwarding traffic associated
with a given I-SID. This guarantees that no forwarding loops are with a given I-SID. This guarantees that no forwarding loops are
created. Filtering based on DF state applies to both unicast and created. Filtering based on DF state applies to both unicast and
multicast traffic, and in both access-to-core as well as core-to- multicast traffic, and in both access-to-core as well as core-to-
access directions (unlike the multi-homed device scenario where DF access directions just like Single-Active multi-homed device scenario
filtering is limited to multi-destination frames in the core-to- (but unlike All-Active multi-homed device scenario where DF filtering
access direction). Similar to the multi-homed device scenario, with is limited to multi-destination frames in the core-to-access
I-SID based load-balancing, a unique B-MAC address is assigned to direction). Similar to Single-Active multi-homed device scenario,
each of the PE nodes connected to the multi-homed network (Segment). with I-SID based load-balancing, a unique B-MAC address is assigned
to 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 [PBB] Backbone Edge Bridge (BEB) Module, which hosts the [PBB] 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
skipping to change at page 17, line 26 skipping to change at page 17, line 26
|<------------------------- PBB -------------------------->| DP |<------------------------- PBB -------------------------->| DP
|<----MPLS----->| |<----MPLS----->|
Legend: CP = Control Plane View Legend: CP = Control Plane View
DP = Data Plane View DP = Data Plane View
Figure 7: Interconnecting 802.1aq/802.1Qbp Networks with PBB-EVPN Figure 7: Interconnecting 802.1aq/802.1Qbp Networks with PBB-EVPN
9.1. B-MAC Address Assignment 9.1. B-MAC Address Assignment
The B-MAC addresses need to be globally unique across all the IEEE The B-MAC addresses need to be globally unique across all networks
802.1aq / 802.1Qbp networks. Given that each network operator has including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC
typically have its own assigned Organizationally Unique Identifier addresses used for Single-Home and Single-Active Ethernet Segments
(OUI), the assignment of unique B-MAC addresses shouldn't be an should be unique because they are typically auto-derived from PE's
issue. pools of reserved MAC addresses that are unique. The B-MAC addresses
used for All-Active Ethernet Segments should also be unique given
that each network operator typically has its own assigned
Organizationally Unique Identifier (OUI) and thus can assign its own
unique MAC addresses.
9.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement 9.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement
B-MAC addresses associated with 802.1aq / 802.1Qbp switches are B-MAC addresses associated with 802.1aq / 802.1Qbp switches are
advertised using the EVPN MAC/IP route advertisement already defined advertised using the EVPN MAC/IP route advertisement already defined
in [EVPN]. in [EVPN].
9.4. Operation: 9.4. Operation:
When a PE receives a PBB-encapsulated Ethernet frame from the access When a PE receives a PBB-encapsulated Ethernet frame from the access
skipping to change at page 18, line 42 skipping to change at page 18, line 46
10.2. C-MAC Mobility Independent of B-MAC Advertisements 10.2. C-MAC Mobility Independent of B-MAC Advertisements
As described above, in PBB-EVPN, a single B-MAC address can aggregate As described above, in PBB-EVPN, a single B-MAC address can aggregate
many C-MAC addresses. Given that B-MAC addresses are associated with many C-MAC addresses. Given that B-MAC addresses are associated with
segments attached to a PE or to the PE itself, their locations are segments attached to a PE or to the PE itself, their locations are
fixed and thus not impacted what so ever by C-MAC mobility. fixed and thus not impacted what so ever by C-MAC mobility.
Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any
re-advertisements of them). This is because the C-MAC address to B- re-advertisements of them). This is because the C-MAC address to B-
MAC address association is learnt in the data-plane and C-MAC MAC address association is learnt in the data-plane and C-MAC
addresses are not advertised in BGP. Aggregation via B-MAC addresses addresses are not advertised in BGP. Aggregation via B-MAC addresses
in PBB-EVPN perform much better than EVPN even if MAC subnet is used in PBB-EVPN performs much better than EVPN.
in EVPN. This is because MAC mobility punctures many holes in a MAC
subnet and effectively renders useless the aggregation property of a
subnet in EVPN.
To illustrate how this compares to EVPN, consider the following To illustrate how this compares to EVPN, consider the following
example: example:
If a PE running EVPN advertises reachability for a MAC subnet that If a PE running EVPN advertises reachability for N MAC addresses via
spans N addresses via a particular segment, and then 50% of the MAC a particular segment, and then 50% of the MAC addresses in that
addresses in that subnet move to other segments (e.g. due to virtual segment move to other segments (e.g. due to virtual machine
machine mobility), then in the worst case, N/2 additional MAC mobility), then N/2 additional MAC Advertisement routes need to be
Advertisement routes need to be sent for the MAC addresses that have sent for the MAC addresses that have moved. With PBB-EVPN, on the
moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on other hand, the B-MAC addresses which are statically associated with
the other hand, the B-MAC addresses which are statically associated PE nodes, are not subject to mobility. As C-MAC addresses move from
with PE nodes, are not subject to mobility. As C-MAC addresses move one segment to another, the binding of C-MAC to B-MAC addresses is
from one segment to another, the binding of C-MAC to B-MAC addresses updated via data-plane learning in PBB-EVPN.
is updated via data-plane learning in PBB-EVPN.
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, PE 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, PE 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.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind
CE1 via data-plane learning. If AC1 fails, then PE3 does not need to CE1 via data-plane learning. If AC1 fails, then PE3 does not need to
flush any of the C-MAC addresses learnt and associated with BM1. This flush any of the C-MAC addresses learnt and associated with BM1. This
is because PE1 will withdraw the MAC Advertisement routes associated is because PE1 will withdraw the MAC Advertisement routes associated
with BM1, thereby leading PE3 to have a single adjacency (to PE2) for with BM1, thereby leading PE3 to have a single adjacency (to PE2) for
this B-MAC address. Therefore, the topology change is communicated to this B-MAC address. Therefore, the topology change is communicated to
PE3 and no C-MAC address flushing is required. PE3 and no C-MAC address flushing is required.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Jose Liste and Patrice Brissette for The authors would like to thank Sami Boutros, Jose Liste, and Patrice
their reviews and comments of this document. Brissette for their reviews and comments of this document. We would
also like to thank Giles Heron for several rounds of reviews and
providing valuable inputs to get this draft ready for IESG
submission.
12. Security Considerations 12. Security Considerations
All the security considerations in [EVPN] apply directly to this All the security considerations in [EVPN] apply directly to this
document because this document leverages [EVPN] control plane and document because this document leverages [EVPN] control plane and
their associated procedures - although not the complete set but their associated procedures - although not the complete set but
rather a subset. rather a subset.
13. IANA Considerations 13. IANA Considerations
 End of changes. 14 change blocks. 
57 lines changed or deleted 62 lines changed or added

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