wdiff rfc8385.original rfc8385.txt

INTERNET-DRAFT Mohammed
Internet Engineering Task Force (IETF) M. Umair
Intended Status:
Request for Comments: 8385 Cisco
Category: Informational S. Kingston Smiler Selvaraj
IPInfusion
Donald
ISSN: 2070-1721 PALC Networks
D. Eastlake 3rd
Huawei
Lucy
L. Yong
Self
Expires: September 17, 2018 March 18,
Independent
June 2018

TRILL

Transparent Interconnection of Lots of Links (TRILL)
Transparent Transport over MPLS
draft-ietf-trill-transport-over-mpls-08.txt

Abstract

This document specifies methods to interconnect multiple Transparent TRILL
(Transparent Interconnection of Lots of links (TRILL) Links) sites with an
intervening MPLS network using existing TRILL and VPLS (Virtual
Private LAN Service) standards. This draft document addresses two problems as follows:
problems: 1) Providing providing connection between more than two TRILL sites
that are separated by an MPLS provider network. network and 2) Providing providing a
single logical virtualized TRILL network for different tenants that
are separated by an MPLS provider network.

Status of This Memo

This Internet-Draft document is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Distribution of this not an Internet Standards Track specification; it is
published for informational purposes.

This document is unlimited. Comments should be sent
to the authors or the TRILL working group mailing list:
trill@ietf.org.

Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
(IETF). It represents the consensus of the IETF community. It has
received public review and its working groups. Note that
other groups may also distribute working has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents as Internet-
Drafts.

Internet-Drafts
approved by the IESG are draft documents valid for a maximum candidate for any level of six months Internet
Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It
https://www.rfc-editor.org/info/rfc8385.

This document is inappropriate subject to use Internet-Drafts BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as reference
material or they describe your rights and restrictions with respect
to cite them other than this document. Code Components extracted from this document must
include Simplified BSD License text as "work described in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list Section 4.e of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

INTERNET-DRAFT TRILL Transparent Transport over MPLS
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction............................................3 Introduction ....................................................3
1.1. Terminology...........................................3 Terminology ................................................3
2. TRILL Over MPLS Model...................................5 TRILL-over-MPLS Model ...........................................5
3. VPLS Model..............................................6
3.1 Model ......................................................5
3.1. Entities in the VPLS Model.............................7
3.2 Model .................................6
3.2. TRILL Adjacency for VPLS model.........................8
3.3 Model .............................7
3.3. MPLS encapsulation Encapsulation for VPLS model......................8
3.4 Loop Free provider PSN/MPLS............................8
3.5 Model ..........................7
3.4. Loop-Free Provider PSN/MPLS ................................7
3.5. Frame Processing.......................................8 Processing ...........................................7
4. VPTS Model..............................................9
4.1 Model ......................................................7
4.1. Entities in the VPTS Model............................11
4.1.1 Model .................................9
4.1.1. TRILL Intermediate Routers (TIR)....................11
4.1.2 Router (TIR) ....................10
4.1.2. Virtual TRILL Switch/Service Domain (VTSD)..........12
4.2 (VTSD) .........10
4.2. TRILL Adjacency for VPTS model........................12
4.3 Model ............................10
4.3. MPLS encapsulation Encapsulation for VPTS model.....................12
4.4 Loop Free provider PSN/MPLS...........................12 Model .........................10
4.4. Loop-Free Provider PSN/MPLS ...............................11
4.5. Frame Processing.....................................13
4.5.1 Multi-Destination Processing ..........................................11
4.5.1. Multi-destination Frame Processing..................13
4.5.2 Processing .................11
4.5.2. Unicast Frame Processing............................13 Processing ...........................11
5. VPTS Model Versus versus VPLS Model...........................14 Model ...................................11
6. Packet Processing Between Pseudowires..................14 between Pseudowires ..........................12
7. Efficiency Considerations..............................15 Considerations ......................................12
8. Security Considerations................................15 Considerations ........................................12
9. IANA Considerations....................................16 Considerations ............................................13
10. Normative References......................................17 References ..........................................13
11. Informative References....................................18

