idnits 2.17.1 draft-aldrin-trill-data-center-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 : ---------------------------------------------------------------------------- No issues found here. 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 2, 2012) is 4409 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 158, but not defined == Missing Reference: 'PBB-EVPN' is mentioned on line 363, but not defined == Unused Reference: 'KEYWORDS' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) == Outdated reference: A later version (-02) exists of draft-tissa-trill-multilevel-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Sam Aldrin 3 INTERNET-DRAFT Donald Eastlake 4 Intended Status: Proposed Standard Huawei Technologies 5 Tissa Senevirathne 6 Ayan Banerjee 7 Santiago Alvarez 8 CISCO 10 Expires: September 3, 2012 March 2, 2012 12 TRILL Data Center Interconnect 13 draft-aldrin-trill-data-center-interconnect-00 15 Abstract 17 This document presents a solution suite for TRILL data center sites 18 to be connected over WAN networks. TRILL protocol is primarily 19 designed to work within intra-data centers. Connecting different 20 sites over WAN using overlay tunnel protocols is the primary method 21 employed at present. Though this presents a simple mechanism to 22 extend the LAN sites to be interconnected, it also brings in the 23 problem of scalability for TRILL nicknames exchanged between sites, 24 latency, duplication of traffic etc. This draft proposes a way to 25 extend the TRILL sites without having to reveal the data of the LAN 26 like customer MAC's or provide MAC's over the WAN, but to establish 27 connections between various sites by extending routing protocol to 28 exchange minimal information, thus reducing the information flow to 29 the required sites only. Document also proposes BGP routing protocol 30 extensions as an example to establish paths and information about the 31 essential RBridges nicknames, over WAN networks like MPLS. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Solution overview . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1 Site inter-connection . . . . . . . . . . . . . . . . . . . 5 74 2.2 Requirements overview . . . . . . . . . . . . . . . . . . . 6 75 2.2 TRILL campus extension . . . . . . . . . . . . . . . . . . 6 76 2.3 TRILL nickname exhaustion . . . . . . . . . . . . . . . . . 6 77 3. Solution comparison analysis . . . . . . . . . . . . . . . . . 7 78 3.1 TRILL campus extension . . . . . . . . . . . . . . . . . . 7 79 3.2 TRILL campus interconnection with E-VPN and PBB-EVPN . . . 8 80 3.3 TRILL campus interconnection over VPN's . . . . . . . . . . 8 81 4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 9 82 4.1 Campus and Backbone Areas . . . . . . . . . . . . . . . . . 9 83 4.2 Unicast forwarding . . . . . . . . . . . . . . . . . . . . . 10 84 4.3 Multicast Forwarding . . . . . . . . . . . . . . . . . . . . 10 85 4.4 MAC learning . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.5 TRILL nickname aggregation . . . . . . . . . . . . . . . . . 12 87 4.6 Route advertisement with BGP . . . . . . . . . . . . . . . . 12 88 5. TRILL campus inter-connectivity . . . . . . . . . . . . . . . . 13 89 5.1 Route advertisement . . . . . . . . . . . . . . . . . . . . 13 90 5.2 Inter-site nickname exchange . . . . . . . . . . . . . . . . 14 91 5.3 Border RBridge capability exchange . . . . . . . . . . . . . 14 92 5.4 TRILL adjacency resolution . . . . . . . . . . . . . . . . . 14 93 5.5 Forwarding of data frames . . . . . . . . . . . . . . . . . 15 94 6. Proposed additions and extensions . . . . . . . . . . . . . . . 15 95 6.1 BGP extension . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.2 Border RBridge capability TLV . . . . . . . . . . . . . . . 16 97 6.3 TRILL nickname aggregation sub-TLV . . . . . . . . . . . . . 16 98 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 99 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 100 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 102 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 1 Introduction 107 TRILL protocol is primarily designed as an intra-datacenter protocol 108 by leveraging the routing functionality to interconnect bridges. 109 Traditional Ethernet networks provided a single path for forwarding 110 the traffic, which is usually derived using protocols like Spanning 111 Tree. TRILL provided a way to utilize multiple links for forwarding, 112 thus utilizing the resources effectively. Even though TRILL is new 113 protocol, it seamlessly integrates with legacy bridging networks 114 without having to forklift upgrade of all the bridges to support 115 TRILL. By not having to learn the MAC addresses of end stations by 116 intermediate devices, provided a powerful way to interconnect bridges 117 within a datacenter and maximizing the resource usage and providing 118 multipath usage option. 120 TRILL enabled network creates efficiency by having reduced forwarding 121 table size. By doing TRILL nickname based forwarding created a layer 122 of abstraction and much easier to implement the protocol. This 123 enabled to address the scalability of a L2 domain, where thousands of 124 RBridges could exist to meet the needs of a datacenter. By leveraging 125 IS-IS protocol, the information exchange and leveraging the path 126 computation technology brought forth a new paradigm into bridging 127 technology. TRILL Base Protocol Specification [RFC6325] specifies a 128 tree based paradigm to forward broadcast and multicast traffic as 129 well as unknown unicast traffic. 131 Even though the TRILL is enabled within a datacenter and is not 132 primarily designed to work over WAN, there is a need to interconnect 133 various TRILL data sites. The same datacenter provider could be 134 having multiple TRILL sites and these TRILL enabled datacenter sites 135 could run independently or could share resources in order to cater to 136 the needs of customers. As such, there exist few proposals based on 137 overlay technologies which interconnect these sites but those 138 solutions require MAC learning at the edge RBridges and stripping of 139 TRILL nickname on the frame. Another option is to interconnect these 140 TRILL sites using Pseudowires and making a huge TRILL site. This is 141 useful option but the downside of this is when provider would like to 142 maintain independent sites and exchange only the required data to be 143 shared across sites, it becomes complicated to maintain the networks. 145 This draft solves these core problems of interconnection, site 146 independence, dynamic information exchange and setting up of 147 connections over WAN, leveraging existing WAN technologies like MPLS, 148 etc. Though the primary goal is effective interconnection, there are 149 various efficient schemes, which could enable seamless TRILL network 150 deployments, are also be presented. Solution covers both unicast and 151 multicast data traffic. 153 1.1 Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 2. Solution overview 161 This section provides the high-level overview of the solution to the 162 problems in various scenarios. More detailed representation of the 163 solution is covered in the later sections of the draft. 165 TRILL site or TRILL campus uses IS-IS to setup the RBridge 166 interconnection. A RBridge knows how to reach another RBridge within 167 the campus. When two TRILL campuses are interconnected, one could 168 visualize it in two different perspectives. First one is a merger of 169 two TRILL campuses into one. This requires each RBridge to know about 170 the other and the IS-IS should be able to compute the shortest paths 171 from one to another. The downside of this model is that information 172 exchange explosion and the size of IS-IS db and number of PDU's being 173 exchanged could increase exponentially. 175 The second perspective is to have these two TRILL campuses being 176 interconnected over a WAN, but their functioning nature is 177 independent to each other. The two campuses exchanges only the 178 required information between border RBridges of the campuses. This 179 will be more optimal and leads to interconnecting multiple campuses 180 without having to redesign the whole network to ensure uniqueness and 181 identity of RBridges. 183 Solution being proposed is an option of maintaining site independency 184 with a simplified solution and modeled around the existing and proven 185 technologies. Some of the enhancements were already proposed in other 186 drafts like multilevel TRILL [TISSA-MLEVEL] and the solution 187 leverages by extending those definitions as necessary. The solution 188 addresses the following areas described in the following sections 190 2.1 Site inter-connection 192 Each TRILL campus is considered as an independent site or an L1 IS-IS 193 domain. These TRILL campus sites are interconnected over WAN. Each 194 area will have an appointed border RBridges. These RBridges exchange 195 the information of other border RBridges of different TRILL campus 196 sites to establish connection with each other. In order to exchange 197 the information, the route has to be established. Extension of BGP 198 protocol is done to exchange the border RBridges information and 199 establish a route or vpn/mvpn connection between each of the border 200 RBridges. More details of the extension are detailed in the below 201 section. These sites are interconnected either over IP or MPLS. As 202 MPLS is a mature WAN technology, this draft references the solution 203 based on MPLS. This does not preclude that other technologies could 204 not be used. 206 2.2 Requirements overview 208 There are various requirements necessary to be met in order to 209 provide a seamless TRILL inter-connectivity across campuses and 210 datacenter. Some of the important requirements are as follows 212 o Extend TRILL technology over interconnect 214 o Ability to provide the same fast convergence for mobility as it 215 does in intra-TRILL campus 217 o Ability to work with various WAN technologies 219 o Option for dynamic establishment of connectivity across sites 221 o Minimal changes to protocols and definitions 223 o Backward compatible to existing networks and their functions. 225 2.2 TRILL campus extension 227 By interconnecting TRILL campus sites over WAN, one could extend the 228 L1 area, but that would cause other issues as detailed in the earlier 229 section. With this solution, all of the TRILL nicknames of one campus 230 are not exchanged with other campuses. Instead, there will be 231 RBridges which gets appointed, so only those specific nicknames are 232 exchanged with others. Also one could create another hierarchical 233 model like VPN, where participating appointed RBridges for that VPN 234 could be exchanged with other campuses belonging to that VPN. 235 Appointed or designated RBridges information will be exchanged with 236 other campus site using the Affinity TLV extension. Detailed 237 description on how to create and the usage are detailed in multileve 238 draft [TISSA-MLEVEL]. When each campus site creates this information 239 and exchanged with other campus sites of the network or VPN, this 240 could be used for two purposes, 1. A VPN specific WAN paths could be 241 created between campus sites. 2. The data distribution could be 242 optimized without having the need to be broadcast the data frames 243 from one campus into every campus site. 245 2.3 TRILL nickname exhaustion 246 Though this draft is not meant to provide solution for TRILL nickname 247 exhaustion, it enables provider to deal with the problem effectively 248 and not having to re-design the network, every time a new campus is 249 interconnected. The proposed solution has RBridges which are not 250 required to be exposed outside of the campus and there are other 251 RBridges which are also known as border RBridges. These border 252 RBridges nicknames are unique globally. Rest of the RBridges 253 nicknames are significant locally, that includes the appointed 254 RBridges nicknames for a VPN. When a frame has to be forwarded to an 255 RBridge which resides in another campus, the originating RBridge only 256 knows how to get to the borderRBridge. This border RBridge should 257 have the list of RBridges of other campus sites and thus could select 258 the appropriate MPLS LSP or MVPN or PW and encapsulate the TRILL 259 frame with the label header and forward over that. More details are 260 covered in the unicast and multicast sections of the detailed 261 solution. 263 3. Solution comparison analysis 265 As eluded to in the earlier sections, there are various methods on 266 interconnecting different TRILL campus sites. Before going into the 267 details of proposed solution a close examination of some of the 268 proposed solutions, provides better perspective of this solution. 270 3.1 TRILL campus extension 272 In this model TRILL campuses are connected over WAN using 273 technologies like PW. This is the most simplest way of 274 interconnecting the sites. When campuses are interconnected, the 275 TRILL campus will get expanded and each RBridge could reach each 276 other. The main criteria for this will be to maintain unique nickname 277 for RBridges. 279 -------------- ------------ -------------- 280 | | | | | | 281 |TRILL Campus | | WAN | | TRILL Campus | 282 | | | | | | 283 | BRB1===| |====BRB2 | 284 RB1 | | | | RB2 285 | | | | | | 286 | | | | | | 287 -------------- ------------ -------------- 289 As shown in the figure above, two TRILL campuses are interconnected 290 over WAN. Border RBridges establish connection over WAN using PW or 291 other WAN technologies. All the nicknames within each campus sites 292 have to be unique. The WAN in this case is transparent to the TRILL 293 campuses and the path computation doesn't involve WAN component, 294 instead it will be like one TRILL campus. When RB1 originates a TRILL 295 frame destined to RB2, it traverses over BRB1 and BRB2 and reaches 296 RB2. 298 This solution is workable when the campuses are small and do NOT need 299 to change or requires interconnecting more TRILL campuses. The other 300 downside for this model is, when two campuses are interconnected and 301 there is overlap of nicknames, the network has to be re-designed to 302 eliminate the duplicate nicknames and make each RBrige to have a 303 unique nickname. 305 3.2 TRILL campus interconnection with E-VPN and PBB-EVPN 307 TRILL campuses could be extended over WAN using E-VPN and PBB-EVPN. 309 BEB +--------------+ BEB 310 || | | || 311 \/ | | \/ 312 +----+ AC1 +----+ | | +----+ +----+ 313 | CE1|-----| | | | | |---| CE2| 314 +----+\ |MES1| | IP/MPLS | |MES3| +----+ 315 \ +----+ | Network | +----+ 316 \ | | 317 AC2\ +----+ | | 318 \| | | | 319 |MES2| | | 320 +----+ | | 321 /\ +--------------+ 322 || 324 The [PBB-EVPN] draft proposes interconnection details on how two 325 TRILL campuses could be interconnected using the E-VPN technology. In 326 this a new BGP route is advertised for reachability of TRILL 327 RBridges. This technique leverages the PBB technology and also 328 enables to retain TRILL header but is recommended to avoid 329 transmitting TRILL encapsulated frames over the WAN links. The 330 primary downside of this method is the requirement for edge RBridges 331 to learn MAC Addresses in order to resolve the adjacency. 333 3.3 TRILL campus interconnection over VPN's 335 In this method, TRILL campus sites could be interconnected over 336 VPN's. 338 -------------- ------------ -------------- 339 | | | | | | 340 |TRILL Campus | | WAN | | TRILL Campus | 341 | | | | | | 342 | BRB1===| |====BRB2 | 343 RB1 | | | | RB2 344 | | | | | | 345 | | | | | | 346 -------------- ------------ -------------- 347 || 348 || 349 ||BRB3 350 ------------ 351 | | 352 |TRILL Campus| 353 | | 354 | | 355 | | 356 | | 357 | | 358 -----RB3---- 360 These VPN's could be established statically or dynamically. In order 361 to establish dynamically, the border RBridges needs to exchange 362 information of the nicknames and connect different sites. The 363 hierarchical model like H-VPLS could be established as well. [PBB- 364 EVPN] draft provides some details on how to achieve this, but still 365 requires border RBridges to exchange MAC information and resolution 366 for L2 adjacency. One other option is much similar to the first model 367 where campuses exchange TRILL nicknames between campuses over VPN's. 368 Though this model groups different sites according to the way VPN's 369 are configured, avoiding flooding of TRILL nicknames or site 370 independency cannot be achieved. 372 4. Operational Overview 374 4.1 Campus and Backbone Areas 376 Each TRILL campus will be assigned a border RBridge. This is 377 identified using the 'Attached' bit in the IS-IS PDU. The border 378 RBridge has list of the RBridges of each campus site. These list of 379 bridges are exchanged using the TRILL nickname aggregation sub-TLV. 380 Details of the sub-TLV are detailed in the below section. 382 Every TRILL campus campus need not exchange all the RBridge nicknames 383 with other campuses. Let us take the scenario of campus A to be 384 interconnected with campus B. In campus A, there are RBridges 385 RB1...RB10, which are interconnected in L1. These nicknames are not 386 tunneled or exchanged with other L1 campus sites. Similarly campus B 387 has RB11...RB20 and need not be distinct from campus A RBridge 388 nicknames. So, if a new campus is connected to the domain, there is 389 no need for the network to redesigned or restructured. 391 The RBridges at each campus advertise the information to other campus 392 to establish a route/MPLS LSP between campus sites. A new BGP 393 extension as defined below is sent out. This reachability TLV is 394 received by other border RBridges and establish the MPLS LSP between 395 them. 397 The border RBridges will have the complete information of its campus 398 RBridges. Not all of the RBridges nicknames need not be advertised 399 globally. So, the globally exchanged nicknames of RBridges should be 400 unique across campuses. Depending on the policy established, these 401 Border RBridges will exchange the TRILL information with other campus 402 border Bridges, over the routes/MPLS LSP established between 403 different campuses. In IS-IS domain the equivalent of this is the L2 404 backbone area, which in this case, is established over WAN. 406 4.2 Unicast forwarding 408 If the destination TRILL nickname is not known, the originating or 409 transit RBridges forwards it to border RBridge. As the border RBridge 410 has all the nicknames of each campus, it forwards the frame to the 411 right campus border RBridge, which in turn could forward within its 412 campus as per base protocol specification [RFC6325]. In the case 413 where the destination is unknown, the frame is flooded to each 414 campus. Using the MAC learning procedures, the associated RBridge 415 will be learnt for the subsequent frames to be forwarded as unicast, 416 instead of flooding. Flooding into various campuses or TRILL data 417 sites happen only if the the frame is of global ID based on VLAN 418 identification. 420 4.3 Multicast Forwarding 422 Whether the traffic scope is local or global across campuses is 423 identified by VLAN or port or fine-grain label. If the traffic is to 424 be forwarded within campus, it is done using the local tree. But if 425 the forwarding has to be done globally, it needs to use the global 426 tree. When the frame has global context, it will be flooded into 427 other TRILL sites as well. 429 In MPLS the multicast networks are established within the core 430 networks. In the case of RBridges, which are part of the customer 431 networks and do not participate in the service provider networks and 432 their topologies, the multicast tree could be built using IP 433 multicast or leverage MVPN services offered by the service provider. 434 The global trees are established between border RBridges with the 435 help of information exchanges between border RBridges. As the IS-IS 436 is limited to individual campus sites, the information for the 437 backbone tree over WAN has to be exchanged between border RBridges 438 either as a IP multicast PIM message or specific TLV indented for 439 other campus border RBridges. More details on this will be added in 440 the later versions of the draft. 442 -------------- ------------ -------------- 443 | | | | | | 444 |TRILL Campus1 | | WAN | | TRILL Campus2| 445 | | | | | | 446 | BRB1===| |====BRB2 | 447 RB1 | | | | RB2 448 | | | | | | 449 | | | | | | 450 -------------- ------------ -------------- 451 || 452 || 453 ||BRB3 454 ------------ 455 | | 456 |TRILL Campus| 457 | 3 | 458 | | 459 | | 460 | | 461 | | 462 -----RB3---- 464 In the above figure when the multicast frame has to be sent from 465 campus 1 to campus 2 and 3, the frame arrives at border RBridge BRB1. 466 With the default global tree between border RBridges of different 467 campuses, the forwarding is setup to egress the frame or replicated 468 over MPLS LSP's to all other campus sites. If the frame is destined 469 for non-default global tree, the appropriate MPLS LSP(s) are 470 identified and the frame is forwarded accordingly. 472 Once the frame is reached on the border router of the campuses, the 473 frame is locally multicast forwarded. The same technique as employed 474 in the multilevel draft [TISSA-MLEVEL] is used here as well. 476 If mVPN services are deployed interconnecting campus sites, the 477 multicast tree is built over these services based on the customer 478 VLANs. 480 4.4 MAC learning 482 When a frame is to be forwarded from customer MAC A to customer MAC 483 B, the frame is set as unknown unicast frame over TRILL networks. If 484 the MAC A and MAC B are connected over WAN, the frame is transmitted 485 over WAN to the other campus. When the frame is reached at the 486 RBridge connecting to MAC B, it will learn about the originator 487 RBridge for MAC A. While responding, the egress RBridge know the 488 originating RBridge, it will unicast the frame to the originator. 490 4.5 TRILL nickname aggregation 492 Nicknames are allocated or assigned to RBridges in a given campuses 493 using various methods. It could be OSS, CLI or could be a dynamic 494 control protocol which configures the nicknames. As the nicknames are 495 confined to each L1 area, the nickname management, when sites are 496 connected over WAN, it is essential to optimize the name allocation 497 in order to use the name space effectively. Name allocation is not in 498 the scope of this draft. If there is a necessity, the topic could be 499 considered in the later revisions of the draft. For this version we 500 do recommend some of the optimization techniques for nickname 501 allocation defined in the multilevel draft [TISSA-MLEVEL]. 503 Each border RBridges needs to exchange the nicknames of each campuses 504 with other border RBridges. As the border RBridges are connected over 505 various types of WAN networks, mandating enhancement to a specific 506 protocol is deemed not the right approach. As the information 507 exchange has to be done, certain characteristics for the data 508 exchange have to be met. 510 o The amount of data exchange has to be minimal and optimized. 512 o the information exchange has to be quick. 514 o Conflicts and duplicate information flow has to be avoided 516 This draft proposes a generic TLV, which is to be exchanged between 517 border RBridges. If the nickname allocation is done in terms of 518 ranges, the same could be exchanged between border RBridges, 519 seamlessly. As the TLV has to be terminated at the border RBridges, 520 it is better suited to be sent as a unicast message to the 521 neighboring border RBridge. This could be sent as an IP message with 522 TRILL header containing the target border RBridge. More details on 523 how to encapsulate and process the frame should be in the later 524 versions of the draft. 526 4.6 Route advertisement with BGP 527 BGP route advertisement is to connect border RBridges. As described 528 in earlier sections, each campus site exchanges the TRILL nicknames 529 with other campuses. These nicknames are not leaked in to the campus 530 but will be maintained at the border RBridges. The connectivity 531 between these border RBridges is similar to L2 backbone of IS-IS but 532 in this case it is over WAN and IS-IS is absent. 534 This draft, unlike some other drafts, do not propose to de-capsulate 535 the TRILL frame to learn the MAC addresses. Instead, it propose to 536 use nicknames themselves to be exchanged between sites. 538 A new BGP route advertisement is defined to advertise the border 539 RBridge nickname with the other border RBridges in different 540 campuses. This advertisement will let other campuses know its MPLS 541 label, its nickname, IP address etc. Once the route is established, 542 further information of campus nicknames etc could be exchanges to 543 establish the inter-connectivity of the TRILL campuses 545 5. TRILL campus inter-connectivity 547 The primary reason to interconnect TRILL campuses is to maintain 548 geographically distant, segmented sites and customer specific 549 segregation possible by interconnecting and not having to redo the 550 network and campus redesign for every change and need. With customers 551 being mobile or services offered by service providers could be re- 552 located depending on the time-zones and resource availability, 553 restricting to a specific site is a thing of the past. 555 These constraints brought forth the need to have different sites 556 interconnected over the WAN, be it MPLS or VPLS or IP and to provide 557 the services on demand to meet the needs of customers and their data 558 center needs. As TRILL has proven to be an effective protocol by 559 bringing routing technologies into bridges or L2 forwarding, the 560 short coming of TRILL interconnect is the immediate need. As eluded 561 to in the earlier sections on different kinds of solutions, meeting 562 all the needs of the TRILL DCI as laid out in the requirements 563 section, is the primary goal of this draft. 565 5.1 Route advertisement 567 Border RBridges only participate in interconnecting various TRILL 568 campuses. These border RBridges are elected or identified as 569 described in the earlier section i.e. using IS-IS protocol 570 advertisement. These border RBridges, when required to interconnect 571 with other campuses, advertise the route to other site border 572 RBridges using the BGP enhancement. Upon receipt of the route 573 advertisement, the MPLS LSP or IP path or Pseudowire is established 574 between RBridges and they could communicate with each other and 575 exchange other information. 577 If L2 connectivity is to be used with protocols like VPLS, a similar 578 method could be employed, where the PWE3 could be established between 579 border RBridges. More details to be added in the later versions of 580 the draft. 582 5.2 Inter-site nickname exchange 584 There are three types of nicknames which are exchanged between border 585 RBridges. 587 o Nickname of border RBridges 589 o Nicknames of RBridges for each campus 591 o Nicknames of RBridges which are part of a specific customer VLAN or 592 VPN 594 The nickname aggregation TLV is used as payload to be exchanged 595 between border RBridges. This information is used to establish inter- 596 connectivity between TRILL sites per customer VLAN or default global 597 tree. 599 5.3 Border RBridge capability exchange 601 An additional capability TLV is defined to exchange info on what each 602 of the border RBridge is capable of. This is very essential for 603 forward and backward capability . Capability information not only 604 indicates the capability version but could also force the 605 interconnection to be restricted as per the policy set by the 606 customer. Some of the capability advertisements are as follows. 608 o Version. 610 o default nick name resolution 612 o connect more campuses 614 o active-active link support 616 o Ability to support multicast forwarding 618 5.4 TRILL adjacency resolution 620 When a frame is to be forwarded from one campus to another, the 621 adjacency resolution has to be done on the border RBridge. When TRILL 622 nicknames are advertised from one border RBridge to another, the 623 border RBridge keeps the database of all the nicknames. The MPLS 624 LSP's between each RBridges are established by the route 625 advertisements. VPN specific services could be established based on 626 the customer VLAN ID's and also the exchange of nicknames per VPN 627 between border RBridges. 629 Once the frame is received on the border RBridge, it will look in the 630 forwarding table to identify the next hop. The adjacency information 631 could indicate an MPLS LSP with a specific label encapsulation. For 632 VPN, there will be additional VPN label in the label stack. The TRILL 633 frame is encapsulated, without removing the TRILL header and is 634 forwarded over the MPLS LSP. 636 5.5 Forwarding of data frames 638 The TRILL frames are forwarded as per the base protocol [RFC6325] 639 within a campus site. The forwarding of the frames from TRILL campus 640 to campus will be over MPLS LSP's or IP or whichever WAN connection 641 is established between border RBridges. The encapsulation of the 642 Frame with WAN header is based on the adjacency resolution made in 643 the forwarding on the border RBridge. 645 6. Proposed additions and extensions 647 There are certain extensions being proposed in this draft to 648 interconnect TRILL campuses or datacenters. These include new 649 additions to routing and also new TLV's to exchange information 650 between border RBridges. There are few references to the extensions 651 proposed in other drafts which are used in this draft as well. 653 6.1 BGP extension 655 A new BGP route advertisement is done to exchange and establish 656 route/MPLS lsp between border RBridges. 658 +---------------------------------------+ 659 |RD (8 octets) | 660 +---------------------------------------+ 661 |Originating RBridge MAC address | 662 +---------------------------------------+ 663 |Originating RBridge IP address(v4/v6) | 664 +---------------------------------------+ 665 | Nickname Length (1 octet) | 666 +---------------------------------------+ 667 | RBridge Nickname (2 octets) | 668 +---------------------------------------+ 669 | MPLS Label (n * 3 octets) | 670 +---------------------------------------+ 672 6.2 Border RBridge capability TLV 674 This TLV as defined in earlier section, defines the capability of a 675 border RBridge, to be exchanged with other border RBridges for 676 seamless inter-working across campus sites. 678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Type = | Length = 8 | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Version | Flags | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Flags | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Definition of flag bits will be identified and defined later. 689 6.3 TRILL nickname aggregation sub-TLV 691 The nickname aggregation TLV defined in multilevel draft [TISSA- 692 MLEVEL] is used in advertising the nicknames into other border 693 Routers. Some new additions or changes will be proposed in later 694 versions of the draft. 696 7 Security Considerations 698 700 8 IANA Considerations 702 704 9 References 706 9.1 Normative References 708 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, March 1997. 711 [RFC2234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 712 Syntax Specifications: ABNF", RFC 2234, November 1997. 714 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 715 "Intermediate System to Intermediate System (IS-IS) 716 Extensions for Advertising Router Information", RFC 4971, 717 July 2007. 719 [RFC6325] Perlman, R., et.al, "Routing Bridges (RBridges): Base 720 Protocol Specification", RFC 6325, July 2011. 722 [trillcmt]Senevirathne, T., et.al, "Coordinated Multicast Trees 723 (CMT)for TRILL", Work in Progress, January 2012. 725 9.2 Informative References 727 [RFC6326] Eastlake, D, et.al, "Transparent Interconnection of Lots of 728 Links (TRILL) Use of IS-IS", RFC 6326, July 2011. 730 [rfc6326bis] Eastlake, D, et.al, "Transparent Interconnection of Lots 731 of Links (TRILL) Use of IS-IS", Work in Progress, draft- 732 eastlake-isis-rfc6326bis-04.txt, January 2012. 734 [TISSA-MLEVEL] Senevirathne, "RBridges: Multilevel TRILL", Work in 735 Progress, draft-tissa-trill-multilevel-00.txt, February 736 201. 738 Authors' Addresses 739 Sam Aldrin 740 Huawei Technologies 741 2330 Central Express Way 742 Santa Clara, CA 95951 744 Email: aldrin.ietf@gmail.com 746 Tissa Senevirathne 747 CISCO Systems 748 375 East Tasman Drive 749 San Jose CA 95134 751 Phone: 408-853-2291 752 Email: tsenevir@cisco.com 754 Ayan Banerjee 755 CISCO Systems 756 425 East Tasman Drive 757 San Jose CA 95134 759 Phone: 408-527-0539 760 Email: ayabaner@cisco.com 762 Donald Eastlake 763 Huawei Technologies 764 155 Beaver Street 765 Milford, MA 01757 USA 767 Phone: +1-508-333-2270 768 Email: d3e3e3@gmail.com 770 Santiago Alvarez 771 CISCO systems 773 Email: saalvare@cisco.com