draft-ietf-l2vpn-pbb-evpn-02.txt   draft-ietf-l2vpn-pbb-evpn-03.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Florin Balus Nabil Bitar Florin Balus Nabil Bitar
Wim Henderickx Verizon Wim Henderickx Verizon
Alcatel-Lucent Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Clarence Filsfils Bloomberg Clarence Filsfils Bloomberg
Dennis Cai Dennis Cai
Cisco Lizhong Jin Cisco Lizhong Jin
ZTE ZTE
Expires: September 29, 2012 March 29, 2012 Expires: December 20, 2012 June 20, 2012
PBB E-VPN PBB-EVPN
draft-ietf-l2vpn-pbb-evpn-02 draft-ietf-l2vpn-pbb-evpn-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5 4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5
4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5 4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5
4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5 4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5
4.4. Interworking with TRILL and 802.1aq Access Networks with 4.4. Per Site Policy Support . . . . . . . . . . . . . . . . . 6
C-MAC Address Transparency . . . . . . . . . . . . . . . . 6 4.5. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6
4.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 6
4.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7 6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7
6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 8 6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7
6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 8 6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 7
6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 8 6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 7
7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8 7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8
7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 9 7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 8
7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 9 7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 8
7.2.1.1 MES B-MAC Address Assignment . . . . . . . . . . . 9 7.2.1.1 MES B-MAC Address Assignment . . . . . . . . . . . 8
7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 11 7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 10
7.2.1.3 Split Horizon and Designated Forwarder Election . . 11 7.2.1.3 Split Horizon and Designated Forwarder Election . . 11
7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 12 7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 11
7.2.2.1 MES B-MAC Address Assignment . . . . . . . . . . . . 12 7.2.2.1 MES B-MAC Address Assignment . . . . . . . . . . . . 11
7.2.2.2 Split Horizon and Designated Forwarder Election . . 12 7.2.2.2 Split Horizon and Designated Forwarder Election . . 12
7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12 7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 12
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 12
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 13
9. Seamless Interworking with TRILL . . . . . . . . . . . . . . . 14 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 13
9.1 TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 15 9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 14
9.2 TRILL Nickname Advertisement Route . . . . . . . . . . . . 16 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 14
9.3 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4 Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 17 10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 15
9.5 Handling Multicast . . . . . . . . . . . . . . . . . . . . . 18 10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 15
9.5.1 Multicast Stitching with Per-Source Load Balancing . . . 19 10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 16
9.5.2 Multicast Stitching with Per-VLAN Load Balancing . . . . 19 10.3. C-MAC Address Learning and Confinement . . . . . . . . . 16
9.5.3 Multicast Stitching with Per-Flow Load Balancing . . . . 20 10.4. Seamless Interworking with TRILL and 802.1aq Access
9.5.4 Multicast Stitching with Per-Tree Load Balancing . . . . 20 Networks . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 21 10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 17
10.2 B-MAC Address Assignment . . . . . . . . . . . . . . . . . 21 10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 17
10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11.1. MAC Advertisement Route Scalability . . . . . . . . . . . 22 14. Intellectual Property Considerations . . . . . . . . . . . . 18
11.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 23 15. Normative References . . . . . . . . . . . . . . . . . . . . 18
11.3. C-MAC Address Learning and Confinement . . . . . . . . . 23 16. Informative References . . . . . . . . . . . . . . . . . . . 18
11.4. Seamless Interworking with TRILL and 802.1aq Access 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
Networks . . . . . . . . . . . . . . . . . . . . . . . . 23
11.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 24
11.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
15. Intellectual Property Considerations . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . 25
17. Informative References . . . . . . . . . . . . . . . . . . . 25
18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[E-VPN] introduces a solution for multipoint L2VPN services, with [E-VPN] introduces a solution for multipoint L2VPN services, with
advanced multi-homing capabilities, using BGP for distributing advanced multi-homing capabilities, using BGP for distributing
customer/client MAC address reach-ability information over the core customer/client MAC address reach-ability information over the core
MPLS/IP network. [802.1ah] defines an architecture for Ethernet MPLS/IP network. [802.1ah] defines an architecture for Ethernet
Provider Backbone Bridging (PBB), where MAC tunneling is employed to Provider Backbone Bridging (PBB), where MAC tunneling is employed to
improve service instance and MAC address scalability in Ethernet as improve service instance and MAC address scalability in Ethernet as
well as VPLS networks [PBB-VPLS]. well as VPLS networks [PBB-VPLS].
skipping to change at page 4, line 29 skipping to change at page 4, line 29
using C-MAC aggregation and B-MAC sub-netting, confine the scope of using C-MAC aggregation and B-MAC sub-netting, confine the scope of
C-MAC learning to only active flows, offer per site policies and C-MAC learning to only active flows, offer per site policies and
avoid C-MAC address flushing on topology changes. The combined avoid C-MAC address flushing on topology changes. The combined
solution is referred to as PBB-EVPN. solution is referred to as PBB-EVPN.
2. Contributors 2. Contributors
In addition to the authors listed above, the following individuals In addition to the authors listed above, the following individuals
also contributed to this document. also contributed to this document.
Keyur Patel Cisco Keyur Patel, Cisco
Sam Aldrin, Huawei
3. Terminology 3. Terminology
BEB: Backbone Edge Bridge BEB: Backbone Edge Bridge
B-MAC: Backbone MAC Address B-MAC: Backbone MAC Address
CE: Customer Edge CE: Customer Edge
C-MAC: Customer/Client MAC Address C-MAC: Customer/Client MAC Address
DHD: Dual-homed Device DHD: Dual-homed Device
DHN: Dual-homed Network DHN: Dual-homed Network
LACP: Link Aggregation Control Protocol LACP: Link Aggregation Control Protocol
skipping to change at page 6, line 6 skipping to change at page 6, line 7
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 MES, the addresses that are not part of active traffic flows on that MES, 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 table (RIB). In network applications with
millions of C-MAC addresses, this introduces a non-trivial waste of millions of C-MAC addresses, this introduces a non-trivial waste of
MES resources. As such, it is required to confine the scope of MES resources. As such, it is required to confine the scope of
visibility of C-MAC addresses only to those MES nodes that are visibility of C-MAC addresses only to those MES 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. Interworking with TRILL and 802.1aq Access Networks with C-MAC 4.4. Per Site Policy Support
Address Transparency
[TRILL] and [802.1aq] define next generation Ethernet bridging
technologies that offer optimal forwarding using IS-IS control plane,
and C-MAC address transparency via Ethernet tunneling technologies.
When access networks based on TRILL or 802.1aq are interconnected
over an MPLS/IP network, it is required to guarantee C-MAC address
transparency on the hand-off point and the edge (i.e. MES) of the
MPLS network. As such, solutions that require termination of the
access data-plane encapsulation (i.e. TRILL or 802.1aq) at the hand-
off to the MPLS network do not meet this transparency requirement,
and expose the MPLS edge devices to the MAC address scalability
problem.
PBB-EVPN supports seamless interconnect with these next generation
Ethernet solutions while guaranteeing C-MAC address transparency on
the MES nodes.
4.5. 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 MES nodes in the network This includes the ability to control which MES nodes in the network
can forward traffic to, or from, a given site. PBB-EVPN is capable of can forward traffic to, or from, a given site. PBB-EVPN is capable of
providing this granularity of policy control. In the case where per providing this granularity of policy control. In the case where per
C-MAC address granularity is required, the EVI can always continue to C-MAC address granularity is required, the EVI can always continue to
operate in E-VPN mode. operate in E-VPN mode.
4.6. Avoiding C-MAC Address Flushing 4.5. Avoiding C-MAC Address Flushing
It is required to avoid C-MAC address flushing upon link, port or It is required to avoid C-MAC address flushing upon link, port or
node failure for multi-homed devices and networks. This is in order node failure for multi-homed devices and networks. This is in order
to speed up re-convergence upon failure. to speed up re-convergence upon failure.
5. Solution Overview 5. Solution Overview
The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge
(BEB) functionality on the E-VPN MES nodes similar to PBB-VPLS, where (BEB) functionality on the E-VPN MES nodes similar to PBB-VPLS, where
BEB functionality is incorporated in the VPLS PE nodes. The MES BEB functionality is incorporated in the VPLS PE nodes. The MES
skipping to change at page 14, line 20 skipping to change at page 13, line 40
This is achieved by having each MES node snoop on ARP request and This is achieved by having each MES node snoop on ARP request and
response messages received over the access interfaces or the MPLS response messages received over the access interfaces or the MPLS
core. The MES builds a cache of IP / MAC address bindings from these core. The MES builds a cache of IP / MAC address bindings from these
snooped messages. The MES then uses this cache to respond to ARP snooped messages. The MES then uses this cache to respond to ARP
requests ingress on access ports and targeting hosts that are in requests ingress on access ports and targeting hosts that are in
remote sites. If the MES finds a match for the IP address in its ARP remote sites. If the MES finds a match for the IP address in its ARP
cache, it responds back to the requesting host and drops the request. cache, it 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 LSM.
9. Seamless Interworking with TRILL 9. Seamless Interworking with IEEE 802.1aq/802.1Qbp
PBB-EVPN enables seamless connectivity of TRILL networks over an
MPLS/IP core while ensuring control-plane separation among these
networks, and maintaining C-MAC address transparency on the MES
nodes.
Every TRILL network that is connected to the MPLS core runs an
independent instance of the IS-IS control-plane. Each MES
participates in the TRILL IS-IS control plane of its local site. The
MES peers, in IS-IS protocol, with the RBridges internal to the site,
but does not terminate the TRILL data-plane encapsulation. So, from a
control-plane viewpoint, the MES appears as an edge RBridge; whereas,
from a data-plane viewpoint, the MES appears as a core RBridge to the
TRILL network. The MES nodes encapsulate TRILL frames with MPLS in
the imposition path, and de-capsulate them in the disposition path.
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
|RB1 |--| | |MES1| |MES2| | |--| RB3|
+----+ | TRILL |---| | | |--| TRILL | +----+
+----+ | | +----+ +----+ | | +----+
|RB2 |--| | | Backbone | | |--| RB4|
+----+ +---------+ +--------------+ +---------+ +----+
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------------------------- TRILL -------------------------->| DP
|<----MPLS----->|
Legend: CP = Control Plane View
DP = Data Plane View
Figure 4: Interconnecting TRILL Networks with PBB-EVPN
9.1 TRILL Nickname Assignment
In TRILL, edge RBridges build forwarding tables that associate remote
C-MAC addresses with remote edge RBridge nicknames via data-path
learning (except if the optional ESADI function is in use). When
different TRILL networks are interconnected over an MPLS/IP network
using a seamless hand-off, the edge RBridges (corresponding to the
ingress and egress RBridges of particular traffic flows) may very
well reside in different TRILL networks. Therefore, in order to
guarantee correct connectivity, the TRILL Nicknames must be globally
unique across all the interconnected TRILL islands in a given EVI.
This can be achieved, for instance, by using a hierarchical Nickname
assignment paradigm, and encoding a Site ID in the high-order bits of
the Nickname:
Nickname = [Site ID : Rbridge ID ]
The Site ID uniquely identifies a TRILL network, whereas the RBridge
ID portion of the Nickname has local significance to a TRILL site,
and can be reused in different sites to designate different RBridges.
However, the fully qualified Nickname is globally unique in the
entire domain of interconnected TRILL networks for a given EVI.
It is worth noting here that this hierarchical Nickname encoding
scheme guarantees that Nickname collisions do not occur between
different TRILL islands. Therefore, there is no need to define TRILL
Nickname collision detection/resolution mechanisms to operate across
separate TRILL islands interconnected via PBB-EVPN.
Another point to note is that there are proposals to achieve per-site
Nickname significance; however, these proposals either require C-MAC
learning on the border RBridge (i.e. violate the C-MAC address
transparency requirement), or require a completely new encapsulation
and associated data-path for TRILL [TRILL-PERLMAN-MULTILEVEL].
9.2 TRILL Nickname Advertisement Route
A new BGP route is defined to support the interconnection of TRILL
networks over PBB-EVPN: the TRILL Nickname Advertisement' route,
encoded as follows:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| Nickname Length (1 octet) |
+---------------------------------------+
| RBridge Nickname (2 octets) |
+---------------------------------------+
| MPLS Label (n * 3 octets) |
+---------------------------------------+
Figure 5: TRILL Nickname Advertisement Route
The MES uses this route to advertise the reachability of TRILL
RBridge nicknames to other MES nodes in the EVI. The MPLS label
advertised in this route is allocated on a per EVI basis and serves
the purpose of identifying to the disposition MES that the MPLS-
encapsulated packet holds an MPLS encapsulated TRILL frame.
9.3 Frame Format
The encapsulation for the transport of TRILL frames over MPLS is
encoded as shown in the figure below:
+------------------+
| IP/MPLS Header |
+------------------+
| TRILL Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 6: TRILL over MPLS Encapsulation
It is worth noting here that while it is possible to transport
Ethernet encapsulated TRILL frames over MPLS, that approach
unnecessarily wastes 16 bytes per packet. That approach further
requires either the use of well-known MAC addresses or having the MES
nodes advertise in BGP their device MAC addresses, in order to
resolve the TRILL next-hop L2 adjacency. To that end, it is simpler
and more efficient to transport TRILL natively over MPLS, and this is
the reason why a new BGP route for TRILL Nickname advertisement is
defined.
9.4 Unicast Forwarding
Every MES advertises in BGP the Nicknames of all RBridges local to
its site in the TRILL Nickname Advertisement routes. Furthermore, the
MES advertises in IS-IS, to the local island, the Rbridge nicknames
of all remote switches in all the other TRILL islands that the MES
has learned via BGP. This is required since TRILL [RFC6325] currently
does not define the concept of default routes. However, if the
concept of default routes is added to TRILL, then the MES can
advertise itself as a border RBridge, and all the other Rbridges in
the TRILL network would install a default route pointing to the MES.
The default route would be used for all unknown destination
Nicknames. This eliminates the need to redistribute Nicknames learnt
via BGP into TRILL IS-IS.
Note that by having multiple MES nodes (connected to the same TRILL
island) advertise routes to the same RBridge nickname, with equal BGP
Local_Pref attribute, it is possible to perform active/active load-
balancing to/from the MPLS core.
When a MES receives an Ethernet-encapsulated TRILL frame from the
access side, it removes the Ethernet encapsulation (i.e. outer MAC
header), and performs a lookup on the egress RBridge nickname in the
TRILL header to identify the next-hop. If the lookup yields that the
next hop is a remote MES, the local MES would then encapsulate the
TRILL frame in MPLS. The label stack comprises of the VPN label
(advertised by the remote MES), followed by an LSP/IGP label. From
that point onwards, regular MPLS forwarding is applied.
On the disposition MES, assuming penultimate-hop-popping is employed,
the MES receives the MPLS-encapsulated TRILL frame with a single
label: the VPN label. The value of the label indicates to the
disposition MES that this is a TRILL packet, so the label is popped,
the TTL field (in the TRILL header) is reinitialized and normal TRILL
processing is employed from this point onwards.
9.5 Handling Multicast
Each TRILL network independently builds its shared multicast trees.
The number of these trees need not match in the different
interconnected TRILL islands. In the MPLS/IP network, multiple
options are available for the delivery of multicast traffic:
- Ingress replication
- LSM with Inclusive trees
- LSM with Aggregate Inclusive trees
- LSM with Selective trees
- LSM with Aggregate Selective trees
When LSM is used, the trees may be either P2MP or MP2MP.
The MES nodes are responsible for stitching the TRILL multicast
trees, on the access side, to the ingress replication tunnels or LSM
trees in the MPLS/IP core. The stitching must ensure that the
following characteristics are maintained at all times:
1. Avoiding Packet Duplication: In the case where the TRILL network
is multi-homed to multiple MES nodes, if all of the MES nodes forward
the same multicast frame, then packet duplication would arise. This
applies to both multicast traffic from site to core as well as from
core to site.
2. Avoiding Forwarding Loops: In the case of TRILL network multi-
homing, the solution must ensure that a multicast frame forwarded by
a given MES to the MPLS core is not forwarded back by another MES (in
the same TRILL network) to the TRILL network of origin. The same
applies for traffic in the core to site direction.
3. Pacifying TRILL RPF Checks: For multicast traffic originating from
a different TRILL network, the RPF checks must be performed against
the disposition MES (i.e. the MES on which the traffic ingress into
the destination TRILL network).
There are two approaches by which the above operation can be
guaranteed: one offers per-source load-balancing while the other
offers per-flow load-balancing.
9.5.1 Multicast Stitching with Per-Source Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES is responsible for forwarding
multicast traffic from a given source RBridge. An MES would only
forward multicast traffic from source RBridges for which it is the
DF, in both the site to core as well as core to site directions. This
solves both the issue of avoiding packet duplication as well as the
issue of avoiding forwarding loops.
In addition, the MES node advertises in IS-IS the nicknames of remote
RBridges, learnt in BGP, for which it is the elected DF. This allows
all RBridges in the local TRILL network to build the correct RPF
state for these remote RBridge nicknames. Note that this results in
all unicast traffic to a given remote RBridge being forwarded to the
DF MES only (i.e. load-balancing of unicast traffic would not be
possible in the site to core direction).
Alternatively, all MES nodes in a redundancy group can advertise the
nicknames of all remote RBridges learnt in BGP. In addition, each MES
advertises the Affinity sub-TLV, defined in [TRILL-CMT], on behalf of
each of the remote RBridges for which it is the elected DF. This
ensures that the RPF check state is set up correctly in the TRILL
network, while allowing load-balancing of unicast traffic among the
MES nodes.
In this approach, all MES nodes in a given redundancy group can
forward and receive traffic on all TRILL trees.
9.5.2 Multicast Stitching with Per-VLAN Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES node is responsible for forwarding
multicast traffic associated with a given VLAN. An MES would forward
multicast traffic for a given VLAN only when it is the DF for this
VLAN. This forwarding rule applies in both the site to core as well
as core to site directions.
In addition, the MES nodes in the redundancy group partition among
themselves the set of TRILL multicast trees so that each MES only
sends traffic on a unique set of trees. This can be done using the RP
Election Protocol as discussed in [TRILL-MULTILEVEL]. Alternatively,
the BGP DF election could be used for that. Each MES, then,
advertises to the local TRILL network a Default Affinity sub-TLV, per
[TRILL-MULTILEVEL], listing the trees that it will be using for
multicast traffic originating from remote RBridges.
In this approach, each MES node in given TRILL network receives
traffic from all TRILL trees but forwards traffic on only a dedicated
subset of trees. Hence, the TRILL network must have at least as many
multicast trees as the number of directly attached MES nodes.
9.5.3 Multicast Stitching with Per-Flow Load Balancing
This approach is similar to the per-VLAN load-balancing approach
described above, with the difference being that the MES nodes perform
the BGP DF election on a per-flow basis. The flow is identified by an
N-Tuple comprising of Layer 2 and Layer 3 addresses in addition to
Layer 4 ports. This can be done by treating the N-Tuple as a numeric
value, and performing, for e.g., a modulo hash function against the
number of PEs in the redundancy group in order to identify the index
of the PE that is the DF for a given N-Tuple.
In this approach, each MES node in given TRILL network receives
traffic from all TRILL trees but forwards traffic on only a dedicated
subset of trees. Hence, the TRILL network must have at least as many
multicast trees as the number of directly attached MES nodes.
9.5.4 Multicast Stitching with Per-Tree Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES node is responsible for forwarding
multicast traffic associated with a given TRILL multicast tree. An
MES would forward multicast traffic with a given destination RBridge
nickname only when it is the DF for this nickname. This forwarding
rule applies in both the site to core as well as core to site
directions. The outcome of the BGP DF election is then used to drive
TRILL IS-IS advertisements: the MES advertises to the local TRILL
network a Default Affinity sub-TLV, per [TRILL-MULTILEVEL], listing
the trees for which it is the elected DF.
Note that on the egress MES, the destination RBridge Nickname in
multicast frames identifies the multicast tree of the remote TRILL
network from which the frame originated. If the TRILL tree
identifiers are not coordinated between sites, then the egress
Nickname has no meaning in the directly attached (destination) TRILL
network. So, the MES needs to select a new tree (after the MPLS
disposition) based on a hash function, and rewrite the frame with
this new destination Nickname before forwarding the traffic. This may
be necessary in certain deployments to ensure complete decoupling
between the TRILL sites connected to the MPLS core. On the other
hand, if the TRILL tree identifiers are coordinated between sites,
then the MES doesn't have to rewrite the destination nickname in the
TRILL header, after the MPLS disposition.
In this approach, each MES node in a given redundancy group forwards
and receives traffic on a disjoint set of TRILL trees. At a minimum,
the TRILL network must have as many multicast trees as the number of
directly attached MES nodes.
10. Seamless Interworking with IEEE 802.1aq/802.1Qbp
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|SW1 |--| | |MES1| |MES2| | |--| SW3| |SW1 |--| | |MES1| |MES2| | |--| 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
10.2 B-MAC Address Assignment 9.1 B-MAC Address Assignment
For the same reasons cited in the TRILL section, the B-MAC addresses For the same reasons cited in the TRILL section, the B-MAC addresses
need to be globally unique across all the IEEE 802.1aq / 802.1Qbp need to be globally unique across all the IEEE 802.1aq / 802.1Qbp
networks. The same hierarchical address assignment scheme depicted networks. The same hierarchical address assignment scheme depicted
above is proposed for B-MAC addresses as well. above is proposed for B-MAC addresses as well.
10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route 9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route
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 BGP MAC Advertisement route already defined in
[E-VPN]. [E-VPN].
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:
+------------------+ +------------------+
skipping to change at page 22, line 19 skipping to change at page 15, line 19
+------------------+ +------------------+
| Ethernet Header | | Ethernet Header |
+------------------+ +------------------+
| Ethernet Payload | | Ethernet Payload |
+------------------+ +------------------+
| Ethernet FCS | | Ethernet FCS |
+------------------+ +------------------+
Figure 8: PBB over MPLS Encapsulation Figure 8: PBB over MPLS Encapsulation
10.3 Operation: 9.3 Operation:
When a MES receives a PBB-encapsulated Ethernet frame from the access When a MES 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 MES, the local MES would then encapsulate the PBB frame in remote MES, the local MES would then encapsulate the PBB frame in
MPLS. The label stack comprises of the VPN label (advertised by the MPLS. The label stack comprises of the VPN label (advertised by the
remote PE), followed by an LSP/IGP label. From that point onwards, remote PE), followed by an LSP/IGP label. From that point onwards,
regular MPLS forwarding is applied. regular MPLS forwarding is applied.
On the disposition MES, assuming penultimate-hop-popping is employed, On the disposition MES, assuming penultimate-hop-popping is employed,
the MES receives the MPLS-encapsulated PBB frame with a single label: the MES receives the MPLS-encapsulated PBB frame with a single label:
the VPN label. The value of the label indicates to the disposition the VPN label. The value of the label indicates to the disposition
MES that this is a PBB frame, so the label is popped, the TTL field MES that this is a PBB frame, so the label is popped, the TTL field
(in the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is (in the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is
employed from this point onwards. employed from this point onwards.
11. 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.
11.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 segments (sites), rather than the number of
hosts/servers. This is because the B-MAC addresses of the MESes, hosts/servers. This is because the B-MAC addresses of the MESes,
rather than C-MAC addresses (of hosts/servers) are being advertised rather than C-MAC addresses (of hosts/servers) are being advertised
in BGP. And, as discussed above, there's a one-to-one mapping between in BGP. And, as discussed above, there's a one-to-one mapping between
multi-homed segments and B-MAC addresses, whereas there's a one-to- multi-homed segments and B-MAC addresses, whereas there's a one-to-
one or many-to-one mapping between single-homed segments and B-MAC one or many-to-one mapping between single-homed segments and B-MAC
addresses for a given MES. As a result, the volume of MAC addresses for a given MES. As a result, the volume of MAC
Advertisement Routes in PBB-EVPN is multiple orders of magnitude less Advertisement Routes in PBB-EVPN is multiple orders of magnitude less
than E-VPN. than E-VPN.
11.2. C-MAC Mobility with MAC Sub-netting 10.2. C-MAC Mobility with MAC Sub-netting
In PBB-EVPN, if a MES allocates its B-MAC addresses from a contiguous In PBB-EVPN, if a MES allocates its B-MAC addresses from a contiguous
range, then it can advertise a MAC prefix rather than individual 48- range, then it can advertise a MAC prefix rather than individual 48-
bit addresses. It should be noted that B-MAC addresses can easily be bit addresses. It should be noted that B-MAC addresses can easily be
assigned from a contiguous range because MES nodes are within the assigned from a contiguous range because MES nodes are within the
provider administrative domain; however, CE devices and hosts are provider administrative domain; however, CE devices and hosts are
typically not within the provider administrative domain. The typically not within the provider administrative domain. The
advantage of such MAC address sub-netting can be maintained even as advantage of such MAC address sub-netting can be maintained even as
C-MAC addresses move from one Ethernet segment to another. This is C-MAC addresses move from one Ethernet segment to another. This is
because the C-MAC address to B-MAC address association is learnt in because the C-MAC address to B-MAC address association is learnt in
skipping to change at page 23, line 32 skipping to change at page 16, line 32
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 sub-netting applies to the B-MAC addresses which
are statically associated with MES nodes and are not subject to are statically associated with MES nodes and are not subject to
mobility. As C-MAC addresses move from one segment to another, the mobility. As C-MAC addresses move from one segment to another, the
binding of C-MAC to B-MAC addresses is updated via data-plane binding of C-MAC to B-MAC addresses is updated via data-plane
learning. learning.
11.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, MES nodes not participating in active data-plane learning. As such, MES 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, MES nodes will not maintain any addresses are not distributed in BGP, MES nodes will not maintain any
record of them in control-plane routing table. record of them in control-plane routing table.
11.4. Seamless Interworking with TRILL and 802.1aq Access Networks 10.4. Seamless Interworking with TRILL and 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 |--| | |MES1| |MES2| | |--| CE | | CE |--| | |MES1| |MES2| | |--| CE |
skipping to change at page 24, line 31 skipping to change at page 17, line 31
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 MES1. If PBB-EVPN is also maintaining C-MAC address transparency on MES1. 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 MES2 as well. addresses would be transparent to MES2 as well.
Interoperability with TRILL access network will be described in Interoperability with TRILL access network will be described in
future revision of this draft. future revision of this draft.
11.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, a unique B-MAC address can be associated with every site
(single-homed or multi-homed). Given that the B-MAC addresses are (single-homed or multi-homed). Given that the B-MAC addresses are
sent in BGP MAC Advertisement routes, it is possible to define per sent in BGP MAC Advertisement routes, it is possible to define per
site (i.e. B-MAC) forwarding policies including policies for E-TREE site (i.e. B-MAC) forwarding policies including policies for E-TREE
service. service.
11.6. Avoiding C-MAC Address Flushing 10.6. Avoiding C-MAC Address Flushing
With PBB-EVPN, it is possible to avoid C-MAC address flushing upon With PBB-EVPN, it is possible to avoid C-MAC address flushing upon
topology change affecting a multi-homed device. To illustrate this, topology change affecting a multi-homed device. To illustrate this,
consider the example network of Figure 1. Both MES1 and MES2 consider the example network of Figure 1. Both MES1 and MES2
advertize the same B-MAC address (BM1) to MES3. MES3 then learns the advertize the same B-MAC address (BM1) to MES3. MES3 then learns the
C-MAC addresses of the servers/hosts behind CE1 via data-plane C-MAC addresses of the servers/hosts behind CE1 via data-plane
learning. If AC1 fails, then MES3 does not need to flush any of the learning. If AC1 fails, then MES3 does not need to flush any of the
C-MAC addresses learnt and associated with BM1. This is because MES1 C-MAC addresses learnt and associated with BM1. This is because MES1
will withdraw the MAC Advertisement routes associated with BM1, will withdraw the MAC Advertisement routes associated with BM1,
thereby leading MES3 to have a single adjacency (to MES2) for this B- thereby leading MES3 to have a single adjacency (to MES2) for this B-
MAC address. Therefore, the topology change is communicated to MES3 MAC address. Therefore, the topology change is communicated to MES3
and no C-MAC address flushing is required. and no C-MAC address flushing is required.
12. Acknowledgements 11. Acknowledgements
TBD. TBD.
13. Security Considerations 12. Security Considerations
There are no additional security aspects beyond those of VPLS/H-VPLS There are no additional security aspects beyond those of VPLS/H-VPLS
that need to be discussed here. that need to be discussed here.
14. IANA Considerations 13. IANA Considerations
This document requires IANA to assign a new SAFI value for L2VPN_MAC This document requires IANA to assign a new SAFI value for L2VPN_MAC
SAFI. SAFI.
15. Intellectual Property Considerations 14. Intellectual Property Considerations
This document is being submitted for use in IETF standards This document is being submitted for use in IETF standards
discussions. discussions.
16. Normative References 15. Normative References
[802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider
Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008. Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008.
17. Informative References 16. Informative References
[PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider [PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider
Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop- Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop-
02.txt, work in progress, July, 2011. 02.txt, work in progress, July, 2011.
[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)", [EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",
draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in
progress, July, 2011. progress, July, 2011.
[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-00.txt, work in progress, February, 2012. l2vpn-evpn-00.txt, work in progress, February, 2012.
[TRILL-CMT] Senevirathne et al., "Coordinated Multicast Trees for 17. Authors' Addresses
TRILL", draft-tissa-trill-cmt-00.txt, work in progress,
January 2012.
[TRILL-MULTILEVEL] Senevirathne et al., "Default Nickname Based
Approach for Multilevel TRILL", draft-tissa-trill-
multilevel-00.txt, work in progress, February 2012.
18. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
595 Burrard Street, Suite 2123 595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com Email: ssalam@cisco.com
Sami Boutros Sami Boutros
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
 End of changes. 31 change blocks. 
404 lines changed or deleted 58 lines changed or added

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