Acknowledgements..........................................19 References ........................................14
Acknowledgements ..................................................15
Authors' Addresses........................................19

INTERNET-DRAFT TRILL Transparent Transport over MPLS Addresses ................................................15

1. Introduction

The IETF Transparent Interconnection of Lots of Links (TRILL)
protocol [RFC6325] [RFC7177] [RFC7780] provides transparent
forwarding in multi-hop networks with arbitrary topology and link
technologies using a header with a hop count and link-state routing.
TRILL provides optimal pair-wise forwarding without configuration,
safe forwarding even during periods of temporary loops, and support
for multipathing of both unicast and multicast traffic. Intermediate
Systems (ISs) implementing TRILL are called Routing Bridges
(RBridges) or TRILL Switches switches.

This document, in conjunction with [RFC7173] on TRILL Transport transport using
Pseudowires,
pseudowires, addresses two problems:

1) Providing providing connection between more than two TRILL sites belongs that belong
to a single TRILL network that and are separated by an MPLS provider
network using [RFC7173]. (Herein (Herein, this is also called problem "problem
statement 1.) 1".)

2) Providing providing a single logical virtualized TRILL network for different
tenants that are separated by an MPLS provider network. In short short,
this is for providing connection between TRILL sites belonging to
a tenant/tenants over a MPLS provider network. (Herein (Herein, this is
also called
problem "problem statement 2.) 2".)

A tenant is the administrative entity on whose behalf their
associated services are managed. Here tenant Here, "tenant" refers to a TRILL
campus that is segregated from other tenants for security reasons.

A key multi-tenancy requirement is traffic isolation so that one
tenant's traffic is not visible to any other tenant. This draft document
also addresses the problem of multi-tenancy by isolating one tenant's
traffic from the other.

[RFC7173] mentions how to interconnect a pair of Transparent
Interconnection of Lots of Links (TRILL) TRILL switch ports
using pseudowires. This document explains, explains how to connect multiple
TRILL sites (not limited to only two sites) using the mechanisms and
encapsulations defined in [RFC7173].

1.1. Terminology

Acronyms and terms used in this document include the following:

AC - Attachment Circuit [RFC4664]

Data Label - VLAN Label or FGL

INTERNET-DRAFT TRILL Transparent Transport over MPLS Fine-Grained Label
database - IS-IS link state database

ECMP - Equal Cost Multi Path Equal-Cost Multipath

FGL - Fine-Grained Labeling [RFC7172]

IS-IS - Intermediate System to Intermediate System [IS-IS]

LDP - Label Distribution Protocol

LAN - Local Area Network

MPLS - Multi-Protocol Multiprotocol Label Switching

PBB - Provider Backbone Bridging

PE - Provider Edge Device device

PSN - Packet Switched Network

PW - Pseudowire [RFC4664]

TIR - TRILL Intermediate Router (Devices (Device that has both IP/MPLS
and TRILL functionality)

TRILL - Transparent Interconnection of Lots of Links OR Tunneled
Routing in the Link Layer

TRILL Site site - A part of a TRILL campus that contains at least one
RBridge.

VLAN - Virtual Local Area Network. Network

VPLS - Virtual Private LAN Service

VPTS - Virtual Private TRILL Service

VSI - Virtual Service Instance [RFC4664]

VTSD - Virtual TRILL Switch Domain OR Virtual TRILL Service
Domain. A Virtual RBridge that segregates one tenant's
TRILL database as well as traffic from the other.

WAN - Wide Area Network

INTERNET-DRAFT TRILL Transparent Transport over MPLS

2. TRILL Over MPLS TRILL-over-MPLS Model

TRILL Over over MPLS can be achieved in two different ways. ways:
a) the VPLS Model for TRILL b) the VPTS Model/TIR Model / TIR Model for
TRILL

Both these models can be used to solve problem statements 1 and 2.
Herein
Herein, the VPLS Model for TRILL is also called Model 1 "Model 1" and the
VPTS
Model/TIR Model / TIR Model is also called Model 2.

