Internet DRAFT - draft-balaji-trill-te-multi-site-interconnect
draft-balaji-trill-te-multi-site-interconnect
TRILL Working Group Balaji Venkat Venkataswami
INTERNET-DRAFT Bhargav Bhikkaji
Intended Status: Proposed Standard Narayana Perumal Swamy
Expires: September 2012 Dell-Force10
March 26, 2012
Interconnecting multiple TRILL sites deploying Traffic Engineering
draft-balaji-trill-te-multi-site-interconnect-00
Abstract
This document specifies the control plane procedures to support
Traffic Engineering (TE) across TRILL sites where such sites are
interconnected using [1] with the help of a Layer 3 core running
IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of
links that possess a certain characteristic like specified bandwidth,
cost or even MTU. This draft aims at addressing how unicast frames
travelling from one TRILL site to another across a Layer 3 core that
supports IP+GRE and/or IP+MPLS can make use of the TE calculated
paths in the sending site as well as the receiving site where such TE
paths are pre-computed in both sites and need a mechanism to inter-
link them together.
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
Balaji Venkat et.al Expires September 2012 [Page 1]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
Copyright and License Notice
Copyright (c) 2012 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
(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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Extensions in IS-IS and BGP . . . . . . . . . . . . . . . . 8
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Normative References . . . . . . . . . . . . . . . . . . . 9
5.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Balaji Venkat et.al Expires September 2012 [Page 2]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
1 Introduction
This document specifies the control plane procedures to support
Traffic Engineering (TE) across TRILL sites where such sites are
interconnected using [1] with the help of a Layer 3 core running
IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of
links that possess a certain characteristic like specified bandwidth,
cost or even MTU. This draft aims at addressing how unicast frames
travelling from one TRILL site to another across a Layer 3 core that
supports IP+GRE and/or IP+MPLS can make use of the TE calculated
paths in the sending site as well as the receiving site where such TE
paths are pre-computed in both sites and need a mechanism to inter-
link them together.
This draft merely enables the above through a Area number aliasing
mechanism. The mechanism to interconnect multiple TRILL sites and
also which provides multi-tenancy in the sense that multiple
customers of a Layer 3 core can make use of this proposal, is enabled
by [1].
1.1 Terminology
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 [RFC2119].
2. Methodology
Assume the following topology consisting of two sites belonging to
the same customer that are interconnected by a Layer 3 core network
running IP+GRE and/or IP+MPLS as defined in [1]. The two sites are
considered as IS-IS Level 1 areas having their own set of nicknames
which may be non-unique between the two sites. That is the same
nickname could be used in one site and the other or even a third or
more if the need arises. The sites are connected using the N-PEs
which are the border Rbridges that have one interface in the IS-IS
Level 1 area and another Pseudo-interface in the Level 2 area which
is actually Pseudo-Level-2 which in fact is the Layer 3 core
interconnecting the two.
Balaji Venkat et.al Expires September 2012 [Page 3]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
____[U-PE]____ ____________ ____[U-PE]____
( ) ( ) ( )
( TRILL Based ) ( IP Core with ) ( TRILL Based )
( RBridges as U-PEs) ( IP+GRE Encap ) ( RBridges as U-PEs)
[U-PEs]RBridges as [N-PE] or IP+MPLS [N-PE] RBridges as [U-PE]
( U-Ps ) ( Encap Tunnels ) ( U-Ps )
( ) ( between N-PEs) ( )
(___[U-PE]_____) (____________) (____[U-PE]____)
Figure 1.0 : Proposed Architecture
Legend :
U-PE : User-near PE device. U-PEs are edge devices in the Customer
site or tier-2 site. This is a Rbridge with BGP capabilities. It has
VRF instances for each tenant it is connected to in the case of
Provider-Backbone functionality use-case.
U-Ps : core devices in the Customer site that do not directly
interact with the Customer's Customer.
N-PE : Network Transport PE device. This is a device with RBridge
capabilities in the non-core facing side. On the core facing side it
is a Layer 3 device supporting IP+GRE and/or IP+MPLS. On the non-core
facing side it has support for VRFs one for each TRILL site that it
connects to. It runs BGP to convey the BGP-MAC-VPN VRF routes to its
peer N-PEs. It also supports IGP on the core facing side like OSPF or
IS-IS for Layer 3 and supports IP+GRE and/or IP+MPLS if need be. A
pseudo-interface representing the N-PE's connection to the Pseudo
Level 2 area is provided at each N-PE and a forwarding adjacency is
maintained between the near-end N-PE to its remote participating N-
PEs pseudo-interface in the common Pseudo Level 2 area.
N-P : Network Transport core device. This device is IP and/or
IP+MPLS core device that is part of the ISP / ISPs that provide the
transport network that connect the disparate TRILL networks together.
As defined in [3] these separate sites are assigned unique area
numbers so that the sites can be connected using multi-level IS-IS
like configuration as specified in [1].
Here the MAC-routes and their corresponding Area number nicknames are
placed in VRFs and using the BGP-MAC-VPN vrf methodology the sites
are interconnected using BGP. BGP serves as the protocol that
distributes the MAC-routes from one site to another. Specific Route
Distinguishers (which are a capability of BGP based IP or MPLS VPNs)
are used to assign uniqueness to the MAC-routes from amongst the
sites. Route targets are used to export and import these routes in
Balaji Venkat et.al Expires September 2012 [Page 4]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
and out of the N-PEs that interconnect these TRILL sites.
Here we advocate the use of a range Area number nicknames to be
assigned to each site of a customer. Each Area number other than the
default Area number which is used for non-TE based frames (both
unicast and multicast), is assigned a significance for a specific
pre-computed TE path within each site. We will call these Area
numbers (other than the default Area number assigned for non-TE
frames) as Site-TE-nicknames. These Site-TE-nicknames are distinct
and unique for the set of customer sites interconnected by the Layer
3 core.j
Each of these Site-TE-nicknames represent a path computed on the
basis of say a bandwidth, cost or MTU constraint. One could compute a
path based on bandwidth that indicates that all the links in that TE-
Path (represented by the Site-TE-nickname in that site) can carry
traffic upto 10GB worth of traffic. Or the TE-Path computed may be
based on cost indicating say that all the links in the TE-path have a
cost over a threshold "X". Or the TE-path could be based on the fact
that all the links in that path have a MTU over and above a threshold
"M" or equal to "M". Combined constraints can also be used where
bandwidth and MTU are to be considered.
So we assign specific Path Characteristics to a TE-Path and assign a
Site-TE-nickname to it. Also the TE-nicknames for each TE-Path are
assigned on each Rbridge and percolated / flooded within that site.
The Site-TE-nicknames are then carried with Path Characteristic TLVs
(to be defined for this purpose) through IS-IS in the site and
advertised into BGP at the N-PE connecting the site to the Layer 3
core. The N-PE then uses a MP-BGP session to advertise these Site-TE-
nicknames and the Path Characteristics in suitable format to other N-
PEs across the Layer 3 core.
On the receiving N-PE the information is re-distributed into IS-IS
TLVs and the Site-TE-nicknames reach all the Rbridges within the
receiving site.
The reachability information in a Rbridge within the TE-Path based
unicast frame sending site would be that the destination exists in
another site whose Site-TE-nickname is reachable through the near end
N-PE. A TE-Path within the local / sending site would have been
computed based on bandwidth , cost or MTU or combination of these
would have been constructed to the N-PE if such links possessing the
characteristics exist.
Now an Ingress Rbridge can use its local Site-TE-nickname (for that
TE-Path to the N-PE) if such a TE-Path the meets the constraints is
available, as a Egress Nickname in the TRILL header to get a frame to
Balaji Venkat et.al Expires September 2012 [Page 5]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
flow through its site through the locally available TE-Path and reach
the connected N-PE within the site. At the N-PE the TRILL header is
decapsulated and the Egress Nickname of the incoming frame looked up
for equivalent path characteristics in the set of Site-TE-nicknames
of the site where the MAC-route says the target host exists. If a
match occurs then the local N-PE puts in the suitable Egress Nickname
as that Site-TE-nickname and sends the packet with the TRILL header
across to the remote site.
At the receiving site the Egress Rbridge Nickname in the TRILL header
is inspected and the appropriate TE-Path from the receiving N-PE
(remote site N-PE) to the Egress Rbridge terminating the TE-Path
represented by the Site-TE-nickname is used to carry the unicast
frame to its destination.
If no match exists for the path characteristics then the
decapsulation still takes place and the normal discarding of the
TRILL header over the L3 core as specified in [1] is done and the
frame sent across to the other side. At the receiving end one of the
existing normal paths (other than the TE-Paths) is used to get the
packet to the target host.
If the sending site does not have a TE-Path to its local N-PE that
meets the constraints then it would choose to send the unicast frame
through normal means as in [1].
In the figure below we demonstrate how the data path is taken from
sender to receiver assuming the sender is in one site and receiver in
other.
In the following picture, RB2 and RB3 are area border RBridges. A
source S is attached to RB1. The two areas have nicknames 15961 and
15918, respectively. RB1 has a nickname, say 27, and RB4 has a
nickname, say 44 (and in fact, they could even have the same
nickname, since the RBridge nickname will not be visible outside the
area).
Balaji Venkat et.al Expires September 2012 [Page 6]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
Pseudo
Default Area 15961 level 2 Default Area 15918
|
TE-Path with MTU 9K V TE-Path with MTU 9K
TE-Site-nickname 15962 TE-Site-Nickname 15919
+-------------------+ +-----------------+ +--------------+
| TE-Path 15962 | | IP Core network | |TE-Path 15919 |
| S--RB1---Rx--Rz----RB2--- ----RB3---Rk--RB4---D |
| 27 | | . . | | 44 |
| | |Pseudo-Interface | | |
+-------------------+ +-----------------+ +--------------+
Here RB2 and RB3 are N-PEs. RB4 and RB1 are U-PEs.
This sample topology could apply to Campus and data-center
topologies. For Provider Backbone topologies S would fall outside the
Area 15961 and RB1 would be the U-PE carrying the C-VLANs inside a P-
VLAN for a specific customer.
Let's say that S transmits a frame to destination D, which is
connected to RB4, and let's say that D's location is learned by the
relevant RBridges already. The relevant RBridges have learned the
following:
1) RB1 has learned that D is connected to nickname 15918
and through remote TE-Site-Nickname 15919 with MTU 9K and
through local N-PE RB2. and through local TE-Site-Nickname
15962 with MTU 9K through RB2.
2) RB3 has learned that D is attached to nickname 44.
and through TE-Site-Nickname 15919 with MTU 9K
The following sequence of events will occur:
- S transmits an Ethernet frame with source MAC = S and destination
MAC = D.
- RB1 encapsulates with a TRILL header with ingress RBridge = 27,
and egress = 15962.
- RB2 has announced in the Level 1 IS-IS instance in area 15961,
that it is attached to all the area nicknames, including 15918 and
15919 which is just an TE-Alias for 15918. Therefore, IS-IS routes
the frame to RB2. (Alternatively, if a distinguished range of
nicknames is used for Level 2, Level 1 RBridges seeing such an egress
nickname will know to route to the nearest border router, which can
be indicated by the IS-IS attached bit.)
- RB2, when transitioning the frame from Level 1 to Level 2,
Balaji Venkat et.al Expires September 2012 [Page 7]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
replaces the ingress RBridge nickname with the area nickname, so
replaces 27 with 15962. Within Level 2, the ingress RBridge field in
the TRILL header will therefore be 15962, and the egress RBridge
field will be 15919 after the path characteristics matching and the
choice of 15919 as the Egress Rbridge satisfying the said constraints
for the TE-Path in 15919. Also RB2 learns that S is attached to
nickname 27 in area 15962 to accommodate return traffic. This is thus
a bi-directional TE-Path that satisfies the constraints chosen by the
Ingress Rbridge RB1.
- The frame is forwarded through Level 2, to RB3, which has
advertised, in Level 2, reachability to the nickname 15918 and 15919.
- RB3, when forwarding into area 15918, keeps the egress nickname in
the TRILL header as 15919 nickname which is the TE-Path to RB4 whose
actual nickname is 44. So, within the destination area, the ingress
nickname will be 15962 and the egress nickname will be 15919.
- RB4, when decapsulating, learns that S is attached to nickname
15962, which is the TE-Path Site-TE-nickname of the ingress.
Now suppose that D's location has not been learned by RB1 and/or RB3.
What will happen, as it would in TRILL today, is that RB1 will
forward the frame as a multi-destination frame, choosing a tree. As
the multi-destination frame transitions into Level 2, RB2 replaces
the ingress nickname with the default area nickname. If RB1 does not
know the location of D, the frame must be flooded, subject to
possible pruning, in Level 2 and, subject to possible pruning, from
Level 2 into every Level 1 area that it reaches on the Level 2
distribution tree which is the MVPN PIM-bidir tree as in [1].
2.1 Extensions in IS-IS and BGP
The TLVs in IS-IS to be added and the BGP extensions will be dealt
with in more detail in later versions of this draft. The other TLVs
that support creation of TE-Paths as in [7] will remain as is.
Balaji Venkat et.al Expires September 2012 [Page 8]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
3 Security Considerations
TBD.
4 IANA Considerations
Suitable IANA requests will be detailed in upcoming versions of the
draft.
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
5.2 Informative References
[1] draft-balaji-trill-over-ip-multi-level-04.txt,
Bhargav Bhikkaji et.al, March 2012, Work in Progress
[2] draft-xl-trill-over-wan-00.txt, XiaoLan. Wan et.al
December 11th ,2011 Work in Progress
[3] draft-perlman-trill-rbridge-multilevel-03.txt, Radia
Perlman et.al October 31, 2011 Work in Progress
[4] draft-raggarwa-mac-vpn-01.txt, Rahul Aggarwal et.al,
June 2010, Work in Progress.
[5] draft-yong-trill-trill-o-mpls, Yong et.al, October
2011, Work in Progress.
[6] draft-raggarwa-sajassi-l2vpn-evpn Rahul Aggarwal
et.al, September 2011, Work in Progress.
[7] draft-hu-trill-traffic-engineering-00.txt Fanwei Hu
et.al, January 11 2012, Work in Progress.
Balaji Venkat et.al Expires September 2012 [Page 9]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
Authors' Addresses
Balaji Venkat Venkataswami,
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
TamilNadu, India.
Tel: +91 (0) 44 4220 8400
Fax: +91 (0) 44 2836 2446
EMail: BALAJI_VENKAT_VENKAT@dell.com
Bhargav Bhikkaji,
Dell-Force10,
350 Holger Way,
San Jose, CA
U.S.A
Email: Bhargav_Bhikkaji@dell.com
Narayana Perumal Swamy,
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
TamilNadu, India.
Tel: +91 (0) 44 4220 8400
Fax: +91 (0) 44 2836 2446
Balaji Venkat et.al Expires September 2012 [Page 10]
INTERNET DRAFT Interconnecting TRILL sites deploying TE March 2012
Email: Narayana_Perumal@dell.com
Balaji Venkat et.al Expires September 2012 [Page 11]
