idnits 2.17.1 draft-balaji-trill-te-multi-site-interconnect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 26, 2012) is 4413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 99, but not defined == Missing Reference: 'U-PEs' is mentioned on line 118, but not defined == Missing Reference: 'N-PE' is mentioned on line 118, but not defined == Missing Reference: 'U-PE' is mentioned on line 118, but not defined == Unused Reference: 'KEYWORDS' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 351, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 359, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 365, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 368, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 383, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1776 ** Downref: Normative reference to an Informational RFC: RFC 1925 (ref. 'TRUTHS') == Outdated reference: A later version (-05) exists of draft-balaji-trill-over-ip-multi-level-04 == Outdated reference: A later version (-01) exists of draft-xl-trill-over-wan-00 == Outdated reference: A later version (-10) exists of draft-perlman-trill-rbridge-multilevel-03 == Outdated reference: A later version (-01) exists of draft-hu-trill-traffic-engineering-00 Summary: 3 errors (**), 0 flaws (~~), 20 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Balaji Venkat Venkataswami 3 INTERNET-DRAFT Bhargav Bhikkaji 4 Intended Status: Proposed Standard Narayana Perumal Swamy 5 Expires: September 2012 Dell-Force10 6 March 26, 2012 8 Interconnecting multiple TRILL sites deploying Traffic Engineering 9 draft-balaji-trill-te-multi-site-interconnect-00 11 Abstract 13 This document specifies the control plane procedures to support 14 Traffic Engineering (TE) across TRILL sites where such sites are 15 interconnected using [1] with the help of a Layer 3 core running 16 IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of 17 links that possess a certain characteristic like specified bandwidth, 18 cost or even MTU. This draft aims at addressing how unicast frames 19 travelling from one TRILL site to another across a Layer 3 core that 20 supports IP+GRE and/or IP+MPLS can make use of the TE calculated 21 paths in the sending site as well as the receiving site where such TE 22 paths are pre-computed in both sites and need a mechanism to inter- 23 link them together. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1 Extensions in IS-IS and BGP . . . . . . . . . . . . . . . . 8 67 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 68 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 69 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 71 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1 Introduction 76 This document specifies the control plane procedures to support 77 Traffic Engineering (TE) across TRILL sites where such sites are 78 interconnected using [1] with the help of a Layer 3 core running 79 IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of 80 links that possess a certain characteristic like specified bandwidth, 81 cost or even MTU. This draft aims at addressing how unicast frames 82 travelling from one TRILL site to another across a Layer 3 core that 83 supports IP+GRE and/or IP+MPLS can make use of the TE calculated 84 paths in the sending site as well as the receiving site where such TE 85 paths are pre-computed in both sites and need a mechanism to inter- 86 link them together. 88 This draft merely enables the above through a Area number aliasing 89 mechanism. The mechanism to interconnect multiple TRILL sites and 90 also which provides multi-tenancy in the sense that multiple 91 customers of a Layer 3 core can make use of this proposal, is enabled 92 by [1]. 94 1.1 Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Methodology 102 Assume the following topology consisting of two sites belonging to 103 the same customer that are interconnected by a Layer 3 core network 104 running IP+GRE and/or IP+MPLS as defined in [1]. The two sites are 105 considered as IS-IS Level 1 areas having their own set of nicknames 106 which may be non-unique between the two sites. That is the same 107 nickname could be used in one site and the other or even a third or 108 more if the need arises. The sites are connected using the N-PEs 109 which are the border Rbridges that have one interface in the IS-IS 110 Level 1 area and another Pseudo-interface in the Level 2 area which 111 is actually Pseudo-Level-2 which in fact is the Layer 3 core 112 interconnecting the two. 114 ____[U-PE]____ ____________ ____[U-PE]____ 115 ( ) ( ) ( ) 116 ( TRILL Based ) ( IP Core with ) ( TRILL Based ) 117 ( RBridges as U-PEs) ( IP+GRE Encap ) ( RBridges as U-PEs) 118 [U-PEs]RBridges as [N-PE] or IP+MPLS [N-PE] RBridges as [U-PE] 119 ( U-Ps ) ( Encap Tunnels ) ( U-Ps ) 120 ( ) ( between N-PEs) ( ) 121 (___[U-PE]_____) (____________) (____[U-PE]____) 123 Figure 1.0 : Proposed Architecture 125 Legend : 127 U-PE : User-near PE device. U-PEs are edge devices in the Customer 128 site or tier-2 site. This is a Rbridge with BGP capabilities. It has 129 VRF instances for each tenant it is connected to in the case of 130 Provider-Backbone functionality use-case. 132 U-Ps : core devices in the Customer site that do not directly 133 interact with the Customer's Customer. 135 N-PE : Network Transport PE device. This is a device with RBridge 136 capabilities in the non-core facing side. On the core facing side it 137 is a Layer 3 device supporting IP+GRE and/or IP+MPLS. On the non-core 138 facing side it has support for VRFs one for each TRILL site that it 139 connects to. It runs BGP to convey the BGP-MAC-VPN VRF routes to its 140 peer N-PEs. It also supports IGP on the core facing side like OSPF or 141 IS-IS for Layer 3 and supports IP+GRE and/or IP+MPLS if need be. A 142 pseudo-interface representing the N-PE's connection to the Pseudo 143 Level 2 area is provided at each N-PE and a forwarding adjacency is 144 maintained between the near-end N-PE to its remote participating N- 145 PEs pseudo-interface in the common Pseudo Level 2 area. 147 N-P : Network Transport core device. This device is IP and/or 148 IP+MPLS core device that is part of the ISP / ISPs that provide the 149 transport network that connect the disparate TRILL networks together. 151 As defined in [3] these separate sites are assigned unique area 152 numbers so that the sites can be connected using multi-level IS-IS 153 like configuration as specified in [1]. 155 Here the MAC-routes and their corresponding Area number nicknames are 156 placed in VRFs and using the BGP-MAC-VPN vrf methodology the sites 157 are interconnected using BGP. BGP serves as the protocol that 158 distributes the MAC-routes from one site to another. Specific Route 159 Distinguishers (which are a capability of BGP based IP or MPLS VPNs) 160 are used to assign uniqueness to the MAC-routes from amongst the 161 sites. Route targets are used to export and import these routes in 162 and out of the N-PEs that interconnect these TRILL sites. 164 Here we advocate the use of a range Area number nicknames to be 165 assigned to each site of a customer. Each Area number other than the 166 default Area number which is used for non-TE based frames (both 167 unicast and multicast), is assigned a significance for a specific 168 pre-computed TE path within each site. We will call these Area 169 numbers (other than the default Area number assigned for non-TE 170 frames) as Site-TE-nicknames. These Site-TE-nicknames are distinct 171 and unique for the set of customer sites interconnected by the Layer 172 3 core.j 174 Each of these Site-TE-nicknames represent a path computed on the 175 basis of say a bandwidth, cost or MTU constraint. One could compute a 176 path based on bandwidth that indicates that all the links in that TE- 177 Path (represented by the Site-TE-nickname in that site) can carry 178 traffic upto 10GB worth of traffic. Or the TE-Path computed may be 179 based on cost indicating say that all the links in the TE-path have a 180 cost over a threshold "X". Or the TE-path could be based on the fact 181 that all the links in that path have a MTU over and above a threshold 182 "M" or equal to "M". Combined constraints can also be used where 183 bandwidth and MTU are to be considered. 185 So we assign specific Path Characteristics to a TE-Path and assign a 186 Site-TE-nickname to it. Also the TE-nicknames for each TE-Path are 187 assigned on each Rbridge and percolated / flooded within that site. 188 The Site-TE-nicknames are then carried with Path Characteristic TLVs 189 (to be defined for this purpose) through IS-IS in the site and 190 advertised into BGP at the N-PE connecting the site to the Layer 3 191 core. The N-PE then uses a MP-BGP session to advertise these Site-TE- 192 nicknames and the Path Characteristics in suitable format to other N- 193 PEs across the Layer 3 core. 195 On the receiving N-PE the information is re-distributed into IS-IS 196 TLVs and the Site-TE-nicknames reach all the Rbridges within the 197 receiving site. 199 The reachability information in a Rbridge within the TE-Path based 200 unicast frame sending site would be that the destination exists in 201 another site whose Site-TE-nickname is reachable through the near end 202 N-PE. A TE-Path within the local / sending site would have been 203 computed based on bandwidth , cost or MTU or combination of these 204 would have been constructed to the N-PE if such links possessing the 205 characteristics exist. 207 Now an Ingress Rbridge can use its local Site-TE-nickname (for that 208 TE-Path to the N-PE) if such a TE-Path the meets the constraints is 209 available, as a Egress Nickname in the TRILL header to get a frame to 210 flow through its site through the locally available TE-Path and reach 211 the connected N-PE within the site. At the N-PE the TRILL header is 212 decapsulated and the Egress Nickname of the incoming frame looked up 213 for equivalent path characteristics in the set of Site-TE-nicknames 214 of the site where the MAC-route says the target host exists. If a 215 match occurs then the local N-PE puts in the suitable Egress Nickname 216 as that Site-TE-nickname and sends the packet with the TRILL header 217 across to the remote site. 219 At the receiving site the Egress Rbridge Nickname in the TRILL header 220 is inspected and the appropriate TE-Path from the receiving N-PE 221 (remote site N-PE) to the Egress Rbridge terminating the TE-Path 222 represented by the Site-TE-nickname is used to carry the unicast 223 frame to its destination. 225 If no match exists for the path characteristics then the 226 decapsulation still takes place and the normal discarding of the 227 TRILL header over the L3 core as specified in [1] is done and the 228 frame sent across to the other side. At the receiving end one of the 229 existing normal paths (other than the TE-Paths) is used to get the 230 packet to the target host. 232 If the sending site does not have a TE-Path to its local N-PE that 233 meets the constraints then it would choose to send the unicast frame 234 through normal means as in [1]. 236 In the figure below we demonstrate how the data path is taken from 237 sender to receiver assuming the sender is in one site and receiver in 238 other. 240 In the following picture, RB2 and RB3 are area border RBridges. A 241 source S is attached to RB1. The two areas have nicknames 15961 and 242 15918, respectively. RB1 has a nickname, say 27, and RB4 has a 243 nickname, say 44 (and in fact, they could even have the same 244 nickname, since the RBridge nickname will not be visible outside the 245 area). 247 Pseudo 248 Default Area 15961 level 2 Default Area 15918 249 | 250 TE-Path with MTU 9K V TE-Path with MTU 9K 251 TE-Site-nickname 15962 TE-Site-Nickname 15919 252 +-------------------+ +-----------------+ +--------------+ 253 | TE-Path 15962 | | IP Core network | |TE-Path 15919 | 254 | S--RB1---Rx--Rz----RB2--- ----RB3---Rk--RB4---D | 255 | 27 | | . . | | 44 | 256 | | |Pseudo-Interface | | | 257 +-------------------+ +-----------------+ +--------------+ 259 Here RB2 and RB3 are N-PEs. RB4 and RB1 are U-PEs. 261 This sample topology could apply to Campus and data-center 262 topologies. For Provider Backbone topologies S would fall outside the 263 Area 15961 and RB1 would be the U-PE carrying the C-VLANs inside a P- 264 VLAN for a specific customer. 266 Let's say that S transmits a frame to destination D, which is 267 connected to RB4, and let's say that D's location is learned by the 268 relevant RBridges already. The relevant RBridges have learned the 269 following: 271 1) RB1 has learned that D is connected to nickname 15918 272 and through remote TE-Site-Nickname 15919 with MTU 9K and 273 through local N-PE RB2. and through local TE-Site-Nickname 274 15962 with MTU 9K through RB2. 275 2) RB3 has learned that D is attached to nickname 44. 276 and through TE-Site-Nickname 15919 with MTU 9K 278 The following sequence of events will occur: 280 - S transmits an Ethernet frame with source MAC = S and destination 281 MAC = D. 283 - RB1 encapsulates with a TRILL header with ingress RBridge = 27, 284 and egress = 15962. 286 - RB2 has announced in the Level 1 IS-IS instance in area 15961, 287 that it is attached to all the area nicknames, including 15918 and 288 15919 which is just an TE-Alias for 15918. Therefore, IS-IS routes 289 the frame to RB2. (Alternatively, if a distinguished range of 290 nicknames is used for Level 2, Level 1 RBridges seeing such an egress 291 nickname will know to route to the nearest border router, which can 292 be indicated by the IS-IS attached bit.) 294 - RB2, when transitioning the frame from Level 1 to Level 2, 295 replaces the ingress RBridge nickname with the area nickname, so 296 replaces 27 with 15962. Within Level 2, the ingress RBridge field in 297 the TRILL header will therefore be 15962, and the egress RBridge 298 field will be 15919 after the path characteristics matching and the 299 choice of 15919 as the Egress Rbridge satisfying the said constraints 300 for the TE-Path in 15919. Also RB2 learns that S is attached to 301 nickname 27 in area 15962 to accommodate return traffic. This is thus 302 a bi-directional TE-Path that satisfies the constraints chosen by the 303 Ingress Rbridge RB1. 305 - The frame is forwarded through Level 2, to RB3, which has 306 advertised, in Level 2, reachability to the nickname 15918 and 15919. 308 - RB3, when forwarding into area 15918, keeps the egress nickname in 309 the TRILL header as 15919 nickname which is the TE-Path to RB4 whose 310 actual nickname is 44. So, within the destination area, the ingress 311 nickname will be 15962 and the egress nickname will be 15919. 313 - RB4, when decapsulating, learns that S is attached to nickname 314 15962, which is the TE-Path Site-TE-nickname of the ingress. 316 Now suppose that D's location has not been learned by RB1 and/or RB3. 317 What will happen, as it would in TRILL today, is that RB1 will 318 forward the frame as a multi-destination frame, choosing a tree. As 319 the multi-destination frame transitions into Level 2, RB2 replaces 320 the ingress nickname with the default area nickname. If RB1 does not 321 know the location of D, the frame must be flooded, subject to 322 possible pruning, in Level 2 and, subject to possible pruning, from 323 Level 2 into every Level 1 area that it reaches on the Level 2 324 distribution tree which is the MVPN PIM-bidir tree as in [1]. 326 2.1 Extensions in IS-IS and BGP 328 The TLVs in IS-IS to be added and the BGP extensions will be dealt 329 with in more detail in later versions of this draft. The other TLVs 330 that support creation of TE-Paths as in [7] will remain as is. 332 3 Security Considerations 334 TBD. 336 4 IANA Considerations 338 Suitable IANA requests will be detailed in upcoming versions of the 339 draft. 341 5 References 343 5.1 Normative References 345 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 349 1 1995. 351 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 352 April 1 1996. 354 5.2 Informative References 356 [1] draft-balaji-trill-over-ip-multi-level-04.txt, 357 Bhargav Bhikkaji et.al, March 2012, Work in Progress 359 [2] draft-xl-trill-over-wan-00.txt, XiaoLan. Wan et.al 360 December 11th ,2011 Work in Progress 362 [3] draft-perlman-trill-rbridge-multilevel-03.txt, Radia 363 Perlman et.al October 31, 2011 Work in Progress 365 [4] draft-raggarwa-mac-vpn-01.txt, Rahul Aggarwal et.al, 366 June 2010, Work in Progress. 368 [5] draft-yong-trill-trill-o-mpls, Yong et.al, October 369 2011, Work in Progress. 371 [6] draft-raggarwa-sajassi-l2vpn-evpn Rahul Aggarwal 372 et.al, September 2011, Work in Progress. 374 [7] draft-hu-trill-traffic-engineering-00.txt Fanwei Hu 375 et.al, January 11 2012, Work in Progress. 377 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 378 RFC 3514, April 1 2003. 380 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 381 Acronyms", RFC 5513, April 1 2009. 383 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 384 2009. 386 Authors' Addresses 388 Balaji Venkat Venkataswami, 389 Dell-Force10, 390 Olympia Technology Park, 391 Fortius block, 7th & 8th Floor, 392 Plot No. 1, SIDCO Industrial Estate, 393 Guindy, Chennai - 600032. 394 TamilNadu, India. 395 Tel: +91 (0) 44 4220 8400 396 Fax: +91 (0) 44 2836 2446 398 EMail: BALAJI_VENKAT_VENKAT@dell.com 400 Bhargav Bhikkaji, 401 Dell-Force10, 402 350 Holger Way, 403 San Jose, CA 404 U.S.A 406 Email: Bhargav_Bhikkaji@dell.com 408 Narayana Perumal Swamy, 409 Dell-Force10, 410 Olympia Technology Park, 411 Fortius block, 7th & 8th Floor, 412 Plot No. 1, SIDCO Industrial Estate, 413 Guindy, Chennai - 600032. 414 TamilNadu, India. 415 Tel: +91 (0) 44 4220 8400 416 Fax: +91 (0) 44 2836 2446 417 Email: Narayana_Perumal@dell.com