INTERNET-DRAFT TRILL Transparent Transport over MPLS "Model 2".

3. VPLS Model

Figure 1 shows the topological model of TRILL over MPLS using the
VPLS model. The PE routers in the below topology model should
support all the functional Components components mentioned in [RFC4664].

+-----+ +-----+
| RBa +---+ ........................... +---| RBb |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+----|PE1 | |PE2 |----+
+----+ MPLS Cloud +----+
. .
. +----+ .
..........|PE3 |...........
+----+ ^
| |
| +-- Emulated LAN
+-----+
| RBc |
+-----+
Site 3

Figure 1. 1: Topological Model of TRILL over MPLS
connecting three
Connecting 3 TRILL Sites

Figure 2 below shows the topological model of TRILL over MPLS to
connect multiple TRILL sites belonging to a tenant. (Tenant ("Tenant" here
is a TRILL campus, not a specific Data label.) Label.) VSI1 and VSI2 are two
Virtual Service Instances that segregate Tenant1's traffic from other
tenant traffic. VSI1 will maintain its own database for Tenant1,
similarly Tenant1;
similarly, VSI2 will maintain its own database for Tenant2.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

+-----+ ............................ +-----+
|RBat1+---+ . ++++++++++++++++++++++++ . +---|RBbt1|
+-----+ | . + + . | +-----+
Tenant1 | +----+ +----+ | Tenant1
Site 1 +----|VSI1| |VSI1|----+ Site 2
+----|VSI2| MPLS Cloud |VSI2|----+
| +----+ +----+ |
+-----+ | . + + . | +-----+
|RBat2+---+ . +++++++++ +----+ ++++++++ . +---|RBbt2|
+-----+ ............|VSI1|........... +-----+
Tenant2 |VSI2| ^ Tenant2
Site 1 +----+ | Site 2
| |
+-----+ +-----Emulated
|RBct2| LAN
+-----+
Tenant2 Site 3

.... VSI1 Path
++++ VSI2 Path

Figure 2. 2: Topological Model for VPLS Model
connecting
Connecting 2 Tenants with 3 sites each Sites Each

