draft-ietf-l2vpn-pbb-evpn-09.txt   rfc7623.txt 
Internet Working Group Ali Sajassi, Ed. Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Internet Draft Samer Salam Request for Comments: 7623 S. Salam
Category: Standards Track Cisco Category: Standards Track Cisco
Nabil Bitar ISSN: 2070-1721 N. Bitar
Verizon Verizon
Aldrin Isaac A. Isaac
Bloomberg Juniper
Wim Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
Lizhong Jin September 2015
ZTE
Expires: April 24, 2015 October 24, 2014
PBB-EVPN Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
draft-ietf-l2vpn-pbb-evpn-09
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document discusses how Ethernet Provider Backbone Bridging (PBB)
provisions of BCP 78 and BCP 79. can be combined with Ethernet VPN (EVPN) in order to reduce the
number of BGP MAC Advertisement routes by aggregating Customer/Client
MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address,
provide client MAC address mobility using C-MAC aggregation, confine
the scope of C-MAC learning to only active flows, offer per-site
policies, and avoid C-MAC address flushing on topology changes. The
combined solution is referred to as PBB-EVPN.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7623.
Copyright and License Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
This document discusses how Ethernet Provider Backbone Bridging (PBB)
can be combined with Ethernet VPN (EVPN) in order to reduce the
number of BGP MAC advertisement routes by aggregating Customer/Client
MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC),
provide client MAC address mobility using C-MAC aggregation, confine
the scope of C-MAC learning to only active flows, offer per site
policies and avoid C-MAC address flushing on topology changes. The
combined solution is referred to as PBB-EVPN.
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements ....................................................4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. MAC Advertisement Route Scalability ........................5
4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5 3.2. C-MAC Mobility Independent of B-MAC Advertisements .........5
4.2. C-MAC Mobility Independent of B-MAC Advertisements . . . . 5 3.3. C-MAC Address Learning and Confinement .....................5
4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5 3.4. Per-Site Policy Support ....................................6
4.4. Per Site Policy Support . . . . . . . . . . . . . . . . . 6 3.5. No C-MAC Address Flushing for All-Active Multihoming .......6
4.5. No C-MAC Address Flushing for All-Active Multi-Homing . . 6 4. Solution Overview ...............................................6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. BGP Encoding ....................................................7
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Ethernet Auto-Discovery Route ..............................7
6.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7 5.2. MAC/IP Advertisement Route .................................7
6.2. MAC/IP Advertisement Route . . . . . . . . . . . . . . . . 8 5.3. Inclusive Multicast Ethernet Tag Route .....................8
6.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 8 5.4. Ethernet Segment Route .....................................8
6.4. Ethernet Segment Route . . . . . . . . . . . . . . . . . . 9 5.5. ESI Label Extended Community ...............................8
6.5. ESI Label Extended Community . . . . . . . . . . . . . . . 9 5.6. ES-Import Route Target .....................................9
6.6. ES-Import Route Target . . . . . . . . . . . . . . . . . . 9 5.7. MAC Mobility Extended Community ............................9
6.7. MAC Mobility Extended Community . . . . . . . . . . . . . 9 5.8. Default Gateway Extended Community .........................9
6.8. Default Gateway Extended Community . . . . . . . . . . . . 9 6. Operation .......................................................9
7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. MAC Address Distribution over Core .........................9
7.1. MAC Address Distribution over Core . . . . . . . . . . . . 9 6.2. Device Multihoming .........................................9
7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 10 6.2.1. Flow-Based Load-Balancing ...........................9
7.2.1. Flow-based Load-balancing . . . . . . . . . . . . . . . 10 6.2.1.1. PE B-MAC Address Assignment ...............10
7.2.1.1. PE B-MAC Address Assignment . . . . . . . . . . . 10 6.2.1.2. Automating B-MAC Address Assignment .......11
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 12 6.2.1.3. Split Horizon and Designated
7.2.1.3 Split Horizon and Designated Forwarder Election . . 12 Forwarder Election ........................12
7.2.2. I-SID Based Load-balancing . . . . . . . . . . . . . . 13 6.2.2. Load-Balancing based on I-SID ......................12
7.2.2.1. PE B-MAC Address Assignment . . . . . . . . . . . . 13 6.2.2.1. PE B-MAC Address Assignment ...............12
7.2.2.2. Split Horizon and Designated Forwarder Election . . 13 6.2.2.2. Split Horizon and Designated
7.2.2.3. Handling Failure Scenarios . . . . . . . . . . . . 13 Forwarder Election ........................13
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 14 6.2.2.3. Handling Failure Scenarios ................13
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 15
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Network Multihoming .......................................14
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 15 6.4. Frame Forwarding ..........................................14
7.5. MPLS Encapsulation of PBB Frames . . . . . . . . . . . . . 16 6.4.1. Unicast ............................................15
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 16 6.4.2. Multicast/Broadcast ................................15
9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 16 6.5. MPLS Encapsulation of PBB Frames ..........................16
9.1. B-MAC Address Assignment . . . . . . . . . . . . . . . . . 17 7. Minimizing ARP/ND Broadcast ....................................16
9.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement . . . 17 8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp .............17
9.4. Operation: . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. B-MAC Address Assignment ..................................17
10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 18 8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement .......17
10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 18 8.3. Operation: ................................................17
10.2. C-MAC Mobility Independent of B-MAC Advertisements . . . 18 9. Solution Advantages ............................................18
10.3. C-MAC Address Learning and Confinement . . . . . . . . . 19 9.1. MAC Advertisement Route Scalability .......................18
10.4. Seamless Interworking with 802.1aq Access Networks . . . 19 9.2. C-MAC Mobility Independent of B-MAC Advertisements ........18
10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 20 9.3. C-MAC Address Learning and Confinement ....................19
10.6. No C-MAC Address Flushing for All-Active Multi-Homing . . 20 9.4. Seamless Interworking with 802.1aq Access Networks ........19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9.5. Per-Site Policy Support ...................................20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.6. No C-MAC Address Flushing for All-Active Multihoming ......20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations .......................................20
14. Normative References . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations ...........................................20
15. Informative References . . . . . . . . . . . . . . . . . . . 21 12. References ....................................................21
16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References .....................................21
12.2. Informative References ...................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................23
1. Introduction 1. Introduction
[EVPN] introduces a solution for multipoint L2VPN services, with [RFC7432] introduces a solution for multipoint Layer 2 Virtual
advanced multi-homing capabilities, using BGP for distributing Private Network (L2VPN) services, with advanced multihoming
customer/client MAC address reach-ability information over the core capabilities, using BGP for distributing customer/client MAC address
MPLS/IP network. [PBB] defines an architecture for Ethernet Provider reachability information over the core MPLS/IP network. [PBB]
Backbone Bridging (PBB), where MAC tunneling is employed to improve defines an architecture for Ethernet Provider Backbone Bridging
service instance and MAC address scalability in Ethernet as well as (PBB), where MAC tunneling is employed to improve service instance
VPLS networks [RFC7080]. and MAC address scalability in Ethernet as well as 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 (B-MAC) address, provide client MAC address mobility
using C-MAC aggregation, confine the scope of C-MAC learning to only using C-MAC aggregation, confine the scope of C-MAC learning to only
active flows, offer per site policies and avoid C-MAC address active flows, offer per-site policies, and avoid C-MAC address
flushing on topology changes. The combined solution is referred to as flushing on topology changes. The combined solution is referred to
PBB-EVPN. as PBB-EVPN.
2. Contributors
In addition to the authors listed above, the following individuals
also contributed to this document.
Sami Boutros, Cisco
Dennis Cai, Cisco
Keyur Patel, Cisco
Clarence Filsfils, Cisco
Sam Aldrin, Huawei
Himanshu Shah, Ciena
Florin Balus, ALU
3. Terminology 2. Terminology
ARP: Address Resolution Protocol
BEB: Backbone Edge Bridge BEB: Backbone Edge Bridge
B-MAC: Backbone MAC Address B-MAC: Backbone MAC
B-VID: Backbone VLAN ID
CE: Customer Edge CE: Customer Edge
C-MAC: Customer/Client MAC Address C-MAC: Customer/Client MAC
ES: Ethernet Segment ES: Ethernet Segment
ESI: Ethernet Segment Identifier ESI: Ethernet Segment Identifier
EVI: EVPN Instance
EVPN: Ethernet VPN
I-SID: Service Instance Identifier (24 bits and global within a PBB
network see [RFC7080])
LSP: Label Switched Path LSP: Label Switched Path
MP2MP: Multipoint to Multipoint MP2MP: Multipoint to Multipoint
MP2P: Multipoint to Point MP2P: Multipoint to Point
NA: Neighbor Advertisement
ND: Neighbor Discovery
P2MP: Point to Multipoint P2MP: Point to Multipoint
P2P: Point to Point P2P: Point to Point
PBB: Provider Backbone Bridge
PE: Provider Edge PE: Provider Edge
EVPN: Ethernet VPN
EVI: EVPN Instance
RT: Route Target RT: Route Target
VPLS: Virtual Private LAN Service
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
3. 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 [RFC7209], in addition to the following: that were described in [RFC7209], in addition to the following:
4.1. MAC Advertisement Route Scalability 3.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
Route per customer/client MAC (C-MAC) address. In certain per C-MAC address. In certain applications, this poses scalability
applications, this poses scalability challenges, as is the case in challenges, as is the case in data center interconnect (DCI)
data center interconnect (DCI) scenarios where the number of virtual scenarios where the number of virtual machines (VMs), and hence the
machines (VMs), and hence the number of C-MAC addresses, can be in number of C-MAC addresses, can be in the millions. In such
the millions. In such scenarios, it is required to reduce the number scenarios, it is required to reduce the number of BGP MAC
of BGP MAC Advertisement routes by relying on a 'MAC summarization' Advertisement routes by relying on a 'MAC summarization' scheme, as
scheme, as is provided by PBB. is provided by PBB.
4.2. C-MAC Mobility Independent of B-MAC Advertisements 3.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, when support for fast C-MAC address mobility. For these applications,
using EVPN, the virtual machine MAC address needs to be transmitted when using EVPN, the virtual machine MAC address needs to be
in BGP MAC Advertisement route. Otherwise, traffic would be forwarded transmitted in BGP MAC Advertisement route. Otherwise, traffic would
to the wrong segment when a virtual machine moves from one Ethernet be forwarded to the wrong segment when a virtual machine moves from
segment to another. This means MAC address prefixes cannot be used in one ES to another. This means MAC address prefixes cannot be used in
data 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.
defines a Backbone MAC (B-MAC) address space that is independent of It defines a B-MAC address space that is independent of the C-MAC
the C-MAC address space, and aggregates C-MAC addresses via a single address space, and aggregates C-MAC addresses via a single B-MAC
B-MAC address. address.
4.3. C-MAC Address Learning and Confinement 3.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 learned 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 advertised 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
some of the PE nodes for that EVPN instance are not involved in if 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
addresses that are not part of active traffic flows on that PE, the addresses that are not part of active traffic flows on that PE, the
device memory is still consumed by keeping record of the C-MAC device memory is still consumed by keeping record of the C-MAC
addresses in the routing table (RIB). In network applications with addresses in the routing information base (RIB) table. In network
millions of C-MAC addresses, this introduces a non-trivial waste of applications with millions of C-MAC addresses, this introduces a non-
PE resources. As such, it is required to confine the scope of trivial waste of PE resources. As such, it is required to confine
visibility of C-MAC addresses only to those PE nodes that are the scope of visibility of C-MAC addresses to only those PE nodes
actively involved in forwarding traffic to, or from, these addresses. that are actively involved in forwarding traffic to, or from, these
addresses.
4.4. Per Site Policy Support 3.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. Both EVPN and PBB-EVPN can forward traffic to, or from, a given site. Both EVPN and PBB-
are capable of providing this granularity of policy control. In the EVPN are capable of providing this granularity of policy control. In
case where the policy needs to be at the granularity of per C-MAC the case where the policy needs to be at the granularity of per C-MAC
address, then C-MAC address learning in control-plane (in BGP) per address, then the C-MAC address should be learned in the control
[EVPN] should be used. plane (in BGP) per [RFC7432].
4.5. No C-MAC Address Flushing for All-Active Multi-Homing 3.5. No C-MAC Address Flushing for All-Active Multihoming
Just as in [EVPN], it is required to avoid C-MAC address flushing Just as in [RFC7432], it is required to avoid C-MAC address flushing
upon link, port or node failure for All-Active multi-homed segments. upon link, port, or node failure for All-Active multihomed segments.
5. Solution Overview 4. 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
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\ +----+ | |
\| | | | \| | | |
| PE2| | | | PE2| | |
+----+ | | +----+ | |
/\ +--------------+ /\ +--------------+
|| ||
BEB BEB
<-802.1Q-> <------PBB over MPLS------> <-802.1Q-> <-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 1: PBB-EVPN Network Figure 1: PBB-EVPN Network
The PE nodes perform the following functions:- Learn customer/client The PE nodes perform the following functions:
MAC addresses (C-MACs) over the attachment circuits in the data-
plane, per normal bridge operation.
- Learn remote C-MAC to B-MAC bindings in the data-plane for traffic - Learn customer/client MAC addresses (C-MACs) over the attachment
received from the core per [PBB] bridging operation. circuits in the data plane, per normal bridge operation.
- Advertise local B-MAC address reach-ability information in BGP to - Learn remote C-MAC to B-MAC bindings in the data plane for traffic
all other PE nodes in the same set of service instances. Note that received from the core per the bridging operation described in
every PE has a set of B-MAC addresses that uniquely identify the [PBB].
device. B-MAC address assignment is described in details in section
7.2.2.
- Build a forwarding table from remote BGP advertisements received - Advertise local B-MAC address reachability information in BGP to
associating remote B-MAC addresses with remote PE IP addresses and all other PE nodes in the same set of service instances. Note
the associated MPLS label(s). that every PE has a set of B-MAC addresses that uniquely
identifies the device. B-MAC address assignment is described in
details in Section 6.2.2.
6. BGP Encoding - Build a forwarding table from remote BGP advertisements received
associating remote B-MAC addresses with remote PE IP addresses and
the associated MPLS label(s).
PBB-EVPN leverages the same BGP Routes and Attributes defined in 5. BGP Encoding
[EVPN], adapted as follows:
6.1. Ethernet Auto-Discovery Route PBB-EVPN leverages the same BGP routes and attributes defined in
[RFC7432], adapted as described below.
5.1. Ethernet Auto-Discovery Route
This route and all of its associated modes are not needed in PBB-EVPN This route and all of its associated modes are not needed in PBB-EVPN
because PBB encapsulation provides the required level of indirection because PBB encapsulation provides the required level of indirection
for C-MAC addresses - i.e., an ES can be represented by a B-MAC for C-MAC addresses -- i.e., an ES can be represented by a B-MAC
address for the purpose of data-plane learning/forwarding. 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 Ethernet A-D (auto-discovery) route for route resolution by means of
Ethernet Segment Identifier (ESI) encoded in the MAC Advertisement the reserved ESI encoded in the MAC Advertisement route: the ESI
route: the ESI values of 0 and MAX-ESI indicate that the receiving PE values of 0 and MAX-ESI indicate that the receiving PE can resolve
can resolve the path without an Ethernet A-D route. the path without an Ethernet A-D route.
6.2. MAC/IP Advertisement Route 5.2. MAC/IP Advertisement Route
The EVPN MAC/IP 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 learned in
data-plane for traffic arriving from the core. The MAC Advertisement the data plane for traffic arriving from the core. The MAC
Route is encoded as follows: Advertisement 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 Segment Identifier field must be set either to 0 (for
single-homed segments or multi-homed segments with per-ISID load-
balancing) or to MAX-ESI (for multi-homed segments with per-flow
load-balancing). All other values are not permitted.
- All other fields are set as defined in [EVPN].
This route is tagged with the Route Target (RT) corresponding to its - The Ethernet Tag field is set to 0.
EVI. This EVI is analogous to a B-VID.
6.3. Inclusive Multicast Ethernet Tag Route - The Ethernet Segment Identifier field must be set to either 0 (for
single-homed segments or multihomed segments with per-I-SID load-
balancing) or to MAX-ESI (for multihomed segments with per-flow
load-balancing). All other values are not permitted.
This route is used for multicast pruning per I-SID. It is used for - All other fields are set as defined in [RFC7432].
This route is tagged with the RT corresponding to its EVI. This EVI
is analogous to a B-VID.
5.3. Inclusive Multicast Ethernet Tag Route
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 set up for
that I-SID . [RFC7080] 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 a large number of PEs and b) it works with any type of LSP
(MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P (MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P
pseudowires. The Inclusive Multicast Ethernet Tag Route is encoded as pseudowires. The Inclusive Multicast Ethernet Tag route is encoded
follow: as follows:
- 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].
This route is tagged with an RT. This RT SHOULD be set to a value - All other fields are set as defined in [RFC7432].
corresponding to its EVI (which is analogous to a B-VID). The RT for
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 this route MAY also be auto-derived from the corresponding Ethernet
Tag (I-SID) based on the procedure specified in section 8.4.1.1.1 of Tag (I-SID) based on the procedure specified in Section 5.1.2.1 of
[EVPN]. [OVERLAY].
6.4. Ethernet Segment Route 5.4. Ethernet Segment Route
This route is auto-discovery of member PEs belonging to a given This route is used for auto-discovery of PEs belonging to a given
redundancy group (e.g., attached to a given Ethernet Segment) per redundancy group (e.g., attached to a given ES) per [RFC7432].
[EVPN].
6.5. ESI Label Extended Community 5.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 [RFC7432], this
extended community is used along with the Ethernet AD route to extended community is used along with the Ethernet A-D 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 source address, there is no need for this extended
community.
6.6. ES-Import Route Target 5.6. ES-Import Route Target
This RT is used as defined in [EVPN]. This RT is used as defined in [RFC7432].
6.7. MAC Mobility Extended Community 5.7. MAC Mobility Extended Community
This extended community is defined in [EVPN] and it is used with a This extended community is defined in [RFC7432] and it is used with a
MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is
tagged with the RT corresponding to its EVI (which is analogous to a tagged with the RT corresponding to its EVI (which is analogous to a
B-VID). When this extended community is used along with a B-MAC route B-VID). When this extended community is used along with a B-MAC
in PBB-EVPN, it indicates that all C-MAC addresses associated with route in PBB-EVPN, it indicates that all C-MAC addresses associated
that B-MAC address across all corresponding I-SIDs must be flushed. with that B-MAC address across all corresponding I-SIDs must be
flushed.
6.8. Default Gateway Extended Community When a PE first advertises a B-MAC, it MAY advertise it with this
extended community where the sticky/static flag is set to 1 and the
sequence number is set to zero. In such cases where the PE wants to
signal the stickiness of a B-MAC, then when a flush indication is
needed, the PE advertises the B-MAC along with the MAC Mobility
extended community where the sticky/static flag remains set and the
sequence number is incremented.
5.8. Default Gateway Extended Community
This extended community is not used in PBB-EVPN. This extended community is not used in PBB-EVPN.
7. Operation 6. 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 [RFC7432].
7.1. MAC Address Distribution over Core 6.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 6.2. Device Multihoming
7.2.1. Flow-based Load-balancing 6.2.1. Flow-Based Load-Balancing
This section describes the procedures for supporting device multi- This section describes the procedures for supporting device
homing in an All-Active redundancy mode (i.e., flow-based load- multihoming in an All-Active redundancy mode (i.e., flow-based load-
balancing). balancing).
7.2.1.1. PE B-MAC Address Assignment 6.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 multihoming. In particular, for the scenario
where a CE is multi-homed to a number of PE nodes with All-Active where a CE is multihomed 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
nodes connected to the same CE must share the same B-MAC address. nodes connected to the same CE must share the same B-MAC address.
Otherwise, the MAC address table of the remote PE nodes will keep Otherwise, the MAC address table of the remote PE nodes will keep
oscillating between the B-MAC addresses of the various PE devices. oscillating between the B-MAC addresses of the various PE devices.
For example, consider the network of Figure 1, and assume that PE1 For example, consider the network of Figure 1, and assume that PE1
has B-MAC BM1 and PE2 has B-MAC BM2. Also, assume that both links has B-MAC address BM1 and PE2 has B-MAC address BM2. Also, assume
from CE1 to the PE nodes are part of the same Ethernet link that both links from CE1 to the PE nodes are part of the same
aggregation group. If BM1 is not equal to BM2, the consequence is Ethernet link aggregation group. If BM1 is not equal to BM2, the
that the MAC address table on PE3 will keep oscillating such that the consequence is that the MAC address table on PE3 will keep
C-MAC address M1 of CE1 would flip-flop between BM1 or BM2, depending oscillating such that the C-MAC address M1 of CE1 would flip-flop
on the load-balancing decision on CE1 for traffic destined to the between BM1 or BM2, depending on the load-balancing decision on CE1
core. for traffic destined to the core.
Considering that there could be multiple sites (e.g. CEs) that are Considering that there could be multiple sites (e.g., CEs) that are
multi-homed to the same set of PE nodes, then it is required for all multihomed to the same set of PE nodes, then it is required for all
the PE devices in a Redundancy Group to have a unique B-MAC address the PE devices in a redundancy group to have a unique B-MAC address
per site. This way, it is possible to achieve fast convergence in the per site. This way, it is possible to achieve fast convergence in
case where a link or port failure impacts the attachment circuit the case where a link or port failure impacts the attachment circuit
connecting a single site to a given PE. connecting a single site to a given PE.
+---------+ +---------+
+-------+ PE1 | IP/MPLS | +-------+ PE1 | IP/MPLS |
/ | | / | |
CE1 | Network | PEr CE1 | Network | PEr
M1 \ | | M1 \ | |
+-------+ PE2 | | +-------+ PE2 | |
/-------+ | | /-------+ | |
/ | | / | |
CE2 | | CE2 | |
M2 \ | | M2 \ | |
\ | | \ | |
+------+ PE3 +---------+ +------+ PE3 +---------+
Figure 2: B-MAC Address Assignment Figure 2: B-MAC Address Assignment
In the example network shown in Figure 2 above, two sites In the example network shown in Figure 2 above, two sites
corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3, corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3,
respectively. Assume that BM1 is the B-MAC used for the site respectively. Assume that BM1 is the B-MAC used for the site
corresponding to CE1. Similarly, BM2 is the B-MAC used for the site corresponding to CE1. Similarly, BM2 is the B-MAC used for the site
corresponding to CE2. On PE1, a single B-MAC address (BM1) is corresponding to CE2. On PE1, a single B-MAC address (BM1) is
required for the site corresponding to CE1. On PE2, two B-MAC required for the site corresponding to CE1. On PE2, two B-MAC
addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a addresses (BM1 and BM2) are required, one per site. Whereas on PE3,
single B-MAC address (BM2) is required for the site corresponding to a single B-MAC address (BM2) is required for the site corresponding
CE2. All three PE nodes would advertise their respective B-MAC to CE2. All three PE nodes would advertise their respective B-MAC
addresses in BGP using the MAC Advertisement routes defined in addresses in BGP using the MAC Advertisement routes defined in
[EVPN]. The remote PE, PEr, would learn via BGP that BM1 is reachable [RFC7432]. The remote PE, PEr, would learn via BGP that BM1 is
via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3. reachable via PE1 and PE2, whereas BM2 is reachable via both PE2 and
Furthermore, PEr establishes, via the PBB bridge learning procedure, PE3. Furthermore, PEr establishes, via the PBB bridge learning
that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via procedure, that C-MAC M1 is reachable via BM1, and C-MAC M2 is
BM2. As a result, PEr can load-balance traffic destined to M1 between reachable via BM2. As a result, PEr can load-balance traffic
PE1 and PE2, as well as traffic destined to M2 between both PE2 and destined to M1 between PE1 and PE2, as well as traffic destined to M2
PE3. In the case of a failure that causes, for example, CE1 to be between both PE2 and PE3. In the case of a failure that causes, for
isolated from PE1, the latter can withdraw the route it has example, CE1 to be isolated from PE1, the latter can withdraw the
advertised for BM1. This way, PEr would update its path list for BM1, route it has advertised for BM1. This way, PEr would update its path
and will send all traffic destined to M1 over to PE2 only. list for BM1 and will send all traffic destined to M1 over to PE2
only.
For Single-Homed or Single-Active sites, it is possible to assign a
unique B-MAC address per site, or have all the Single-Homed sites or
Single-Active sites connected to a 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 address lookup on the
disposition PE (even though source C-MAC learning is still required
in the data-plane). The disadvantage of the first model over the
second model is additional B-MAC advertisements in BGP.
In summary, every PE may use a unicast B-MAC address shared by all
single-homed sites or a unicast B-MAC address per single-homed site
and, in addition, a unicast B-MAC address per All-Active multi-homed
site. In the latter case, the B-MAC address MUST be the same for all
PE nodes in a Redundancy Group connected to the same site.
7.2.1.2. Automating B-MAC Address Assignment 6.2.1.2. Automating B-MAC Address Assignment
The PE B-MAC address used for Single-Homed or Single-Active sites can The PE B-MAC address used for single-homed or Single-Active sites can
be automatically derived from the hardware (using for e.g. the be automatically derived from the hardware (using for example the
backplane's address and/or PE's reserved MAC pool ). However, the B- backplane's address and/or PE's reserved MAC pool ). However, the
MAC address used for All-Active sites must be coordinated among the B-MAC address used for All-Active sites must be coordinated among the
RG members. To automate the assignment of this latter address, the PE redundancy group members. To automate the assignment of this latter
can derive this B-MAC address from the MAC Address portion of the address, the PE can derive this B-MAC address from the MAC address
CE's Link Aggregation Control Protocol (LACP) System Identifier by portion of the CE's Link Aggregation Control Protocol (LACP) System
flipping the 'Locally Administered' bit of the CE's address. This Identifier by flipping the 'Locally Administered' bit of the CE's
guarantees the uniqueness of the B-MAC address within the network, address. This guarantees the uniqueness of the B-MAC address within
and ensures that all PE nodes connected to the same All-Active CE use the network, and ensures that all PE nodes connected to the same All-
the same value for the B-MAC address. Active CE use the same value for the B-MAC address.
Note that with this automatic provisioning of the B-MAC address Note that with this automatic provisioning of the B-MAC address
associated with All-Active CEs, it is not possible to support the associated with All-Active CEs, it is not possible to support the
uncommon scenario where a CE has multiple link bundles within the uncommon scenario where a CE has multiple link bundles within the
same LACP session towards the PE nodes, and the service involves same LACP session towards the PE nodes, and the service involves
hair-pinning traffic from one bundle to another. This is because the hair-pinning traffic from one bundle to another. This is because the
split-horizon filtering relies on B-MAC addresses rather than Site-ID split-horizon filtering relies on B-MAC addresses rather than Site-ID
Labels (as will be described in the next section). The operator must Labels (as will be described in the next section). The operator must
explicitly configure the B-MAC address for this fairly uncommon explicitly configure the B-MAC address for this fairly uncommon
service scenario. service scenario.
Whenever a B-MAC address is provisioned on the PE, either manually or Whenever a B-MAC address is provisioned on the PE, either manually or
automatically (as an outcome of CE auto-discovery), the PE MUST automatically (as an outcome of CE auto-discovery), the PE MUST
transmit an MAC Advertisement Route for the B-MAC address with a transmit a 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 6.2.1.3. Split Horizon and Designated Forwarder Election
[EVPN] relies on access split horizon, where the Ethernet Segment [RFC7432] relies on split-horizon filtering for a multi-homed ES,
Label is used for egress filtering on the attachment circuit in order where the ES label is used for egress filtering on the attachment
to prevent forwarding loops. In PBB-EVPN, the B-MAC source address circuit in order to prevent forwarding loops. In PBB-EVPN, the B-MAC
can be used for the same purpose, as it uniquely identifies the source address can be used for the same purpose, as it uniquely
originating site of a given frame. As such, Ethernet Segment (ES) identifies the originating site of a given frame. As such, ES labels
Labels are not used in PBB-EVPN, and the egress split-horizon are not used in PBB-EVPN, and the egress split-horizon filtering is
filtering is done based on the B-MAC source address. It is worth done based on the B-MAC source address. It is worth noting here that
noting here that [PBB] defines this B-MAC address based filtering [PBB] defines this B-MAC address-based filtering function as part of
function as part of the I-Component options, hence no new functions the I-Component options; hence, no new functions are required to
are required to support split-horizon beyond what is already defined support split-horizon filtering beyond what is already defined in
in [PBB]. [PBB].
The Designated Forwarder election procedures are defined in [EVPN]. The Designated Forwarder (DF) election procedures are defined in
[RFC7432].
7.2.2. I-SID Based Load-balancing 6.2.2. Load-Balancing based on I-SID
This section describes the procedures for supporting device multi- This section describes the procedures for supporting device
homing in a Single-Active redundancy mode with per-ISID load- multihoming in a Single-Active redundancy mode with per-I-SID load-
balancing. balancing.
7.2.2.1. PE B-MAC Address Assignment 6.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-I-SID 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 multihomed ES: Each PE connected to the multihomed
the multi-homed segment is assigned a unique B-MAC. Every PE then segment is assigned a unique B-MAC. Every PE then advertises its
advertises its B-MAC address using the BGP MAC advertisement route. B-MAC address using the BGP MAC Advertisement route. In this mode of
In this mode of operation, two B-MAC address assignment models are 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 all its single-homed
Segments (ES's). This includes the single-homed segments as well as segments and/or all its multi-homed Single-Active segments (e.g.,
the multi-homed segments operating with per-ISID load-balancing mode. segments operating in per-I-SID load-balancing mode).
- The PE may use a dedicated B-MAC address for each ES operating with - The PE may use a dedicated B-MAC address for each ES operating
per-ISID load-balancing mode. with per-I-SID load-balancing mode.
A PE implementation MAY choose to support either the shared B-MAC A PE implementation MAY choose to support either the shared B-MAC
address model or the dedicated B-MAC address model without causing address model or the dedicated B-MAC address model without causing
any interoperability issues. any interoperability issues. The advantage of the dedicated B-MAC
over the shared B-MAC address for multi-homed Single-Active segments,
is that when C-MAC flushing is needed, fewer C-MAC addresses are
impacted. Furthermore, it gives the disposition PE the ability to
avoid C-MAC destination address lookup even though source C-MAC
learning is still required in the data plane. Its disadvantage is
that there are additional B-MAC advertisements in BGP.
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 multihomed ES, to all the PE nodes configured with
configured with that I-SID. Then, when reply traffic arrives at the that I-SID. Then, when reply traffic arrives at the remote PE, it
remote PE, it learns (in the data-path) the B-MAC address and learns (in the data path) the B-MAC address and associated next-hop
associated next-hop PE to use for said C-MAC address. PE to use for said C-MAC address.
7.2.2.2. Split Horizon and Designated Forwarder Election The procedures 6.2.2.2. Split Horizon and Designated Forwarder Election
are similar to the flow-based load-balancing case, with the only
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
segment-to-core directions.
7.2.2.3. Handling Failure Scenarios The procedures are similar to the flow-based load-balancing case,
with the only 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 segment-to-core directions.
When a PE connected to a multi-homed Ethernet Segment loses 6.2.2.3. Handling Failure Scenarios
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
achieved in one of two ways, depending on the B-MAC assignment model:
- If the PE uses a shared B-MAC address for multiple ES's, then the When a PE connected to a multihomed ES loses connectivity to the
C-MAC flushing is signaled by means of having the failed PE re- segment, due to link or port failure, it needs to notify the remote
advertise the MAC Advertisement route for the associated B-MAC, PEs to trigger C-MAC address flushing. This can be achieved in one
tagged with the MAC Mobility Extended Community attribute. The value of two ways, depending on the B-MAC assignment model:
of the Counter field in that attribute must be incremented prior to
advertisement. 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 that are mapped to the EVI of the withdrawn MAC route.
- If the PE uses a dedicated B-MAC address for each Ethernet Segment - If the PE uses a shared B-MAC address for multiple Ethernet
operating under per-ISID load-balancing mode, the the failed PE segments, then the C-MAC flushing is signaled by means of having
simply withdraws the B-MAC route previously advertised for that the failed PE re-advertise the MAC Advertisement route for the
segment. This causes the remote PE nodes to flush all C-MAC addresses associated B-MAC, tagged with the MAC Mobility extended community
associated with the B-MAC in question. This is done across all I-SIDs attribute. The value of the Counter field in that attribute must
that are mapped to the EVI of the withdrawn MAC route. be incremented prior to advertisement. 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 that are mapped to the
EVI of the withdrawn MAC route.
When a PE connected to a multi-homed Ethernet Segment fails (i.e. - If the PE uses a dedicated B-MAC address for each ES operating
node failure) or when the PE becomes completely isolated from the under per-I-SID load-balancing mode, the failed PE simply
EVPN network, the remote PEs will start purging the MAC Advertisement withdraws the B-MAC route previously advertised for that segment.
routes that were advertised by the failed PE. This is done either as This causes the remote PE nodes to flush all C-MAC addresses
an outcome of the remote PEs detecting that the BGP session to the associated with the B-MAC in question. This is done across all
failed PE has gone down, or by having a Route Reflector withdrawing I-SIDs that are mapped to the EVI of the withdrawn MAC route.
all the routes that were advertised by the failed PE. The remote PEs,
in this case, will perform C-MAC address flushing as an outcome of
the MAC Advertisement route withdrawals.
For all failure scenarios (link/port failure, node failure and PE When a PE connected to a multihomed ES fails (i.e., node failure) or
when the PE becomes completely isolated from the EVPN network, the
remote PEs will start purging the MAC Advertisement routes that were
advertised by the failed PE. This is done either as an outcome of
the remote PEs detecting that the BGP session to the failed PE has
gone down, or by having a Route Reflector withdrawing all the routes
that were advertised by the failed PE. The remote PEs, in this case,
will perform C-MAC address flushing as an outcome of the MAC
Advertisement route withdrawals.
For all failure scenarios (link/port failure, node failure, and PE
node isolation), when the fault condition clears, the recovered PE node isolation), when the fault condition clears, the recovered PE
re-advertises the associated Ethernet Segment route to other members re-advertises the associated ES route to other members of its
of its Redundancy Group. This triggers the backup PE(s) in the redundancy group. This triggers the backup PE(s) in the redundancy
Redundancy Group to block the I-SIDs for which the recovered PE is a group to block the I-SIDs for which the recovered PE is a DF. When a
DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address backup PE blocks the I-SIDs, it triggers a C-MAC address flush
flush notification to the remote PEs by re-advertising the MAC 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
remote PE nodes to flush all C-MAC addresses associated with the B- the remote PE nodes to flush all C-MAC addresses associated with the
MAC in question. This is done across all I-SIDs that are mapped to B-MAC in question. This is done across all I-SIDs that are mapped to
the EVI of the withdrawn/readvertised MAC route. the EVI of the withdrawn/re-advertised MAC route.
7.3. Network Multi-homing 6.3. Network Multihoming
When an Ethernet network is multi-homed to a set of PE nodes running When an Ethernet network is multihomed to a set of PE nodes running
PBB-EVPN, Single-Active redundancy model can be supported with per PBB-EVPN, Single-Active redundancy model can be supported with per-
service instance (i.e. I-SID) load-balancing. In this model, DF service instance (i.e., I-SID) load-balancing. In this model, DF
election is performed to ensure that a single PE node in the election is performed to ensure that a single PE node in the
redundancy group is responsible for forwarding traffic associated redundancy group is responsible for forwarding traffic associated
with a given I-SID. This guarantees that no forwarding loops are with a given I-SID. This guarantees that no forwarding loops are
created. Filtering based on DF state applies to both unicast and created. Filtering based on DF state applies to both unicast and
multicast traffic, and in both access-to-core as well as core-to- multicast traffic, and in both access-to-core as well as core-to-
access directions just like Single-Active multi-homed device scenario access directions just like a Single-Active multihomed device
(but unlike All-Active multi-homed device scenario where DF filtering scenario (but unlike an All-Active multihomed device scenario where
is limited to multi-destination frames in the core-to-access DF filtering is limited to multi-destination frames in the core-to-
direction). Similar to Single-Active multi-homed device scenario, access direction). Similar to a Single-Active multihomed device
with I-SID based load-balancing, a unique B-MAC address is assigned scenario, with load-balancing based on I-SID, a unique B-MAC address
to each of the PE nodes connected to the multi-homed network is assigned to each of the PE nodes connected to the multihomed
(Segment). network (segment).
7.4. Frame Forwarding 6.4. Frame Forwarding
The frame forwarding functions are divided in between the Bridge The frame-forwarding functions are divided in between the Bridge
Module, which hosts the [PBB] Backbone Edge Bridge (BEB) Module, which hosts the [PBB] BEB functionality, and the MPLS
functionality, and the MPLS Forwarder which handles the MPLS Forwarder which handles the MPLS imposition/disposition. The details
imposition/disposition. The details of frame forwarding for unicast of frame forwarding for unicast and multi-destination frames are
and multi-destination frames are discussed next. discussed next.
7.4.1. Unicast 6.4.1. Unicast
Known unicast traffic received from the AC will be PBB-encapsulated Known unicast traffic received from the Attachment Circuit (AC) will
by the PE using the B-MAC source address corresponding to the be PBB-encapsulated by the PE using the B-MAC source address
originating site. The unicast B-MAC destination address is determined corresponding to the originating site. The unicast B-MAC destination
based on a lookup of the C-MAC destination address (the binding of address is determined based on a lookup of the C-MAC destination
the two is done via transparent learning of reverse traffic). The address (the binding of the two is done via transparent learning of
resulting frame is then encapsulated with an LSP tunnel label and the reverse traffic). The resulting frame is then encapsulated with an
MPLS label which uniquely identifies the B-MAC destination address on LSP tunnel label and an EVPN label associated with the B-MAC
the egress PE. If per flow load-balancing over ECMPs in the MPLS core destination address. If per flow load-balancing over ECMPs in the
is required, then a flow label is added below the label associated MPLS core is required, then a flow label is added below the label
with the BMAC address in the label stack. associated with the B-MAC 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 the
core. When these frames are to be forwarded, then the same set of MPLS core. When these frames are to be forwarded, then the same set
options used for forwarding multicast/broadcast frames (as described of options used for forwarding multicast/broadcast frames (as
in next section) are used. described in next section) are used.
7.4.2. Multicast/Broadcast 6.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 of the
the following two options: 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 or P2P tunnel LSPs. The frame is encapsulated with a set of MP2P or P2P tunnel LSPs. The frame is encapsulated with a
tunnel LSP label and the EVPN ingress replication label advertised in tunnel LSP label and the EVPN ingress replication label advertised
the Inclusive Multicast Route. in the Inclusive Multicast Ethernet Tag [RFC7432].
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 [RFC7432]. This includes either the use of
Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS
Forwarder can use MP2MP tunnel LSP if Inclusive trees are used. 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 Ethernet Tag defined in [RFC7432] apply here.
7.5. MPLS Encapsulation of PBB Frames 6.5. MPLS Encapsulation of PBB Frames
The encapsulation for the transport of PBB frames over MPLS is The encapsulation for the transport of PBB frames over MPLS is
similar to that of classical Ethernet, albeit with the additional PBB similar to that of classical Ethernet, albeit with the additional PBB
header, as shown in the figure below: header, as shown in the figure below:
+------------------+ +------------------+
| IP/MPLS Header | | IP/MPLS Header |
+------------------+ +------------------+
| PBB Header | | PBB Header |
+------------------+ +------------------+
| Ethernet Header | | Ethernet Header |
+------------------+ +------------------+
| Ethernet Payload | | Ethernet Payload |
+------------------+ +------------------+
| Ethernet FCS | | Ethernet FCS |
+------------------+ +------------------+
Figure 8: PBB over MPLS Encapsulation Figure 3: PBB over MPLS Encapsulation
8. Minimizing ARP Broadcast 7. Minimizing ARP/ND Broadcast
The PE nodes implement an ARP-proxy function in order to minimize the The PE nodes MAY implement an ARP/ND-proxy function in order to
volume of ARP traffic that is broadcasted over the MPLS network. This minimize the volume of ARP/ND traffic that is broadcasted over the
is achieved by having each PE node snoop on ARP request and response MPLS network. In case of ARP proxy, this is achieved by having each
messages received over the access interfaces or the MPLS core. The PE PE node snoop on ARP request and response messages received over the
builds a cache of IP / MAC address bindings from these snooped access interfaces or the MPLS core. The PE builds a cache of IP/MAC
messages. The PE then uses this cache to respond to ARP requests address bindings from these snooped messages. The PE then uses this
ingress on access ports and targeting hosts that are in remote sites. cache to respond to ARP requests ingress on access ports and target
If the PE finds a match for the IP address in its ARP cache, it hosts that are in remote sites. If the PE finds a match for the IP
responds back to the requesting host and drops the request. address in its ARP cache, it responds back to the requesting host and
Otherwise, if it does not find a match, then the request is flooded drops the request. Otherwise, if it does not find a match, then the
over the MPLS network using either ingress replication or P2MP LSPs. request is flooded over the MPLS network using either ingress
replication or P2MP LSPs. In case of ND proxy, this is achieved
similar to the above but with ND/NA messages per [RFC4389].
8. 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 4: Interconnecting 802.1aq / 802.1Qbp Networks with PBB-EVPN
9.1. B-MAC Address Assignment 8.1. B-MAC Address Assignment
The B-MAC addresses need to be globally unique across all networks The B-MAC addresses need to be globally unique across all networks
including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC
addresses used for Single-Home and Single-Active Ethernet Segments addresses used for single-homed and Single-Active Ethernet segments
should be unique because they are typically auto-derived from PE's should be unique because they are typically auto-derived from the
pools of reserved MAC addresses that are unique. The B-MAC addresses PE's pools of reserved MAC addresses that are unique. The B-MAC
used for All-Active Ethernet Segments should also be unique given addresses used for All-Active Ethernet segments should also be unique
that each network operator typically has its own assigned given that each network operator typically has its own assigned
Organizationally Unique Identifier (OUI) and thus can assign its own Organizationally Unique Identifier (OUI) and thus can assign its own
unique MAC addresses. unique MAC addresses.
9.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement 8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement
B-MAC addresses associated with 802.1aq / 802.1Qbp switches are B-MAC addresses associated with 802.1aq / 802.1Qbp switches are
advertised using the EVPN MAC/IP route advertisement already defined advertised using the EVPN MAC/IP route advertisement already defined
in [EVPN]. in [RFC7432].
9.4. Operation: 8.3. 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,
the PE receives the MPLS-encapsulated PBB frame with a single label: the PE receives the MPLS-encapsulated PBB frame with a single label:
the VPN label. The value of the label indicates to the disposition PE the VPN label. The value of the label indicates to the disposition
that this is a PBB frame, so the label is popped, the TTL field (in PE that this is a PBB frame, so the label is popped, the TTL field
the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is (in the 802.1Qbp F-Tag) is reinitialized, and normal PBB processing
employed from this point onwards. is employed from this point onwards.
10. Solution Advantages 9. 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.
10.1. MAC Advertisement Route Scalability 9.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 Ethernet Segments (e.g., sites), rather than the number the number of Ethernet segments (e.g., sites) rather than the number
of hosts/servers. This is because the B-MAC addresses of the PEs, of hosts/servers. This is because the B-MAC addresses of the PEs,
rather than C-MAC addresses (of hosts/servers) are being advertised rather than C-MAC addresses (of hosts/servers), are being advertised
in BGP. As discussed above, there's a one-to-one mapping between All- in BGP. As discussed above, there's a one-to-one mapping between
Active multi-homed segments and their associated B-MAC addresses, and All-Active multihomed segments and their associated B-MAC addresses;
there can be either a one-to-one or many-to-one mapping between there can be either a one-to-one or many-to-one mapping between
Single-Active multi-homed segments and their associated B-MAC Single-Active multihomed segments and their associated B-MAC
addresses, and finally there is a many-to-one mapping between single- 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 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 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 each segment can be associated with many C-MAC addresses. As a
result, the volume of MAC Advertisement Routes in PBB-EVPN may be result, the volume of MAC Advertisement routes in PBB-EVPN may be
multiple orders of magnitude less than EVPN. multiple orders of magnitude less than EVPN.
10.2. C-MAC Mobility Independent of B-MAC Advertisements 9.2. C-MAC Mobility Independent of B-MAC Advertisements
As described above, in PBB-EVPN, a single B-MAC address can aggregate As described above, in PBB-EVPN, a single B-MAC address can aggregate
many C-MAC addresses. Given that B-MAC addresses are associated with many C-MAC addresses. Given that B-MAC addresses are associated with
segments attached to a PE or to the PE itself, their locations are segments attached to a PE or to the PE itself, their locations are
fixed and thus not impacted what so ever by C-MAC mobility. fixed and thus not impacted what so ever by C-MAC mobility.
Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any
re-advertisements of them). This is because the C-MAC address to B- re-advertisements of them). This is because the association of C-MAC
MAC address association is learnt in the data-plane and C-MAC address to B-MAC address is learned in the data-plane and C-MAC
addresses are not advertised in BGP. Aggregation via B-MAC addresses addresses are not advertised in BGP. Aggregation via B-MAC addresses
in PBB-EVPN performs much better than EVPN. in PBB-EVPN performs much better than EVPN.
To illustrate how this compares to EVPN, consider the following To illustrate how this compares to EVPN, consider the following
example: example:
If a PE running EVPN advertises reachability for N MAC addresses via If a PE running EVPN advertises reachability for N MAC addresses
a particular segment, and then 50% of the MAC addresses in that via a particular segment, and then 50% of the MAC addresses in
segment move to other segments (e.g. due to virtual machine that segment move to other segments (e.g., due to virtual machine
mobility), then N/2 additional MAC Advertisement routes need to be mobility), then N/2 additional MAC Advertisement routes need to be
sent for the MAC addresses that have moved. With PBB-EVPN, on the sent for the MAC addresses that have moved. With PBB-EVPN, on the
other hand, the B-MAC addresses which are statically associated with other hand, the B-MAC addresses that are statically associated
PE nodes, are not subject to mobility. As C-MAC addresses move from with PE nodes are not subject to mobility. As C-MAC addresses
one segment to another, the binding of C-MAC to B-MAC addresses is move from one segment to another, the binding of C-MAC to B-MAC
updated via data-plane learning in PBB-EVPN. addresses is updated via data-plane learning in PBB-EVPN.
10.3. C-MAC Address Learning and Confinement 9.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 the control-plane routing table.
10.4. Seamless Interworking with 802.1aq Access Networks 9.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 |
+----+ | 802.1aq |---| | | |--| MPLS | +----+ +----+ | 802.1aq |---| | | |--| MPLS | +----+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
| CE |--| | | Backbone | | |--| CE | | CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
Figure 9: Interoperability with 802.1aq Figure 5: Interoperability with 802.1aq
If the MPLS backbone network employs EVPN, then the 802.1aq data- If the MPLS backbone network employs EVPN, then the 802.1aq data-
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.
10.5. Per Site Policy Support 9.5. Per-Site Policy Support
In PBB-EVPN, the per site policy can be supported via B-MAC addresses In PBB-EVPN, the per-site policy can be supported via B-MAC addresses
via assigning a unique B-MAC address for every site/segment via assigning a unique B-MAC address for every site/segment
(typically multi-homed but can also be single-homed). Given that the (typically multihomed but can also be single-homed). Given that the
B-MAC addresses are sent in BGP MAC/IP route advertisement, it is B-MAC addresses are sent in BGP MAC/IP route advertisement, it is
possible to define per site (i.e. B-MAC) forwarding policies possible to define per-site (i.e., B-MAC) forwarding policies
including policies for E-TREE service. including policies for E-TREE service.
10.6. No C-MAC Address Flushing for All-Active Multi-Homing 9.6. No C-MAC Address Flushing for All-Active Multihoming
Just as in [EVPN], with PBB-EVPN, it is possible to avoid C-MAC Just as in [RFC7432], with PBB-EVPN, it is possible to avoid C-MAC
address flushing upon topology change affecting an All-Active multi- address flushing upon topology change affecting an All-Active
homed segment. To illustrate this, consider the example network of multihomed segment. To illustrate this, consider the example network
Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1) to of Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1)
PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind to PE3. PE3 then learns the C-MAC addresses of the servers/hosts
CE1 via data-plane learning. If AC1 fails, then PE3 does not need to behind CE1 via data-plane learning. If AC1 fails, then PE3 does not
flush any of the C-MAC addresses learnt and associated with BM1. This need to flush any of the C-MAC addresses learned and associated with
is because PE1 will withdraw the MAC Advertisement routes associated BM1. This is because PE1 will withdraw the MAC Advertisement routes
with BM1, thereby leading PE3 to have a single adjacency (to PE2) for associated with BM1, thereby leading PE3 to have a single adjacency
this B-MAC address. Therefore, the topology change is communicated to (to PE2) for this B-MAC address. Therefore, the topology change is
PE3 and no C-MAC address flushing is required. communicated to PE3 and no C-MAC address flushing is required.
11. Acknowledgements 10. Security Considerations
The authors would like to thank Sami Boutros, Jose Liste, and Patrice All the security considerations in [RFC7432] apply directly to this
Brissette for their reviews and comments of this document. We would document because this document leverages the control plane described
also like to thank Giles Heron for several rounds of reviews and in [RFC7432] and their associated procedures -- although not the
providing valuable inputs to get this draft ready for IESG complete set but rather a subset.
submission.
12. Security Considerations This document does not introduce any new security considerations
beyond that of [RFC7432] and [RFC4761] because advertisements and
processing of B-MAC addresses follow that of [RFC7432] and processing
of C-MAC addresses follow that of [RFC4761] -- i.e, B-MAC addresses
are learned in the control plane and C-MAC addresses are learned in
data plane.
All the security considerations in [EVPN] apply directly to this 11. IANA Considerations
document because this document leverages [EVPN] control plane and
their associated procedures - although not the complete set but
rather a subset.
13. IANA Considerations There are no additional IANA considerations for PBB-EVPN beyond what
is already described in [RFC7432].
There is no additional IANA considerations for PBB-EVPN beyond what 12. References
is already described in [EVPN].
14. Normative References 12.1. Normative References
[EVPN] Sajassi, et al., "BGP MPLS Based Ethernet VPN", draft- [PBB] IEEE, "IEEE Standard for Local and metropolitan area
ietf-l2vpn-evpn-11.txt, work in progress, October 2014. networks - Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", Clauses 25 and 26, IEEE Std
802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
15. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS) [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Interoperability with Provider Backbone Bridges", RFC Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
7080, December 2013. Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7209] A. Sajassi, et al., "Requirements for Ethernet VPN 12.2. Informative References
(EVPN)", RFC 7209, May 2014.
[PBB] Clauses 25 and 26 of "IEEE Standard for Local and [MMRP] IEEE, "IEEE Standard for Local and metropolitan area
metropolitan area networks - Media Access Control (MAC) networks - Media Access Control (MAC) Bridges and Virtual
Bridges and Virtual Bridged Local Area Networks", IEEE Std Bridged Local Area Networks", Clause 10, IEEE Std 802.1Q,
802.1Q, 2013. DOI 10.1109/IEEESTD.2011.6009146.
[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan [OVERLAY] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Isaac, A.,
area networks - Media Access Control (MAC) Bridges and Uttaro, J., Henderickx, W., Shekhar, R., Salam, S., Patel,
Virtual Bridged Local Area Networks", IEEE Std 802.1Q, K., Rao, D., and S. Thoria, "A Network Virtualization
2013. Overlay Solution using EVPN",
draft-ietf-bess-evpn-overlay-01, February 2015.
16. Authors' Addresses [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>.
Ali Sajassi [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>.
[RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual
Private LAN Service (VPLS) Interoperability with Provider
Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080,
December 2013, <http://www.rfc-editor.org/info/rfc7080>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<http://www.rfc-editor.org/info/rfc7209>.
Acknowledgements
The authors would like to thank Jose Liste and Patrice Brissette for
their reviews and comments of this document. We would also like to
thank Giles Heron for several rounds of reviews and providing
valuable inputs to get this document ready for IESG submission.
Contributors
In addition to the authors listed, the following individuals also
contributed to this document.
Lizhong Jin, ZTE
Sami Boutros, Cisco
Dennis Cai, Cisco
Keyur Patel, Cisco
Sam Aldrin, Huawei
Himanshu Shah, Ciena
Jorge Rabadan, ALU
Authors' Addresses
Ali Sajassi, editor
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134
United States
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
Nabil Bitar Nabil Bitar
Verizon Communications Verizon Communications
Email : nabil.n.bitar@verizon.com Email: nabil.n.bitar@verizon.com
Aldrin Isaac Aldrin Isaac
Bloomberg Juniper
Email: aisaac71@bloomberg.net Email: aisaac@juniper.net
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.com
Lizhong Jin
Shanghai,
China
Email: lizho.jin@gmail.comLizhong Jin
 End of changes. 200 change blocks. 
582 lines changed or deleted 631 lines changed or added

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