< draft-ietf-l2vpn-pbb-evpn-07.txt   draft-ietf-l2vpn-pbb-evpn-08.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: December 18, 2014 June 18, 2014 Expires: April 18, 2015 October 18, 2014
PBB-EVPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-07 draft-ietf-l2vpn-pbb-evpn-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document discusses how Ethernet Provider Backbone Bridging This document discusses how Ethernet Provider Backbone Bridging (PBB)
[802.1ah] can be combined with EVPN in order to reduce the number of can be combined with Ethernet VPN (EVPN) in order to reduce the
BGP MAC advertisement routes by aggregating Customer/Client MAC (C- number of BGP MAC advertisement routes by aggregating Customer/Client
MAC) addresses via Provider Backbone MAC address (B-MAC), provide MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC),
client MAC address mobility using C-MAC aggregation and B-MAC sub- provide client MAC address mobility using C-MAC aggregation, confine
netting, confine the scope of C-MAC learning to only active flows, the scope of C-MAC learning to only active flows, offer per site
offer per site policies and avoid C-MAC address flushing on topology policies and avoid C-MAC address flushing on topology changes. The
changes. The combined solution is referred to as PBB-EVPN. combined solution is referred to as PBB-EVPN.
Conventions Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 Independent of B-MAC Advertisements . . . . 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. No C-MAC Address Flushing for All-Active Multi-Homing . . 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 . . . . . . . . . . . . . . . 8 6.2. MAC/IP 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 . . . . . . . . . . . . . . . . . . 9
6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 9 6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 9
6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 9 6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 9
6.7. MAC Mobility Extended Community . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10
7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 10 7.2.1. Flow-based Load-balancing . . . . . . . . . . . . . . . 10
7.2.1.1 PE B-MAC Address Assignment . . . . . . . . . . . . 10 7.2.1.1. PE B-MAC Address Assignment . . . . . . . . . . . 10
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 12 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 . . . . . . . . . . . . . . . 13 7.2.2. I-SID Based Load-balancing . . . . . . . . . . . . . . 13
7.2.2.1 PE B-MAC Address Assignment . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 15 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 15
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 15 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 15
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15
7.5. MPLS Encapsulation of PBB Frames . . . . . . . . . . . . . 16
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 16 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 16
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 16 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 16
9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 16 9.1. B-MAC Address Assignment . . . . . . . . . . . . . . . . . 17
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 17 9.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement . . . 17
9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.4. Operation: . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 17 10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 18
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18
10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 18 10.2. C-MAC Mobility Independent of B-MAC Advertisements . . . 18
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 18 10.3. C-MAC Address Learning and Confinement . . . . . . . . . 19
10.4. Seamless Interworking with TRILL and 802.1aq Access 10.4. Seamless Interworking with 802.1aq Access Networks . . . 19
Networks . . . . . . . . . . . . . . . . . . . . . . . . 19 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 20
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 19 10.6. No C-MAC Address Flushing for All-Active Multi-Homing . . 20
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. Normative References . . . . . . . . . . . . . . . . . . . . 20
15. Normative References . . . . . . . . . . . . . . . . . . . . 20 15. Informative References . . . . . . . . . . . . . . . . . . . 20
16. Informative References . . . . . . . . . . . . . . . . . . . 20 16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
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. [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 [PBB-VPLS]. 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 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 4, line 43 skipping to change at page 4, line 43
Sam Aldrin, Huawei Sam Aldrin, Huawei
Himanshu Shah, Ciena Himanshu Shah, Ciena
Florin Balus, ALU 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 ES: Ethernet Segment
DHN: Dual-homed Network ESI: Ethernet Segment Identifier
LACP: Link Aggregation Control Protocol LSP: Label Switched Path
LSM: Label Switched Multicast
MDT: Multicast Delivery Tree
MP2MP: Multipoint to Multipoint MP2MP: Multipoint to Multipoint
MP2P: Multipoint to Point
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
PW: Pseudowire
EVPN: Ethernet VPN EVPN: Ethernet VPN
EVI: EVPN Instance
RT: Route Target
Single-Active Redundancy Mode: When only a single PE, among a group Single-Active Redundancy Mode: When only a single PE, among a group
of PEs attached to an Ethernet segment, is allowed to forward traffic of PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet Segment, then the Ethernet segment is defined to/from that Ethernet Segment, then the Ethernet segment is defined
to be operating in Single-Active redundancy mode. to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward traffic to/from that Ethernet Segment, segment are allowed to forward traffic to/from that Ethernet Segment,
then the Ethernet segment is defined to be operating in All-Active then the Ethernet segment is defined to be operating in All-Active
redundancy mode. 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 [RFC7209], 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
data center interconnect (DCI) scenarios 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. scheme, as is provided by PBB.
4.2. C-MAC Mobility with MAC Summarization 4.2. C-MAC Mobility Independent of B-MAC Advertisements
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, the support for fast C-MAC address mobility. For these applications, when
exact virtual machine MAC address needs to be transmitted in BGP MAC using EVPN, the virtual machine MAC address needs to be transmitted
Advertisement route. Otherwise, traffic would be forwarded to the in BGP MAC Advertisement route. Otherwise, traffic would be forwarded
wrong segment when a virtual machine moves from one Ethernet segment to the wrong segment when a virtual machine moves from one Ethernet
to another. This means MAC address prefixes cannot be used in data segment to another. This means MAC address prefixes cannot be used in
center applications. data center applications.
In order 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, PBB technology is used. It scalability benefits of MAC summarization, PBB technology is used. It
defines a Backbone MAC (B-MAC) address space that is independent of defines a Backbone MAC (B-MAC) address space that is independent of
the C-MAC address space, and aggregate C-MAC addresses via a B-MAC the C-MAC address space, and aggregates C-MAC addresses via a single
address and then apply summarization to B-MAC addresses. B-MAC address.
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 23 skipping to change at page 6, line 23
millions of C-MAC addresses, this introduces a non-trivial waste of millions of C-MAC addresses, this introduces a non-trivial waste of
PE resources. As such, it is required to confine the scope of PE resources. As such, it is required to confine the scope of
visibility of C-MAC addresses only to those PE nodes that are visibility of C-MAC addresses only to those PE nodes that are
actively involved in forwarding traffic to, or from, these addresses. actively involved in forwarding traffic to, or from, these addresses.
4.4. Per Site Policy Support 4.4. Per Site Policy Support
In many applications, it is required to be able to enforce In many applications, it is required to be able to enforce
connectivity policy rules at the granularity of a site (or segment). connectivity policy rules at the granularity of a site (or segment).
This includes the ability to control which PE nodes in the network This includes the ability to control which PE nodes in the network
can forward traffic to, or from, a given site. PBB-EVPN is capable of can forward traffic to, or from, a given site. Both EVPN and PBB-EVPN
providing this granularity of policy control. In the case where per are capable of providing this granularity of policy control. In the
C-MAC address granularity is required, the EVI can always continue to case where the policy needs to be at the granularity of per C-MAC
operate in EVPN mode. address, then C-MAC address learning in control-plane (in BGP) per
[EVPN] should be used.
4.5. Avoiding C-MAC Address Flushing 4.5. No C-MAC Address Flushing for All-Active Multi-Homing
It is required to avoid C-MAC address flushing upon link, port or Just as in [EVPN], it is required to avoid C-MAC address flushing
node failure for All-Active multi-homed devices and networks. This is upon link, port or node failure for All-Active multi-homed segments.
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 33 skipping to change at page 7, line 33
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 for traffic - Learn remote C-MAC to B-MAC bindings in the data-plane for traffic
received 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 B-MAC addresses that uniquely identify the
the device. More on the PE addressing in section 5. device. B-MAC address assignment is described in details in section
7.2.2.
- 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. Ethernet Auto-Discovery Route 6.1. Ethernet Auto-Discovery Route
This route and all of its associated modes are not needed in PBB- This route and all of its associated modes are not needed in PBB-EVPN
EVPN. because PBB encapsulation provides the required level of indirection
for C-MAC addresses - i.e., an ES can be represented by a B-MAC
address for the purpose of data-plane learning/forwarding.
The receiving PE knows that it need not wait for the receipt of the The receiving PE knows that it need not wait for the receipt of the
Ethernet A-D route for route resolution by means of the reserved ESI Ethernet A-D route for route resolution by means of the reserved
encoded in the MAC Advertisement route: the ESI values of 0 and MAX- Ethernet Segment Identifier (ESI) encoded in the MAC Advertisement
ESI indicate that the receiving PE can resolve the path without an route: the ESI values of 0 and MAX-ESI indicate that the receiving PE
Ethernet A-D route. can resolve the path without an Ethernet A-D route.
6.2. BGP MAC Advertisement Route 6.2. MAC/IP Advertisement Route
The EVPN MAC Advertisement Route is used to distribute B-MAC The EVPN MAC/IP 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.
- All other fields are set as defined in [EVPN]. - All other fields are set as defined in [EVPN].
This route is tagged with the RT corresponding to its EVI. This EVI This route is tagged with the Route Target (RT) corresponding to its
is analogous to a B-VID. EVI. This EVI is analogous to a B-VID.
6.3. Inclusive Multicast Ethernet Tag Route 6.3. Inclusive Multicast Ethernet Tag Route
This route is used for multicast pruning per I-SID. It is used for This route is used for multicast pruning per I-SID. It is used for
auto-discovery of PEs participating in a given I-SID so that a 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 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 that I-SID . [RFC7080] uses multicast pruning per I-SID based on
[MMRP] which is a soft-state protocol. The advantages of multicast [MMRP] which is a soft-state protocol. The advantages of multicast
pruning using this BGP route over [MMRP] are that a) it scales very 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 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. (MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P
The Inclusive Multicast Ethernet Tag Route is encoded as follow: pseudowires. The Inclusive Multicast Ethernet Tag Route is encoded as
follow:
- 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 8.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 auto-discovery of member PEs belonging to a given
redundancy group (e.g., attached to a given Ethernet Segment) per
[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 B-MAC 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
skipping to change at page 10, line 4 skipping to change at page 10, line 7
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 mode (i.e., 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 mode, a given C-MAC address would be reachable via redundancy mode, a given C-MAC address would be reachable via
multiple PE nodes concurrently. Given that any given remote PE will multiple PE nodes concurrently. Given that any given remote PE will
bind the C-MAC address to a single B-MAC address, then the various PE bind the C-MAC address to a single B-MAC address, then the various PE
skipping to change at page 12, line 4 skipping to change at page 12, line 4
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 sites or a unicast B-MAC address per single-homed site
in addition, a unicast B-MAC address per All-Active multi-homed CE. and, in addition, a unicast B-MAC address per All-Active multi-homed
In the latter case, the B-MAC address MUST be the same for all PE site. In the latter case, the B-MAC address MUST be the same for all
nodes in a Redundancy Group connected to the same CE. 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 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 Link Aggregation Control Protocol (LACP)
'Locally Administered' bit of the CE's address. This guarantees the System Identifier by flipping the 'Locally Administered' bit of the
uniqueness of the B-MAC address within the network, and ensures that CE's address. This guarantees the uniqueness of the B-MAC address
all PE nodes connected to the same multi-homed CE use the same value within the network, and ensures that all PE nodes connected to the
for the B-MAC address. same multi-homed 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 multi-homed CEs, it is not possible to support the
uncommon scenario where a CE has multiple bundles towards the PE uncommon scenario where a CE has multiple link bundles within the
nodes, and the service involves hair-pinning traffic from one bundle same LACP session towards the PE nodes, and the service involves
to another. This is because the split-horizon filtering relies on B- hair-pinning traffic from one bundle to another. This is because the
MAC addresses rather than Site-ID Labels (as will be described in the split-horizon filtering relies on B-MAC addresses rather than Site-ID
next section). The operator must explicitly configure the B-MAC Labels (as will be described in the next section). The operator must
address for this fairly uncommon service scenario. explicitly configure the B-MAC address for this fairly uncommon
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
transmit an MAC Advertisement Route for the B-MAC address with a transmit an MAC Advertisement Route for the B-MAC address with a
downstream assigned MPLS label that uniquely identifies that address downstream assigned MPLS label that uniquely identifies that address
on the advertising PE. The route is tagged with the RTs of the on the advertising PE. The route is tagged with the RTs of the
associated EVIs as described above. associated EVIs as described above.
7.2.1.3 Split Horizon and Designated Forwarder Election 7.2.1.3 Split Horizon and Designated Forwarder Election
[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, Ethernet Segment (ES) originating site of a given frame. As such, Ethernet Segment (ES)
Labels are not used in PBB-EVPN, and the egress split-horizon Labels are not used in PBB-EVPN, and the egress split-horizon
filtering is done based on the B-MAC source address. It is worth filtering is done based on the B-MAC source address. It is worth
noting here that [PBB] defines this B-MAC address based filtering noting here that [PBB] defines this B-MAC address based filtering
function as part of the I-Component options, hence no new functions function as part of the I-Component options, hence no new functions
are required to support split-horizon beyond what is already defined are required to support split-horizon beyond what is already defined
in [PBB]. Given that the ES label is not used in PBB-EVPN, the PE in [PBB].
sets the Label field in the Ethernet Segment Route to 0.
The Designated Forwarder election procedures are defined in [EVPN]. The Designated Forwarder election procedures are defined in [EVPN].
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 mode 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
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. This includes the single-homed segments as well as the Segments (ES's). This includes the single-homed segments as well as
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 Ethernet Segment - The PE may use a dedicated B-MAC address for each ES operating with
operating with per-ISID load-balancing mode. 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
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
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
When a PE connected to a multi-homed Ethernet Segment loses When a PE connected to a multi-homed Ethernet Segment loses
connectivity to the segment, due to link or port failure, it needs to connectivity to the segment, due to link or port failure, it needs to
notify the remote PEs to trigger C-MAC address flushing. This can be notify the remote PEs to trigger C-MAC address flushing. This can be
achieved in one of two ways, depending on the B-MAC assignment model: achieved in one of two ways, depending on the B-MAC assignment model:
- If the PE uses a shared B-MAC address for multiple Ethernet - If the PE uses a shared B-MAC address for multiple ES's, then the
Segments, then the C-MAC flushing is signaled by means of having the C-MAC flushing is signaled by means of having the failed PE re-
failed PE re-advertise the MAC Advertisement route for the associated advertise the MAC Advertisement route for the associated B-MAC,
B-MAC, tagged with the MAC Mobility Extended Community attribute. The tagged with the MAC Mobility Extended Community attribute. The value
value of the Counter field in that attribute must be incremented of the Counter field in that attribute must be incremented prior to
prior to advertisement. This causes the remote PE nodes to flush all advertisement. This causes the remote PE nodes to flush all C-MAC
C-MAC addresses associated with the B-MAC in question. This is done addresses associated with the B-MAC in question. This is done across
across all I-SIDs that are mapped to the EVI of the withdrawn MAC all I-SIDs that are mapped to the EVI of the withdrawn MAC route.
route.
- If the PE uses a dedicated B-MAC address for each Ethernet Segment - If the PE uses a dedicated B-MAC address for each Ethernet Segment
operating under per-ISID load-balancing mode, the the failed PE operating under per-ISID load-balancing mode, the the failed PE
simply withdraws the B-MAC route previously advertised for that simply withdraws the B-MAC route previously advertised for that
segment. This causes the remote PE nodes to flush all C-MAC addresses segment. This causes the remote PE nodes to flush all C-MAC addresses
associated with the B-MAC in question. This is done across all I-SIDs associated with the B-MAC in question. This is done across all I-SIDs
that are mapped to the EVI of the withdrawn MAC route. that are mapped to the EVI of the withdrawn MAC route.
When a PE connected to a multi-homed Ethernet Segment fails (i.e. When a PE connected to a multi-homed Ethernet Segment fails (i.e.
node failure) or when the PE becomes completely isolated from the node failure) or when the PE becomes completely isolated from the
skipping to change at page 14, line 42 skipping to change at page 14, line 41
re-advertises the associated Ethernet Segment route to other members re-advertises the associated Ethernet Segment route to other members
of its Redundancy Group. This triggers the backup PE(s) in the of its Redundancy Group. This triggers the backup PE(s) in the
Redundancy Group to block the I-SIDs for which the recovered PE is a Redundancy Group to block the I-SIDs for which the recovered PE is a
DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address
flush notification to the remote PEs by re-advertising the MAC flush notification to the remote PEs by re-advertising the MAC
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/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, 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
skipping to change at page 15, line 31 skipping to change at page 15, line 30
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
the two is done via transparent learning of reverse traffic). The the two is done via transparent learning of reverse traffic). The
resulting frame is then encapsulated with an LSP tunnel label and the resulting frame is then encapsulated with an LSP tunnel label and the
MPLS label which uniquely identifies the B-MAC destination address on MPLS label which uniquely identifies the B-MAC destination address on
the egress PE. If per flow load-balancing over ECMPs in the MPLS core the egress PE. If per flow load-balancing over ECMPs in the MPLS core
is required, then a flow label is added as the end of stack label. is required, then a flow label is added below the label associated
with the BMAC address in the label stack.
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 [PBB]. 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 or P2P tunnel LSPs. The frame is encapsulated with a
label and the EVPN ingress replication label advertised in the tunnel LSP label and the EVPN ingress replication label advertised in
Inclusive Multicast Route. the 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
Inclusive or Aggregate Inclusive trees. Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS
Forwarder can use MP2MP tunnel LSP if Inclusive trees are used.
Note that the same procedures for advertising and handling the Note that the same procedures for advertising and handling the
Inclusive Multicast Route defined in [EVPN] apply here. Inclusive Multicast Route defined in [EVPN] apply here.
7.5. MPLS Encapsulation of PBB Frames
The encapsulation for the transport of PBB frames over MPLS is
similar to that of classical Ethernet, albeit with the additional PBB
header, as shown in the figure below:
+------------------+
| IP/MPLS Header |
+------------------+
| PBB Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 8: PBB over MPLS Encapsulation
8. Minimizing ARP Broadcast 8. Minimizing ARP Broadcast
The PE nodes implement an ARP-proxy function in order to minimize the The PE nodes implement an ARP-proxy function in order to minimize the
volume of ARP traffic that is broadcasted over the MPLS network. This volume of ARP traffic that is broadcasted over the MPLS network. This
is achieved by having each PE node snoop on ARP request and response is achieved by having each PE node snoop on ARP request and response
messages received over the access interfaces or the MPLS core. The PE messages received over the access interfaces or the MPLS core. The PE
builds a cache of IP / MAC address bindings from these snooped builds a cache of IP / MAC address bindings from these snooped
messages. The PE then uses this cache to respond to ARP requests messages. The PE then uses this cache to respond to ARP requests
ingress on access ports and targeting hosts that are in remote sites. ingress on access ports and targeting hosts that are in remote sites.
If the PE finds a match for the IP address in its ARP cache, it If the PE finds a match for the IP address in its ARP cache, it
responds back to the requesting host and drops the request. responds back to the requesting host and drops the request.
Otherwise, if it does not find a match, then the request is flooded Otherwise, if it does not find a match, then the request is flooded
over the MPLS network using either ingress replication or LSM. over the MPLS network using either ingress replication or P2MP LSPs.
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|SW1 |--| | | PE1| | PE2| | |--| SW3| |SW1 |--| | | PE1| | PE2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+ +----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4| |SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP |<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------------------------- PBB -------------------------->| DP |<------------------------- PBB -------------------------->| DP
|<----MPLS----->| |<----MPLS----->|
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
For the same reasons cited in the TRILL section, the B-MAC addresses The B-MAC addresses need to be globally unique across all the IEEE
need to be globally unique across all the IEEE 802.1aq / 802.1Qbp 802.1aq / 802.1Qbp networks. Given that each network operator has
networks. The same hierarchical address assignment scheme depicted typically have its own assigned Organizationally Unique Identifier
above is proposed for B-MAC addresses as well. (OUI), the assignment of unique B-MAC addresses shouldn't be an
issue.
9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route 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 BGP MAC Advertisement route already defined in advertised using the EVPN MAC/IP route advertisement already defined
[EVPN]. in [EVPN].
The encapsulation for the transport of PBB frames over MPLS is
similar to that of classical Ethernet, albeit with the additional PBB
header, as shown in the figure below:
+------------------+
| IP/MPLS Header |
+------------------+
| PBB Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 8: PBB over MPLS Encapsulation
9.3 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
side, it performs a lookup on the B-MAC destination address to side, it performs a lookup on the B-MAC destination address to
identify the next hop. If the lookup yields that the next hop is a identify the next hop. If the lookup yields that the next hop is a
remote PE, the local PE would then encapsulate the PBB frame in MPLS. remote PE, the local PE would then encapsulate the PBB frame in MPLS.
The label stack comprises of the VPN label (advertised by the remote The label stack comprises of the VPN label (advertised by the remote
PE), followed by an LSP/IGP label. From that point onwards, regular PE), followed by an LSP/IGP label. From that point onwards, regular
MPLS forwarding is applied. MPLS forwarding is applied.
On the disposition PE, assuming penultimate-hop-popping is employed, On the disposition PE, assuming penultimate-hop-popping is employed,
skipping to change at page 18, line 9 skipping to change at page 18, line 18
employed from this point onwards. employed from this point onwards.
10. Solution Advantages 10. Solution Advantages
In this section, we discuss the advantages of the PBB-EVPN solution In this section, we discuss the advantages of the PBB-EVPN solution
in the context of the requirements set forth in section 3 above. in the context of the requirements set forth in section 3 above.
10.1. MAC Advertisement Route Scalability 10.1. MAC Advertisement Route Scalability
In PBB-EVPN the number of MAC Advertisement Routes is a function of In PBB-EVPN the number of MAC Advertisement Routes is a function of
the number of segments (sites), rather than the number of the number of Ethernet Segments (e.g., sites), rather than the number
hosts/servers. This is because the B-MAC addresses of the PEs, rather of hosts/servers. This is because the B-MAC addresses of the PEs,
than C-MAC addresses (of hosts/servers) are being advertised in BGP. rather than C-MAC addresses (of hosts/servers) are being advertised
And, as discussed above, there's a one-to-one mapping between multi- in BGP. As discussed above, there's a one-to-one mapping between All-
homed segments and B-MAC addresses, whereas there's a one-to-one or Active multi-homed segments and their associated B-MAC addresses, and
many-to-one mapping between single-homed segments and B-MAC addresses there can be either a one-to-one or many-to-one mapping between
for a given PE. As a result, the volume of MAC Advertisement Routes Single-Active multi-homed segments and their associated B-MAC
in PBB-EVPN is multiple orders of magnitude less than EVPN. addresses, and finally there is a many-to-one mapping between single-
home sites and their associated B-MAC addresses on a given PE. This
means a single B-MAC is associated with one or more segments where
each segment can be associated with many C-MAC addresses. As a
result, the volume of MAC Advertisement Routes in PBB-EVPN may be
multiple orders of magnitude less than EVPN.
10.2. C-MAC Mobility with MAC Sub-netting 10.2. C-MAC Mobility Independent of B-MAC Advertisements
In PBB-EVPN, if a PE allocates its B-MAC addresses from a contiguous As described above, in PBB-EVPN, a single B-MAC address can aggregate
range, then it can advertise a MAC prefix rather than individual 48- many C-MAC addresses. Given that B-MAC addresses are associated with
bit addresses. It should be noted that B-MAC addresses can easily be segments attached to a PE or to the PE itself, their locations are
assigned from a contiguous range because PE nodes are within the fixed and thus not impacted what so ever by C-MAC mobility.
provider administrative domain; however, CE devices and hosts are Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any
typically not within the provider administrative domain. The re-advertisements of them). This is because the C-MAC address to B-
advantage of such MAC address sub-netting can be maintained even as MAC address association is learnt in the data-plane and C-MAC
C-MAC addresses move from one Ethernet segment to another. This is addresses are not advertised in BGP. Aggregation via B-MAC addresses
because the C-MAC address to B-MAC address association is learnt in in PBB-EVPN perform much better than EVPN even if MAC subnet is used
the data-plane and C-MAC addresses are not advertised in BGP. To in EVPN. This is because MAC mobility punctures many holes in a MAC
illustrate how this compares to EVPN, consider the following example: subnet and effectively renders useless the aggregation property of a
subnet in EVPN.
To illustrate how this compares to EVPN, consider the following
example:
If a PE running EVPN advertises reachability for a MAC subnet that If a PE running EVPN advertises reachability for a MAC subnet that
spans N addresses via a particular segment, and then 50% of the MAC spans N addresses via a particular segment, and then 50% of the MAC
addresses in that subnet move to other segments (e.g. due to virtual addresses in that subnet move to other segments (e.g. due to virtual
machine mobility), then in the worst case, N/2 additional MAC machine mobility), then in the worst case, N/2 additional MAC
Advertisement routes need to be sent for the MAC addresses that have Advertisement routes need to be sent for the MAC addresses that have
moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on
the other hand, the sub-netting applies to the B-MAC addresses which the other hand, the B-MAC addresses which are statically associated
are statically associated with PE nodes and are not subject to with PE nodes, are not subject to mobility. As C-MAC addresses move
mobility. As C-MAC addresses move from one segment to another, the from one segment to another, the binding of C-MAC to B-MAC addresses
binding of C-MAC to B-MAC addresses is updated via data-plane is updated via data-plane learning in PBB-EVPN.
learning.
10.3. C-MAC Address Learning and Confinement 10.3. C-MAC Address Learning and Confinement
In PBB-EVPN, C-MAC address reachability information is built via In PBB-EVPN, C-MAC address reachability information is built via
data-plane learning. As such, 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.
10.4. Seamless Interworking with TRILL and 802.1aq Access Networks 10.4. Seamless Interworking with 802.1aq Access Networks
Consider the scenario where two access networks, one running MPLS and Consider the scenario where two access networks, one running MPLS and
the other running 802.1aq, are interconnected via an MPLS backbone the other running 802.1aq, are interconnected via an MPLS backbone
network. The figure below shows such an example network. network. The figure below shows such an example network.
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
| CE |--| | | PE1| | PE2| | |--| CE | | CE |--| | | PE1| | PE2| | |--| CE |
skipping to change at page 19, line 34 skipping to change at page 20, line 5
plane encapsulation must be terminated on PE1 or the edge device plane encapsulation must be terminated on PE1 or the edge device
connecting to PE1. Either way, all the PE nodes that are part of the connecting to PE1. Either way, all the PE nodes that are part of the
associated service instances will be exposed to all the C-MAC associated service instances will be exposed to all the C-MAC
addresses of all hosts/servers connected to the access networks. addresses of all hosts/servers connected to the access networks.
However, if the MPLS backbone network employs PBB-EVPN, then the However, if the MPLS backbone network employs PBB-EVPN, then the
802.1aq encapsulation can be extended over the MPLS backbone, thereby 802.1aq encapsulation can be extended over the MPLS backbone, thereby
maintaining C-MAC address transparency on PE1. If PBB-EVPN is also maintaining C-MAC address transparency on PE1. If PBB-EVPN is also
extended over the MPLS access network on the right, then C-MAC extended over the MPLS access network on the right, then C-MAC
addresses would be transparent to PE2 as well. addresses would be transparent to PE2 as well.
Interoperability with TRILL access network will be described in
future revision of this draft.
10.5. Per Site Policy Support 10.5. Per Site Policy Support
In PBB-EVPN, a unique B-MAC address can be associated with every site In PBB-EVPN, the per site policy can be supported via B-MAC addresses
(single-homed or multi-homed). Given that the B-MAC addresses are via assigning a unique B-MAC address for every site/segment
sent in BGP MAC Advertisement routes, it is possible to define per (typically multi-homed but can also be single-homed). Given that the
site (i.e. B-MAC) forwarding policies including policies for E-TREE B-MAC addresses are sent in BGP MAC/IP route advertisement, it is
service. possible to define per site (i.e. B-MAC) forwarding policies
including policies for E-TREE service.
10.6. Avoiding C-MAC Address Flushing 10.6. No C-MAC Address Flushing for All-Active Multi-Homing
With PBB-EVPN, it is possible to avoid C-MAC address flushing upon Just as in [EVPN], with PBB-EVPN, it is possible to avoid C-MAC
topology change affecting a multi-homed device. To illustrate this, address flushing upon topology change affecting an All-Active multi-
consider the example network of Figure 1. Both PE1 and PE2 advertize homed segment. To illustrate this, consider the example network of
the same B-MAC address (BM1) to PE3. PE3 then learns the C-MAC Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1) to
addresses of the servers/hosts behind CE1 via data-plane learning. If PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind
AC1 fails, then PE3 does not need to flush any of the C-MAC addresses CE1 via data-plane learning. If AC1 fails, then PE3 does not need to
learnt and associated with BM1. This is because PE1 will withdraw the flush any of the C-MAC addresses learnt and associated with BM1. This
MAC Advertisement routes associated with BM1, thereby leading PE3 to is because PE1 will withdraw the MAC Advertisement routes associated
have a single adjacency (to PE2) for this B-MAC address. Therefore, with BM1, thereby leading PE3 to have a single adjacency (to PE2) for
the topology change is communicated to PE3 and no C-MAC address this B-MAC address. Therefore, the topology change is communicated to
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 Jose Liste and Patrice Brissette for
their reviews and comments of this document. 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 All the security considerations in [EVPN] apply directly to this
that need to be discussed here. document because this document leverages [EVPN] control plane and
their associated procedures - although not the complete set but
rather a subset.
13. IANA Considerations 13. IANA Considerations
This document requires IANA to assign a new SAFI value for L2VPN_MAC There is no additional IANA considerations for PBB-EVPN beyond what
SAFI. is already described in [EVPN].
14. Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
15. Normative References 14. Normative References
[PBB] Clauses 25 and 26 of "IEEE Standard for Local and metropolitan [EVPN] Sajassi, et al., "BGP MPLS Based Ethernet VPN", draft-
area networks - Media Access Control (MAC) Bridges and ietf-l2vpn-evpn-11.txt, work in progress, October 2014.
Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2013.
16. Informative References 15. Informative References
[PBB-VPLS] Sajassi, et al., "VPLS Interoperability with Provider [RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS)
Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop- Interoperability with Provider Backbone Bridges", RFC
05.txt, work in progress, October, 2013. 7080, December 2013.
[EVPN-REQ] Sajassi, et al., "Requirements for Ethernet VPN (EVPN)", [RFC7209] A. Sajassi, et al., "Requirements for Ethernet VPN
draft-ietf-l2vpn-evpn-req-05.txt, work in progress, (EVPN)", RFC 7209, May 2014.
October, 2013.
[EVPN] Sajassi, et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [PBB] Clauses 25 and 26 of "IEEE Standard for Local and
l2vpn-evpn-04.txt, work in progress, July, 2013. metropolitan area networks - Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks", IEEE Std
802.1Q, 2013.
[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan
networks - Media Access Control (MAC) Bridges and Virtual area networks - Media Access Control (MAC) Bridges and
Bridged Local Area Networks", IEEE Std 802.1Q, 2013. Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2013.
17. Authors' Addresses 16. 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
skipping to change at page 21, line 32 skipping to change at page 22, line 4
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
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.be
Lizhong Jin Lizhong Jin
ZTE Corporation Shanghai,
889, Bibo Road China
Shanghai, 201203, China Email: lizho.jin@gmail.comLizhong Jin
Email: lizhong.jin@zte.com.cn
 End of changes. 83 change blocks. 
226 lines changed or deleted 238 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/