In this model, TRILL sites are connected to VPLS-capable PE devices
that provide a logical interconnect, such that TRILL RBridges
belonging to a specific tenant are connected via an a single bridged
Ethernet. These PE devices are the same as the PE devices specified
in [RFC4026]. The Attachment Circuit ports of PE Routers routers are layer Layer 2
switch ports that are connected to the RBridges at a TRILL site. Here
Here, each VPLS instance looks like an emulated LAN. This model is
similar to connecting different RBridges by a layer Layer 2 bridge domain (multi
access
(multi-access link) as specified in [RFC6325]. This model doesn't
requires any changes in PE routers to carry TRILL packets, as TRILL
packets will be transferred transparently.

3.1

3.1. Entities in the VPLS Model

The PE (VPLS-PE) and CE Customer Edge (CE) devices are defined in
[RFC4026].

The Generic generic L2VPN Transport Functional Components transport functional components like Attachment
Circuits, Pseudowires, VSI etc. pseudowires, VSI, etc., are defined in [RFC4664].

The RB (RBridge) and TRILL Sites campus are defined in [RFC6325] as updated
by [RFC7780].

INTERNET-DRAFT TRILL Transparent Transport over MPLS

3.2

3.2. TRILL Adjacency for VPLS model

As specified in section 3 of this document, Model

As specified in Section 3, the MPLS cloud looks like an emulated LAN
(also called multi-access link or broadcast link). This results in
RBridges at different sites looking like they are connected by a
multi-access link. With such interconnection, the TRILL adjacencies
over the link are automatically discovered and established through
TRILL IS-IS control messages [RFC7177]. These IS-
IS IS-IS control messages
are transparently forwarded by the VPLS domain, after doing MPLS
encapsulation as specified in the section 3.4.

3.3 Section 3.3.

3.3. MPLS encapsulation Encapsulation for VPLS model Model

Use of VPLS [RFC4762] [RFC4761] to interconnect TRILL sites requires
no changes to a VPLS implementation, implementation -- in particular particular, the use of
Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal
Ethernet frames from an RBridge (i.e., CE) and is not aware that the
CE is an RBridge device. As an example, an MPLS-encapsulated TRILL
packet within the MPLS network can use the format illustrated in
Appendix A of [RFC7173] for the non-PBB case. For the PBB case,
additional header fields illustrated in [RFC7041] can be added by the
entry PE and removed by the exit PE.

3.4 Loop Free provider

3.4. Loop-Free Provider PSN/MPLS

No explicit handling is required to avoid loop free a loop-free topology. Split
Horizon The
"split horizon" technique specified in [RFC4664] will take care of
avoiding loops in the provider PSN network.

3.5

3.5. Frame Processing

The PE devices transparently process the TRILL control and data
frames. Procedures to forward the frames are defined in [RFC4664].

INTERNET-DRAFT TRILL Transparent Transport over MPLS

4. VPTS Model

The VPTS (Virtual Virtual Private TRILL Service) Service (VPTS) is a L2 Layer 2 TRILL service, service
that emulates TRILL service across a Wide Area Network (WAN). VPTS
is similar to what VPLS does for bridge a bridged core but provides a TRILL
core. VPLS provides "Virtual Private LAN Service" for different
customers. VPTS provides "Virtual Private TRILL Service" for
different TRILL tenants.

Figure 3 shows the topological model of TRILL over MPLS using VPTS.
In this model model, the PE routers are replaced with TIR (TRILL TRILL Intermediate Router)
Routers (TIRs), and VSI is the VSIs are replaced with VTSD (Virtual Virtual TRILL Switch Domain).
Domains (VTSDs). The TIR devices must be capable of supporting both
MPLS and TRILL as specified in section Section 4.1.1. The TIR devices are
interconnected via PWs and appear as a unified emulated TRILL campus
with each VTSD inside a TIR equivalent to a an RBridge.

Some

Below are some of the reasons for interconnecting TRILL Sites sites without
isolating the TRILL Control control plane of one TRILL site from other sites are as
described below. sites.

1) Nickname Uniqueness: uniqueness: One of the basic requirements of TRILL is
that,
that RBridge Nicknames nicknames are unique within the campus [RFC6325]. If
we segregate the control plane of one TRILL site from other TRILL site
sites and provide interconnection between these sites, it may
result in
Nickname nickname collision.

2) Distribution Trees trees and their pruning: When a TRILL Data packet
traverses a Distribution Tree, it will stay on it even in other
TRILL sites. If no end-station service is enabled for a
particular Data Label in a TRILL site, the Distribution Tree distribution tree may
be pruned and TRILL data packets of that particular Data Label
might never get to another TRILL site where the pckets packets had no
receivers. The TRILL RPF Reverse Path Forwarding (RPF) check will
always be performed on the packets that are received by TIRs
through pseudowires.

3) Hop Count count values: When a TRILL data packet is received over a
pseudowire by a TIR, the TIR does the processing of Hop Count
defined in [RFC6325] and will not perform any resetting of Hop
Count.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

+-----+ +-----+
| RBa +---+ ........................... +---| RBb |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+----|TIR1| |TIR2|----+
+----+ MPLS Cloud +----+
. .
. +----+ .
..........|TIR3|...........
+----+ ^
| |
| +-- Emulated TRILL
+-----+
| RBc |
+-----+
Site 3

Figure 3. 3: Topological Model of VPTS/TIR
connecting three Connecting 3 TRILL Sites
In the above Figure 3, Site1, Site2 Site 1, Site 2, and Site3 Site 3 (running the TRILL protocol)
are connected to TIR Devices. devices. These TIR devices, along with the MPLS
cloud, look like an a unified emulated TRILL network. Only the PE
devices in the MPLS network should be replaced with TIRs so the
intermediate Provider provider routers are agnostic to the TRILL protocol.

