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]