Internet DRAFT - draft-ietf-l2vpn-trill-evpn
draft-ietf-l2vpn-trill-evpn
Internet Working Group Ali Sajassi
Internet Draft Samer Salam
Category: Standards Track Cisco
Aldrin Issac
Bloomberg
Nabil Bitar
Verizon
Sam Aldrin
Huawei
Expires: April 1, 2015 October 1, 2014
TRILL-EVPN
draft-ietf-l2vpn-trill-evpn-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Sajassi et al. Expires April 1, 2015 [Page 1]
INTERNET DRAFT TRILL-EVPN October 1, 2014
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document discusses how Ethernet VPN (E-VPN) technology is used
to interconnect TRILL [TRILL] networks over an MPLS/IP network, with
two key characteristics: C-MAC address transparency on the hand-off
point and control-plane isolation among the interconnected TRILL
networks.
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. C-MAC Address Transparency on the Hand-off Point . . . . . 4
4.2. Control Plane Isolation among TRILL Networks . . . . . . . 5
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
5.1. TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 6
5.2. TRILL Nickname Advertisement Route . . . . . . . . . . . . 7
5.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 8
5.5. Handling Multicast . . . . . . . . . . . . . . . . . . . . 9
5.5.1. Multicast Stitching with Per-Source Load Balancing . . 10
5.5.2. Multicast Stitching with Per-VLAN Load Balancing . . . 10
5.5.3. Multicast Stitching with Per-Flow Load Balancing . . . 11
5.5.4. Multicast Stitching with Per-Tree Load Balancing . . . 11
6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Intellectual Property Considerations . . . . . . . . . . . . 12
11. Normative References . . . . . . . . . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . 13
Sajassi et al. Expires April 1, 2015 [Page 2]
INTERNET DRAFT TRILL-EVPN October 1, 2014
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Sajassi et al. Expires April 1, 2015 [Page 3]
INTERNET DRAFT TRILL-EVPN October 1, 2014
1. Introduction
[E-VPN] introduces a solution for multipoint L2VPN services, with
advanced multi-homing capabilities, using BGP for distributing
customer/client MAC address reach-ability information over the core
MPLS/IP network. [TRILL] defines a solution for optimal forwarding of
Ethernet frames with support for multipathing of unicast and
multicast traffic, using IS-IS control-plane and associated tunneling
encapsulation that includes a hop count. In this document, we discuss
how Ethernet VPN (E-VPN) technology can be used to interconnect TRILL
[TRILL] networks over an MPLS/IP network, while guaranteeing two key
characteristics: C-MAC address transparency on the hand-off point and
control-plane isolation among the interconnected TRILL networks. The
resulting solution is referred to as TRILL-EVPN.
2. Contributors
In addition to the authors listed above, the following individuals
also contributed to this document.
Keyur Patel Cisco
Tissa Senevirathne Cisco
3. Terminology
CE: Customer Edge
C-MAC: Customer/Client MAC Address
DHD: Dual-homed Device
DHN: Dual-homed Network
E-VPN: Ethernet VPN
LACP: Link Aggregation Control Protocol
LSM: Label Switched Multicast
MDT: Multicast Delivery Tree
MES: MPLS Edge Switch
MP2MP: Multipoint to Multipoint
P2MP: Point to Multipoint
P2P: Point to Point
PoA: Point of Attachment
PW: Pseudowire
TRILL: Transparent Interconnect of Lots of Links
4. Requirements
4.1. C-MAC Address Transparency on the Hand-off Point
[TRILL] addresses the problem of MAC address table scalability on
Sajassi et al. Expires April 1, 2015 [Page 4]
INTERNET DRAFT TRILL-EVPN October 1, 2014
intermediate switching devices by introducing a tunneling technology
and confining C-MAC address learning/forwarding to the edge of the
TRILL network. When TRILL networks are interconnected over an MPLS/IP
network, it is required to maintain C-MAC address transparency on the
hand-off point and the edge (i.e. MES) of the MPLS network.
Otherwise, the MPLS edge nodes may suffer from MAC address table
space exhaustion given that they would need to learn the C-MAC
addresses from all interconnected TRILL networks.
TRILL-EVPN supports seamless interconnect with TRILL while
guaranteeing C-MAC address transparency on the MES nodes.
4.2. Control Plane Isolation among TRILL Networks
It is required to maintain control-plane isolation among the various
TRILL networks being interconnected over the MPLS/IP network. This
ensures the following characteristics:
- scalability of the IS-IS control plane in large deployments. In
TRILL, all nodes must calculate the shared multicast trees, so as the
number of interconnected cloud networks scales, this places a burden
on the RBridges, especially if roots are to be located in every site
to ensure optimality of the data-path.
- fault domain localization, where link or node failures in one site
do not trigger SPF re-computations in remote sites.
Interconnect solutions which extend the IS-IS control-plane over the
MPLS network, as an overlay, do not meet this requirement. TRILL-EVPN
provides control-plane isolation between interconnected TRILL
networks by terminating the TRILL IS-IS at the MPLS edge nodes.
5. Solution Overview
TRILL-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.
Sajassi et al. Expires April 1, 2015 [Page 5]
INTERNET DRAFT TRILL-EVPN October 1, 2014
+--------------+
| |
+---------+ | 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 1: Interconnecting TRILL Networks with TRILL-EVPN
5.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
Sajassi et al. Expires April 1, 2015 [Page 6]
INTERNET DRAFT TRILL-EVPN October 1, 2014
separate TRILL islands interconnected via TRILL-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-MULTILEVEL].
5.2. TRILL Nickname Advertisement Route
A new BGP route is defined to support the interconnection of TRILL
networks over TRILL-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 (1 octet) |
+---------------------------------------+
Figure 2: 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.
5.3. Frame Format
The encapsulation for the transport of TRILL frames over MPLS is
encoded as shown in the figure below:
Sajassi et al. Expires April 1, 2015 [Page 7]
INTERNET DRAFT TRILL-EVPN October 1, 2014
+------------------+
| IP/MPLS Header |
+------------------+
| TRILL Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 3: 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.
5.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
Sajassi et al. Expires April 1, 2015 [Page 8]
INTERNET DRAFT TRILL-EVPN October 1, 2014
next hop is a remote MES, the local MES would then encapsulate the
TRILL frame with appropriate MPLS label stack. 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.
5.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
Sajassi et al. Expires April 1, 2015 [Page 9]
INTERNET DRAFT TRILL-EVPN October 1, 2014
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.
5.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.
5.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,
Sajassi et al. Expires April 1, 2015 [Page 10]
INTERNET DRAFT TRILL-EVPN October 1, 2014
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.
5.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.
5.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
Sajassi et al. Expires April 1, 2015 [Page 11]
INTERNET DRAFT TRILL-EVPN October 1, 2014
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.
6. OAM Considerations
When TRILL networks are interconnected over MPLS networks, the IS-IS
control plane is not extended across the MPLS network. As described
in earlier sections, this will provide advantage in scaling the TRILL
networks without any issues when changes happen within different
TRILL networks.
TRILL OAM could be performed in TRILL networks, within the framework
defined in [TRILL-OAM-FWRK]. When TRILL networks are interconnected,
TRILL OAM frames just like TRILL data frames are transparently sent
over the MPLS network. There are no changes required to perform TRILL
OAM operations. MPLS OAM operations could be performed as defined in
[MPLS-OAM] to ensure the working of MPLS network interconnecting the
TRILL networks.
7. Acknowledgements
The authors would like to thank Sami Boutros and Dennis Cai for their
valuable comments.
8. Security Considerations
There are no additional security aspects beyond those of VPLS/H-VPLS
that need to be discussed here.
9. IANA Considerations
This document requires IANA to assign a new SAFI value for L2VPN_MAC
SAFI.
10. Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
11. Normative References
Sajassi et al. Expires April 1, 2015 [Page 12]
INTERNET DRAFT TRILL-EVPN October 1, 2014
[TRILL] Perlman et al., "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July, 2011.
12. Informative References
[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",
draft-ietf-l2vpn-evpn-req-04.txt, work in progress, July,
2013.
[E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-04.txt, work in progress, July, 2013.
[TRILL-CMT] Senevirathne et al., "Coordinated Multicast Trees for
TRILL", draft-tissa-trill-cmt-01.txt, work in progress,
January 2012.
[TRILL-MULTILEVEL] Senevirathne et al., "Default Nickname Based
Approach for Multilevel TRILL", draft-tissa-trill-
multilevel-02.txt, work in progress, February 2012.
[TRILL-OAM-FWRK] Salam et al., "TRILL OAM Framework", draft-ietf-
trill-oam-framework-03, September, 2013.
[MPLS-OAM] Kompella & Swallow, "Detecting MPLS Data Plane Failures",
RFC 4379, February, 2006.
13. Authors' Addresses
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Samer Salam
Cisco
Email: ssalam@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Aldrin Isaac
Bloomberg
Email: aisaac71@bloomberg.net
Sajassi et al. Expires April 1, 2015 [Page 13]
INTERNET DRAFT TRILL-EVPN October 1, 2014
Sam Aldrin
Huawei
Email: sam.aldrin@gmail.com
Sajassi et al. Expires April 1, 2015 [Page 14]