Figure 4 below extends the topological model of TRILL over MPLS to
connect multiple TRILL sites belonging to a tenant (tenant ("tenant" here is
a campus, not a Data label) Label) using the VPTS model. VTSD1 and VTSD2
are two Virtual TRILL Switch Domains (Virtual RBridges) that
segregate Tenant1's traffic from Tenant2's traffic. VTSD1 will
maintain its own TRILL database for Tenant1. Similarly Tenant1; similarly, VTSD2 will
maintain its own TRILL database for Tenant2.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

+-----+ ............................ +-----+
|RBat1+---+ . ######################## . +---|RBbt1|
+-----+ | . # # . | +-----+
Tenant1 | +-----+ +-----+ | Tenant1
Site 1 +----|VTSD1| |VTSD1|----+ Site 2
+----|VTSD2| MPLS Cloud |VTSD2|----+
| +-----+ +-----+ |
+-----+ | . # # . | +-----+
|RBat2+---+ . #########+-----+######### . +---|RBbt2|
+-----+ ...........|VTSD1|........... +-----+
Tenant2 |VTSD2| ^ Tenant2
Site 1 +-----+ | Site 2
| |
+-----+ +-----Emulated
|RBct2| TRILL
+-----+
Tenant2 Site 3

.... VTSD1 Connectivity
#### VTSD2 Connectivity

Figure 4. 4: Topological Model of VPTS/TIR
connecting
Connecting 2 tenants Tenants with three 3 TRILL Sites

4.1

4.1. Entities in the VPTS Model

The CE devices are defined in [RFC4026].

The Generic generic L2VPN Transport Functional Components transport functional components like Attachment
Circuits, Pseudowires etc. pseudowires, etc., are defined in [RFC4664].

The RB (RBridge) and TRILL Campus campus are defined in [RFC6325] as updated
by [RFC7780].

This model introduces two new entities called entities, TIR and VTSD that VTSD, which are
described below.

4.1.1

4.1.1. TRILL Intermediate Routers Router (TIR)

The TIRs (TRILL Intermediate Routers) must be capable of running both VPLS and TRILL protocols.
TIR devices are a superset of the VPLS-PE devices defined in
[RFC4026] with the additional functionality of TRILL. The VSI instance that
provides transparent bridging functionality in the PE device is
replaced with VTSD in a TIR.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

4.1.2

4.1.2. Virtual TRILL Switch/Service Domain (VTSD)

The VTSD (Virtual Trill Switch Domain) is similar to the VSI (layer (Layer 2 bridge) in the VPLS model,
but the VTSD acts as a TRILL RBridge. The VTSD is a superset of the
VSI and must support all the functionality provided by the VSI as
defined in [RFC4026]. Along with VSI functionality, the VTSD must be
capable of supporting TRILL protocols and forming TRILL adjacencies.
The VTSD must be capable of performing all the operations that a
standard TRILL Switch switch can do.

One VTSD instance per tenant must be maintained, maintained when multiple tenants
are connected to a TIR. The VTSD must maintain all the information maintained
kept by the RBridge on a per tenant per-tenant basis. The VTSD must also take
care of segregating one tenant tenant's traffic from other. another's. Each VTSD
will have its own nickname for each tenant, tenant. If a TIR supports 10
TRILL tenants, it needs to be assigned with ten 10 TRILL nicknames, one
for the nickname space of each of its tenants, and run
ten 10 copies of
TRILL protocols, one for each tenant. It is possible that it would
have the same nickname for two or more tenants tenants, but, since the TRILL
data and control traffic are separated for the tenants, there is no
confusion.

4.2

4.2. TRILL Adjacency for VPTS model Model

The VTSD must be capable of forming a TRILL adjacency with the
corresponding VTSDs present in its peer VPTS neighbor, neighbor and also with
the
neighbor neighboring RBridges present in of the TRILL sites. The procedure to form
TRILL Adjacency adjacency is specified in [RFC7173] and [RFC7177].

4.3

4.3. MPLS encapsulation Encapsulation for VPTS model Model

The VPTS model uses PPP or Ethernet pseudowires for MPLS
encapsulation as specified in [RFC7173], [RFC7173] and requires no changes in
the packet format in that RFC. In accordance with [RFC7173], the PPP
encapsulation is the default.

4.4 Loop Free provider

4.4. Loop-Free Provider PSN/MPLS

This model isn't required to employ Split Horizon the "split horizon" mechanism in
the provider PSN network, as TRILL takes care of Loop free loop-free topology
using
Distribution Trees. distribution trees. Any multi-destination packet will traverse
a distribution tree path. All distribution trees are calculated
based on the TRILL base protocol standard [RFC6325] as updated by
[RFC7780].

INTERNET-DRAFT TRILL Transparent Transport over MPLS

4.5. Frame Processing

This section specifies multi-destination and unicast frame processing
in the VPTS/TIR model.

4.5.1 Multi-Destination

4.5.1. Multi-destination Frame Processing

Any multi-destination (unknown unicast, multicast multicast, or broadcast, as
indicated by the multi-destination bit in the TRILL Header) header) packets
inside a VTSD will be processed or forwarded through the distribution
tree for which they were encapsulated on TRILL ingress. If any multi-
destination
multi-destination packet is received from the wrong pseudowire at a
VTSD, the TRILL protocol running in the VTSD will perform an RPF
check as specified in [RFC7780] and drop the packet.

