draft-ietf-l2vpn-pbb-evpn-05.txt   draft-ietf-l2vpn-pbb-evpn-06.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: January 16, 2014 July 16, 2013 Expires: April 18, 2014 October 18, 2013
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-05 draft-ietf-l2vpn-pbb-evpn-06
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 43 skipping to change at page 2, line 43
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7
6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7 6.2. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7
6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 8 6.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 8
6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 8 6.4. Ethernet Segment Route . . . . . . . . . . . . . . . . . . 8
7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 8
7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8 6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 8
7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 8 6.7. MAC Mobility Extended Community . . . . . . . . . . . . . 8
7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 8 6.8. Default Gateway Extended Community . . . . . . . . . . . . 9
7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 8
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 10 7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2.1.3 Split Horizon and Designated Forwarder Election . . 11 7.1. MAC Address Distribution over Core . . . . . . . . . . . . 9
7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 11 7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 9
7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 11 7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 9
7.2.2.2 Split Horizon and Designated Forwarder Election . . 12 7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 9
7.2.2.3 Handling Failure Scenarios . . . . . . . . . . . . . 12 7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 11
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 13 7.2.1.3 Split Horizon and Designated Forwarder Election . . 12
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13 7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 12
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 12
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 14 7.2.2.2 Split Horizon and Designated Forwarder Election . . 13
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14 7.2.2.3 Handling Failure Scenarios . . . . . . . . . . . . . 13
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 14
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 14
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 14
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 15
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 15 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 15
9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 15 9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 16
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 15 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 16
9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 16 10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 17
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 16 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 17
10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 17 10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 18
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 Networks . . . . . . . . . . . . . . . . . . . . . . . . 18
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 18 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 19
10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 18 10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Intellectual Property Considerations . . . . . . . . . . . . 19 14. Intellectual Property Considerations . . . . . . . . . . . . 20
15. Normative References . . . . . . . . . . . . . . . . . . . . 19 15. Normative References . . . . . . . . . . . . . . . . . . . . 20
16. Informative References . . . . . . . . . . . . . . . . . . . 19 16. Informative References . . . . . . . . . . . . . . . . . . . 20
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 17. 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. [802.1ah] defines an architecture for Ethernet MPLS/IP network. [PBB] defines an architecture for Ethernet Provider
Provider Backbone Bridging (PBB), where MAC tunneling is employed to Backbone Bridging (PBB), where MAC tunneling is employed to improve
improve service instance and MAC address scalability in Ethernet as service instance and MAC address scalability in Ethernet as well as
well as VPLS networks [PBB-VPLS]. VPLS networks [PBB-VPLS].
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 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.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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 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 Backbone Edge Bridge (BEB)
(BEB) functionality on the EVPN PE nodes similar to PBB-VPLS, where functionality on the EVPN PE nodes similar to PBB-VPLS, where BEB
BEB functionality is incorporated in the VPLS PE nodes. The PE functionality is incorporated in the VPLS PE nodes. The PE devices
devices would then receive 802.1Q Ethernet frames from their would then receive 802.1Q Ethernet frames from their attachment
attachment circuits, encapsulate them in the PBB header and forward circuits, encapsulate them in the PBB header and forward the frames
the frames over the IP/MPLS core. On the egress EVPN PE, the PBB over the IP/MPLS core. On the egress EVPN PE, the PBB header is
header is removed following the MPLS disposition, and the original removed following the MPLS disposition, and the original 802.1Q
802.1Q Ethernet frame is delivered to the customer equipment. Ethernet frame is delivered to the customer equipment.
BEB +--------------+ BEB BEB +--------------+ BEB
|| | | || || | | ||
\/ | | \/ \/ | | \/
+----+ AC1 +----+ | | +----+ +----+ +----+ AC1 +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE2| | CE1|-----| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+ +----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+ \ +----+ | Network | +----+
\ | | \ | |
AC2\ +----+ | | AC2\ +----+ | |
\| | | | \| | | |
skipping to change at page 7, line 9 skipping to change at page 7, line 9
|| ||
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 from traffic
ingress from the core per [802.1ah] bridging operation. ingress 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).
6. BGP Encoding 6. BGP Encoding
PBB-EVPN leverages the same BGP Routes and Attributes defined in PBB-EVPN leverages the same BGP Routes and Attributes defined in
[EVPN], adapted as follows: [EVPN], adapted as follows:
6.1. BGP MAC Advertisement Route 6.1. Ethernet Auto-Discovery Route
This route and all of its associated modes are not needed in PBB-
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.2. BGP MAC Advertisement Route
The EVPN MAC Advertisement Route is used to distribute B-MAC The EVPN MAC Advertisement Route is used to distribute B-MAC
addresses of the PE nodes instead of the C-MAC addresses of end- addresses of the PE nodes instead of the C-MAC addresses of end-
stations/hosts. This is because the C-MAC addresses are learnt in the stations/hosts. This is because the C-MAC addresses are learnt in the
data-plane for traffic arriving from the core. The MAC Advertisement data-plane for traffic arriving from the core. The MAC Advertisement
Route is encoded as follows: Route is encoded as follows:
- The MAC address field contains the B-MAC address. - The MAC address field contains the B-MAC address.
- The Ethernet Tag field is set to 0. - The Ethernet Tag field is set to 0.
- The Ethernet Segment Identifier field must be set either to 0 (for - The Ethernet Segment Identifier field must be set either to 0 (for
single-homed Segments or multi-homed Segments with per-ISID load- single-homed Segments or multi-homed Segments with per-ISID load-
balancing) or to MAX-ESI (for multi-homed Segments with per-flow balancing) or to MAX-ESI (for multi-homed Segments with per-flow
load-balancing). All other values are not permitted. load-balancing). All other values are not permitted.
The route is tagged with the RT corresponding to the EVI associated - All other fields are set as defined in [EVPN].
with the B-MAC address.
All other fields are set as defined in [EVPN]. This route is tagged with the RT corresponding to its EVI. This EVI
is analogous to a B-VID.
6.2. Ethernet Auto-Discovery Route 6.3. Inclusive Multicast Ethernet Tag Route
This route and all of its associated modes are not needed in PBB- This route is used for multicast pruning per I-SID. It is used for
EVPN. auto-discovery of PEs participating in a given I-SID so that a
multicast tunnel (MP2P, P2P, P2MP, or MP2MP LSP) can be setup for
that I-SID . [PBB-VPLS] uses multicast pruning per I-SID based on
[MMRP] which is a soft-state protocol. The advantages of multicast
pruning using this BGP route over [MMRP] are that a) it scales very
well for large number of PEs and b) it works with any type of LSP
(MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P PWs.
The Inclusive Multicast Ethernet Tag Route is encoded as follow:
The receiving PE knows that it need not wait for the receipt of the - The Ethernet Tag field is set with the appropriate I-SID value.
Ethernet A-D route for route resolution by means of the reserved ESI - All other fields are set as defined in [EVPN].
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 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
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
[EVPN].
PBB-EVPN uses the same set of route targets defined in [EVPN]. The 6.4. Ethernet Segment Route
future revision of this document will describe new RT types.
6.4. MAC Mobility Extended Community This route is used as defined in [EVPN].
This extended community is defined in [EVPN]. When used in PBB-EVPN, 6.5. ESI Label Extended Community
it indicates that the C-MAC forwarding tables for the I-SIDs
associated with the RT tagging the MAC Advertisement route must be
flushed.
Note that all other BGP messages and/or attributes are used as This extended community is not used in PBB-EVPN. In [EVPN], this
defined in [EVPN]. extended community is used along with the Ethernet AD route to
advertise an MPLS label for the purpose of split-horizon filtering.
Since in PBB-EVPN, the split-horizon filtering is performed natively
using BMAC SA, there is no need for this extended community.
6.6. ES-Import Route Target
This RT is used as defined in [EVPN].
6.7. MAC Mobility Extended Community
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
with the RT corresponding to its EVI (which is analogous to a B-VID).
When this extended community is used along with a BMAC rotue in PBB-
EVPN, it indicates that the C-MAC forwarding tables for all the I-
SIDs associated with the RT tagging this BMAC Advertisement route
must be flushed.
6.8. Default Gateway Extended Community
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].
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
skipping to change at page 8, line 47 skipping to change at page 9, line 40
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 PE 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 [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 and flow-based load-balancing, a given C-MAC address would
be reachable via multiple PE nodes concurrently. Given that any given be reachable via multiple PE nodes concurrently. Given that any given
remote PE will bind the C-MAC address to a single B-MAC address, then remote PE will bind the C-MAC address to a single B-MAC address, then
the various PE nodes connected to the same CE must share the same B- the various PE nodes connected to the same CE must share the same B-
MAC address. Otherwise, the MAC address table of the remote PE nodes MAC address. Otherwise, the MAC address table of the remote PE nodes
skipping to change at page 11, line 22 skipping to change at page 12, line 16
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, 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 [PBB]
[802.1ah] defines this B-MAC address based filtering function as part defines this B-MAC address based filtering function as part of the I-
of the I-Component options, hence no new functions are required to Component options, hence no new functions are required to support
support split-horizon beyond what is already defined in [802.1ah]. split-horizon beyond what is already defined in [PBB]. Given that the
Given that the Segment label is not used in PBB-EVPN, the PE sets the Segment label is not used in PBB-EVPN, the PE sets the Label field in
Label field in the Ethernet Segment Route to 0. 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 a single-active redundancy model with per-ISID load-
balancing. balancing.
7.2.2.1 PE B-MAC Address Assignment 7.2.2.1 PE B-MAC Address Assignment
In the case where per-ISID load-balancing is desired among the PE In the case where per-ISID load-balancing is desired among the PE
nodes in a given redundancy group, multiple unicast B-MAC addresses nodes in a given redundancy group, multiple unicast B-MAC addresses
are allocated per multi-homed Ethernet Segment: Each PE connected to are allocated per multi-homed Ethernet Segment: Each PE connected to
the multi-homed segment is assigned a unique B-MAC. Every PE then the multi-homed segment is assigned a unique B-MAC. Every PE then
advertises its B-MAC address using the BGP MAC advertisement route. advertises its B-MAC address using the BGP MAC advertisement route.
In this mode of operation, two B-MAC address assignment models are In this mode of operation, two B-MAC address assignment models are
skipping to change at page 13, line 26 skipping to change at page 14, line 20
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 MAC route. the EVI of the withdrawn MAC route.
7.3. Network Multi-homing 7.3. Network Multi-homing
When an Ethernet network is multi-homed to a set of PE nodes running When an Ethernet network is multi-homed to a set of PE nodes running
PBB-EVPN, an all-active redundancy model can be supported with per PBB-EVPN, a 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 (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 PE 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 [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
Known unicast traffic received from the AC will be PBB-encapsulated Known unicast traffic received from the AC will be PBB-encapsulated
by the PE 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
skipping to change at page 14, line 21 skipping to change at page 15, line 15
For unknown unicast traffic, the PE 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 PE using the B-MAC source address corresponding encapsulated by the PE using the B-MAC source address corresponding
to the originating site. The multicast B-MAC destination address is to the originating site. The multicast B-MAC destination address is
selected based on the value of the I-SID as defined in [802.1ah]. The selected based on the value of the I-SID as defined in [PBB]. 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 EVPN ingress replication label advertised in the label and the EVPN ingress replication label advertised in the
Inclusive Multicast Route. Inclusive Multicast Route.
Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the
procedures defined in [EVPN]. This includes either the use of procedures defined in [EVPN]. This includes either the use of
skipping to change at page 19, line 7 skipping to change at page 20, line 7
addresses of the servers/hosts behind CE1 via data-plane learning. If addresses of the servers/hosts behind CE1 via data-plane learning. If
AC1 fails, then PE3 does not need to flush any of the C-MAC addresses AC1 fails, then PE3 does not need to flush any of the C-MAC addresses
learnt and associated with BM1. This is because PE1 will withdraw the learnt and associated with BM1. This is because PE1 will withdraw the
MAC Advertisement routes associated with BM1, thereby leading PE3 to MAC Advertisement routes associated with BM1, thereby leading PE3 to
have a single adjacency (to PE2) for this B-MAC address. Therefore, have a single adjacency (to PE2) for this B-MAC address. Therefore,
the topology change is communicated to PE3 and no C-MAC address the topology change is communicated to PE3 and no C-MAC address
flushing is required. flushing is required.
11. Acknowledgements 11. Acknowledgements
TBD. The authors would like to thank Jose Liste and Patrice Brissette for
their reviews and comments of this document.
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.
13. IANA Considerations 13. IANA Considerations
This document requires IANA to assign a new SAFI value for L2VPN_MAC This document requires IANA to assign a new SAFI value for L2VPN_MAC
SAFI. SAFI.
14. Intellectual Property Considerations 14. Intellectual Property Considerations
This document is being submitted for use in IETF standards This document is being submitted for use in IETF standards
discussions. discussions.
15. Normative References 15. Normative References
[802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider [PBB] Clauses 25 and 26 of "IEEE Standard for Local and metropolitan
Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008. area networks - Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2013.
16. Informative References 16. Informative References
[PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider [PBB-VPLS] Sajassi, et al., "VPLS Interoperability with Provider
Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop- Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop-
05.txt, work in progress, July, 2011. 05.txt, work in progress, October, 2013.
[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (EVPN)", [EVPN-REQ] Sajassi, et al., "Requirements for Ethernet VPN (EVPN)",
draft-ietf-l2vpn-evpn-req-04.txt, work in progress, July, draft-ietf-l2vpn-evpn-req-05.txt, work in progress,
2011. October, 2013.
[EVPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [EVPN] Sajassi, et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-04.txt, work in progress, February, 2012. l2vpn-evpn-04.txt, work in progress, July, 2013.
[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2013.
17. Authors' Addresses 17. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
595 Burrard Street, Suite # 2123 595 Burrard Street, Suite # 2123
Vancouver, BC V7X 1J1, Canada Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com Email: ssalam@cisco.com
Sami Boutros Sami Boutros
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
 End of changes. 32 change blocks. 
95 lines changed or deleted 143 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/