The Pruning pruning mechanism in Distribution Trees, distribution trees, as specified in
[RFC6325] and [RFC7780], can also be used to avoid forwarding of
multi-destination data packets on the branches where there are no
potential destinations.

4.5.2

4.5.2. Unicast Frame Processing

Unicast packets are forwarded in the same way they get forwarded in a
standard TRILL Campus campus as specified in [RFC6325]. If multiple equal equal-
cost paths are available over pseudowires to reach the destination,
then VTSD should be capable of doing ECMP for them.

INTERNET-DRAFT TRILL Transparent Transport over MPLS those equal-cost paths.

5. VPTS Model Versus versus VPLS Model

The VPLS Model model uses a simpler loop-breaking rule: the "split horizon"
rule, where a PE must not forward traffic from one PW to another in
the same VPLS mesh, whereas mesh. In contrast, the VPTS Model model uses distribution Trees
trees for loop free loop-free topology. As this is an emulated TRILL service,
for interoperability purposes purposes, the VPTS model is the default.

6. Packet Processing Between between Pseudowires

Whenever a packet gets received over a pseudowire, a VTSD will
decapsulate the MPLS headers followed by checking then check the TRILL header. If the
egress nickname in the TRILL header is for a TRILL site located
beyond another pseudowire, then the VTSD will encapsulate the packet
with new MPLS headers and send it across the proper pseudowire.

For example example, in figure Figure 3, consider that the pseudowire between TIR1
and TIR2 fails, Then fails. Then, TIR1 will communicate with TIR2 via TIR3,
whenever TIR3.
Whenever packets which that are destined to TIR3 gets are received from the
pseudowire between TIR1 and TIR3, the VTSD inside TIR3 will
decapsulate the MPLS headers, then check the TRILL header's egress
nickname field. If the egress nickname indicate indicates it is destained destined for
the RBridge in site3 Site 3, then the packet will be sent to RBc, RBc; if the
egress nickname is located at site2, Site 2, VTSD will add MPLS headers for
the pseudowire between TIR3 and TIR2 and forward the packet on that
pseudowire.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

7. Efficiency Considerations

Since the VPTS Model model uses Distribution distribution trees for processing of multi-
destination data packets, it is always advisable to have at least one
Distribution
distribution tree root to be located in every TRILL site. This will
avoid
prevent data packets getting from being received at TRILL sites where end-station end-
station service is not enabled for that data packet.

8. Security Considerations

This document specifies methods using existing standards and
facilities in ways that do not create new security problems.

For general VPLS security considerations, including discussion of
isolating customers from each other, see [RFC4761] and [RFC4762].

For security considerations for transport of TRILL by Pseudowires security consideration, pseudowires,
see [RFC7173]. In particular, since pseudowires are support supported by
MPLS or IP IP, which are in turn supported by a link layer, that
document recommends using IP security, such as IPsec [RFC4301] or
DTLS [RFC6347], or the lower link layer link-layer security, such as MACSEC
[802.1AE] for Ethernet links.

Transmission outside the customer environment through the provider
environment, as described in this document, increases risk of
compromise or injection of false data through failure of tenant
isolation or by the provider. In the VPLS model (Section 3), the use
of link encryption and authentication between the CEs of a tenant
that is being connected through provider facilities should be a good
defense. In the VPTS model (Section 4), it is assumed that the CEs
will peer with virtual TRILL switches of the provider network network, and
thus link security between TRILL switch ports is inadequate as it
will terminate at the edge PE. Thus, encryption and authentication
from end station to end station
encryption and authentication is are more
appropriate for the VPTS model.

For added security against the compromise of data data, end-to-end
encryption and authentication should be considered; that is,
encryption and authentication from source end station to destination
end station. This would typically be provided by IPsec [RFC4301] or
DTLS [RFC6347] or other protocols convenient to protect the
information of concern.

For general TRILL security considerations, see [RFC6325].

INTERNET-DRAFT TRILL Transparent Transport over MPLS

9. IANA Considerations

This document requires has no IANA actions. RFC Editor: Please delete
this section before publication

INTERNET-DRAFT TRILL Transparent Transport over MPLS

10. Normative References

[IS-IS] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, 2002". 2002.

[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, <https://www.rfc-
editor.org/info/rfc4761>.
<https://www.rfc-editor.org/info/rfc4761>.

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<https://www.rfc-editor.org/info/rfc6325>.

[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson,
"Transparent Interconnection of Lots of Links (TRILL)
Transport Using Pseudowires", RFC 7173,
DOI 10.17487/RFC7173, May 2014,
<https://www.rfc-editor.org/info/rfc7173>.

[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
2014, <https://www.rfc-editor.org/info/rfc7177>.

[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

11. Informative References

[802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks-- Metropolitan Area
Networks: Media Access Control (MAC) Security.", 2006. Security", IEEE Std
802.1AE, DOI 10.1109/IEEESTD.2006.245590.

[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, <https://www.rfc-
editor.org/info/rfc4026>.
<https://www.rfc-editor.org/info/rfc4026>.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, <https://www.rfc-
editor.org/info/rfc4664>.
<https://www.rfc-editor.org/info/rfc4664>.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
"Extensions to the Virtual Private LAN Service (VPLS)
Provider Edge (PE) Model for Provider Backbone Bridging",
RFC 7041, DOI 10.17487/RFC7041, November 2013, <https://www.rfc-
editor.org/info/rfc7041>.
<https://www.rfc-editor.org/info/rfc7041>.

[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172,
DOI 10.17487/RFC7172, May 2014,
<https://www.rfc-editor.org/info/rfc7172>.

INTERNET-DRAFT TRILL Transparent Transport over MPLS

Acknowledgements

The contributions of Andrew G. Malis are gratefully acknowledged in
improving the quality of this document.

Authors' Addresses

Mohammed Umair
Cisco Systems
SEZ, Cessna Business Park
Sarjapur - Marathahalli Outer Ring road
Bengaluru - 560103, 560103
India

EMail:

Email: mohammed.umair2@gmail.com

S. Kingston Smiler Selvaraj
IPInfusion
RMZ Centennial
Mahadevapura Post
Bangalore
PALC NETWORKS PVT LTD
Envision Technology Center
#119, 1st Floor, Road No.3
EPIP Area Phase 1, Whitefield
Near Vydehi Hospital
Bengaluru - 560048 560066, Karnataka
India

EMail:

Email: kingstonsmiler@gmail.com

Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
United States of America

Phone: +1-508-333-2270
EMail:
Email: d3e3e3@gmail.com

Lucy Yong
Self
Independent

Phone: +1-469-227-5837
EMail:
Email: lucyyong@gmail.com

INTERNET-DRAFT TRILL Transparent Transport over MPLS

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.