idnits 2.17.1 draft-muks-trill-dci-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([VTSD]), 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 == Line 397 has weird spacing: '... and b) Con...' == Line 448 has weird spacing: '...way for traff...' == Line 520 has weird spacing: '...N), and b) Us...' -- The document date (February 17, 2016) is 2988 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6339bis' is mentioned on line 519, but not defined == Unused Reference: 'Pseudo-Nickname' is defined on line 748, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mohammed Umair 3 Intended Status: Informational Kingston Smiler S 4 Shaji Ravindranathan 5 IPInfusion 6 Lucy Yong 7 Donald Eastlake 3rd 8 Huawei Technologies 9 Expires: August 20, 2016 February 17, 2016 11 Date Center Interconnect using TRILL 12 14 Abstract 16 This document describes a TRILL based Data Center Interconnect (DCI) 17 solution. TRILL is predominantly used inside a data center for 18 providing intra-data center switching optimally by utilizing multiple 19 links. This draft described a way to use TRILL to extend a network 20 across different data center via MPLS service provider network using 21 Virtual TRILL Service/Switch Domain (VTSD) as described in draft 22 [VTSD]. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Date Center Topology . . . . . . . . . . . . . . . . . . . . . 7 65 3. Requirements of DCI Protocol . . . . . . . . . . . . . . . . . 7 66 3.1. Multi-homing with all-active forwarding . . . . . . . . . 8 67 3.2. Effectively scaling the bandwidth by adding more links . . 8 68 3.3. Auto-discovery of services . . . . . . . . . . . . . . . . 9 69 3.4. Delivering Layer 2 and Layer 3 services over the same 70 interface . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5. BUM traffic optimization . . . . . . . . . . . . . . . . . 9 72 3.6. Control plane learning of MAC . . . . . . . . . . . . . . 10 73 3.7. Virtualisation and isolation of different instances . . . 10 74 3.8. MAC mass-withdrawal . . . . . . . . . . . . . . . . . . . 10 75 3.9. Significantly larger Name-Space in the Overlay (16M 76 segments) . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.10. Extensive OAM Capabilities . . . . . . . . . . . . . . . 11 78 3.11. Supporting Ring topology in the Core Network . . . . . . 11 79 4. TRILL DCI Operations . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. TRILL data center . . . . . . . . . . . . . . . . . . . . . 12 81 4.2. Layer2 data center . . . . . . . . . . . . . . . . . . . . 12 82 4.2.1. TRILL Access load-balancing . . . . . . . . . . . . . 13 83 4.2.1.1. Appointed Forwarder Mechanism . . . . . . . . . . 13 84 4.2.1.2. TRILL Active-Active Access . . . . . . . . . . . . 13 85 4.2.2. TRILL Pseudowire load-balancing . . . . . . . . . . . . 13 86 5. MPLS encapsulation and Loop free provider PSN/MPLS . . . . . . 14 87 6. Frame Processing . . . . . . . . . . . . . . . . . . . . . . . 15 88 6.1. Frame processing between data center T2 switch and TIR. . . 15 89 6.2. Frame processing between TIR's . . . . . . . . . . . . . . 15 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 97 1 Introduction 99 The IETF Transparent Interconnection of Lots of Links (TRILL) 100 protocol [RFC6325] [RFC7177] [RFC7180bis] provides transparent 101 forwarding in multi-hop networks with arbitrary topology and link 102 technologies using a header with a hop count and link-state routing. 103 TRILL provides optimal pair-wise forwarding without configuration, 104 safe forwarding even during periods of temporary loops, and support 105 for multipathing of both unicast and multicast traffic. Devices 106 implementing TRILL are called Routing Bridges(RBridges)or TRILL 107 Switches. 109 TRILL is predominantly used inside data centers for providing intra- 110 data center switching optimally by utilizing multiple links. Though 111 TRILL usually runs within a data center, there is a need to 112 interconnect various data center sites to provide connectivity across 113 data centers. This draft describes a solution to this problem by 114 using VTSD (Virtual TRILL Switch Domain) as described in the draft 115 [VTSD]. 117 The draft [VTSD] introduces a new terminology called VTSD (Virtual 118 TRILL Switch Domain) and VPTS (Virtual Private TRILL Service). 120 The (Virtual Private TRILL Service) VPTS is a L2 TRILL service, that 121 emulates TRILL service across a Wide Area Network (WAN) over MPLS 122 PWE3. VPTS is similar to what VPLS does for bridge domain. 124 The VTSD [Virtual Trill Switch Domain] is similar to VSI (layer 2 125 bridge) in VPLS model, but this acts as a TRILL RBridge. VTSD is a 126 superset of VSI and must support all the functionality provided by 127 the VSI as defined in [RFC4026]. Along with VSI functionality, the 128 VTSD must be capable of supporting TRILL protocols and form TRILL 129 adjacency. The VTSD must be capable of performing all the operations 130 that a standard TRILL Switch can do. 132 Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that 133 emulates the essential attributes of a service such as Ethernet over 134 a Packet Switched Network (PSN). The required functions of PWs 135 include encapsulating service-specific PDUs arriving at an ingress 136 port, and carrying them across a path or tunnel, managing their 137 timing and order, and any other operations required to emulate the 138 behavior and characteristics of the service as faithfully as 139 possible. 141 The PEs may be connected by an MPLS Label Switched Path (LSP) 142 infrastructure, which provides the benefits of MPLS technology. The 143 PEs may also be connected by an IP network, in which case IP/GRE 144 (Generic Routing Encapsulation) tunneling or other IP tunneling can 145 be used to provide PSN functionality. The detailed procedures in 146 this document are specified only for MPLS LSPs as PSN. However, 147 these procedures are designed to be extensible to use IP tunnels as 148 PSN, which is outside the scope of this document. 150 1.1 Terminology 152 Acronyms used in this document include the following: 154 AC - Attachment Circuit [RFC4664] 156 Access Port - A TRILL switch port configured with 157 the "end station service enable" bit 158 on, as described in 159 Section 4.9.1 of [RFC6325]. 160 All AC's, VTSD ports 161 connected to CE's, should configured 162 as TRILL Access port. 164 AF - Appointed Forwarder [RFC6325] 165 and [RFC6439bis]. 167 BUM - Broadcast, Unknown destination Unicast 168 and Multicast 170 Data Label - VLAN or FGL 172 DCI - Data Center Interconnect 174 ECMP - Equal Cost Multi Pathing 176 FGL - Fine-Grained Labeling [RFC7172] 178 IS-IS - Intermediate System to Intermediate 179 System [IS-IS] 181 L2 - Layer 2 183 LAN - Local Area Network 185 Link - The means by which adjacent TRILL 186 switches or VTSD is connected. 187 May be a bridged LAN. 189 MLAG - Multi-Chassis Link Aggregation 190 MPLS - Multi-Protocol Label Switching 192 PE - Provider Edge Device 194 PSN - Packet Switched Network 196 PW - Pseudowire [RFC4664] 198 RBridge - An alternative name for TRILL Switch 200 TIR - TRILL Intermediate Router 201 (Devices where Pseudowire starts and 202 Terminates) 204 TRILL - Transparent Interconnection of Lots 205 of Links OR Tunneled Routing in the 206 Link Layer [RFC6325] 208 TRILL Site - A part of a TRILL campus that 209 contains at least one RBridge. 211 TRILL switch - A device implementing the TRILL 212 protocol. An alternative name 213 for an RBridge. 215 Trunk port - A TRILL switch port configured with 216 the "end station service disable" 217 bit on, as described in 218 Section 4.9.1 of [RFC6325]. 219 All pseudowires should 220 be configured as TRILL Trunk port. 222 VLAN - Virtual Local Area Network 224 VPLS - Virtual Private LAN Service 226 VPTS - Virtual Private TRILL Service 228 VSI - Virtual Service Instance [RFC4664] 230 VTSI - Virtual TRILL Service Instance 232 VTSD - Virtual TRILL Switch Domain OR 233 Virtual TRILL Service Domain 234 A Virtual RBridge that segregates 235 one tenant's TRILL database as well 236 as traffic from the other. 238 VTSD-AP - A VTSD TRILL Access port can be a 239 AC or a logical port connected with 240 CE's. it can be a combination of 241 physical port and Data Label. 242 OR just Physical port connected to 243 CE's 245 2. Date Center Topology 247 The reference topology used in this document is a 3 tier traditional 248 topology. Although other topologies may be utilized within the data 249 center, most of such L2 based data centers may be modeled as a 3 tier 250 traditional topology. The reference topology is illustrated in Figure 251 1. To keep terminologies simple and uniform, in this document these 252 layers will be referred to as the Tier-1, Tier-2 and Tier-3 "tiers", 253 and the switches in these layers will be termed as T1SW, T2SW etc. 254 For simplicity reasons, the entire data center topology will not be 255 mentioned in the further sections. Only the relevant nodes will be 256 shown identified by this nomenclature. 258 +------+ +------+ 259 | | | | 260 | T1SW1|--| T1SW2| Tier-1 261 | | | | 262 +------+ +------+ 263 | | | | 264 +---------+ | | +----------+ 265 | +-------+--+------+--+-------+ | 266 | | | | | | | | 267 +----+ +----+ +----+ +----+ 268 | | | | | | | | 269 |T2SW|-----|T2SW| |T2SW|-----|T2SW| Tier-2 270 | | | | | | | | 271 +----+ +----+ +----+ +----+ 272 | | | | 273 | | | | 274 | +-----+ | | +-----+ | 275 +-|T3SW |-+ +-|T3SW |-+ Tier-3 276 +-----+ +-----+ 277 | | | | | | 278 <- Servers -> <- Servers -> 280 Figure 1: Typical data center network topology 282 3. Requirements of DCI Protocol 283 This section describes in detail the key requirements of a data 284 center interconnect (DCI) solution. 286 3.1. Multi-homing with all-active forwarding 288 One of the key requirements of a DCI layer in data center is to 289 efficiently use all the links in the network by spreading load across 290 them. There are two types of links in the DCI layer. The links that 291 provides connectivity to the data center and the links that provides 292 connectivity to other data center via backbone network. The DCI layer 293 should use both of these link types optimally in an all-active 294 forwarding manner. Typically the links towards the data center will 295 have multiple connectivity towards the peer for providing redundancy 296 in the network. TRILL supports multiple active parallel links 297 between the TRILL R-Bridges / traditional L2 bridges. For providing 298 active load-balance for traffic from layer2 data center TRILL uses 299 the Appointed Forwarder mechanism. 301 The Appointed forwarder mechanism defined in [RFC6439bis] provides a 302 way to actively forwarding end station traffic by a RBridge, so that 303 native traffic in each VLAN is handled by at most one RBridge. By 304 default, the DRB (Designated RBridge) on a link is in-charge of 305 native traffic for all VLANs on the link. The DRB may, if it wishes, 306 act as Appointed Forwarder for any VLAN and it may appoint other 307 RBridges that have ports on the link as Appointed Forwarder for one 308 or more VLANs with any one of the mechanism described in 309 [RFC6439bis]. 311 A RBridge on a multi-access link forms adjacency [RFC7177] with other 312 RBridge if the VLAN's configured/enabled between them are common. For 313 example there are four RBridges attached to multi-access link, say 314 RB1, RB2, RB3 and RB4. RB1 and RB2 are configured with single VLAN 315 "VLAN 2", whereas RB3 and RB4 are configured with "VLAN 3". Assume 316 that there are no Native VLAN's present on any of the RBridges 317 connected to multi-access link. Since TRILL Hellos are sent with VLAN 318 Tag enabled on the interface, RB3 and RB4 drops the hellos of RB1 and 319 RB2 (since they are not configured for VLAN 2). Similarly RB1 and RB2 320 drops the Hellos of RB3 and RB4. This results in RB1 and RB2 not 321 forming adjacency with RB3 and RB4. RB1 and RB2 after electing DRB 322 and forming adjacency between them, will decide about VLAN 2 AF. 323 Similarly RB3 and RB4 decide about the VLAN 3 AF. 325 3.2. Effectively scaling the bandwidth by adding more links 327 As more and more services are deployed over the cloud, there is a 328 clear requirement for easily scaling the bandwidth in the network 329 without disturbing the existing running services. One of the ways to 330 scale the bandwidth is to add a link (either physical or logical) 331 across the devices which require higher bandwidth rate. The same 332 requirement is applicable in the DCI layer for interfaces towards the 333 backbone network and towards the data center. 335 TRILL protocol, by design itself inherently takes care of this by 336 optimally utilizing multiple links. As PWE3 interface, which provides 337 connectivity to different data center is also part of TRILL network, 338 it is possible to dynamically scale the bandwidth in the backbone 339 network / DCI interface by adding more PWE3 to the VTSD instance. 341 3.3. Auto-discovery of services 343 This is one of the key requirement of data center so DCI services 344 will be provisioned with minimal configuration effort. Currently the 345 TRILL protocol doesn't have any mechanism to discover peer VTSD / TIR 346 nodes. A new draft should be proposed to address this in TRILL. 348 3.4. Delivering Layer 2 and Layer 3 services over the same interface 350 It is desirable to provide a mechanism to advertise both layer 2 and 351 layer 3 forwarding information (Route (IP prefix) in case of L3 and 352 MAC in case of L2) to the peer nodes across the data centers. The 353 control plane way of distributing the forwarding information provides 354 multiple benefits in terms of scale, performance and security. 355 [ARP/ND-Optimization] and [IA-APPsub-TLV] provides mechanism to 356 distribute both MAC and IP information over TRILL network. 358 3.5. BUM traffic optimization 360 A key design consideration in a DCI network is handling BUM 361 (Broadcast, Unknown Unicast and Multicast) traffic. If the BUM 362 packets are handled as in the traditional layer 2 network (by 363 forwarding to all the ports which are part of the same broadcast 364 domain), this will create excessive overhead in the network. TRILL 365 takes care of this issue using the distribution tree and pruning 366 mechanism. 368 Any unknown unicast, multicast or broadcast frames inside VTSD should 369 be processed or forwarded through any one of the distribution tree's 370 path. If any multi-destination frame is received from the wrong 371 pseudowire at a VTSD, the TRILL protocol running in VTSD should 372 perform a RPF check as specified in [RFC7180bis] and drops the 373 packet. 375 Pruning (VLAN (or FGL) and multicast pruning) mechanism of 376 Distribution Tree as specified in [RFC6325] and [RFC7180bis] can also 377 be used for forwarding of multi-destination data frames on the 378 branches that are not pruned. 380 Also the ARP/ND-proxy and control plane MAC address learning 381 mechanism mentioned in Sections 3.4 and 3.6 will help the 382 VTSD/RBridges in the network to learn the unicast MAC address from 383 ARP/ND packets. This reduces the unknown unicast flow. 385 3.6. Control plane learning of MAC 387 Learning MAC addresses in data plane brings the scaling limitations 388 of the devices to the DCI layer. Hence the protocol that provides DCI 389 should provide control plane learning to overcome the data plane 390 learning limitation. Mac address learning through ESADI (End Station 391 Address Distribution Information Protocol) is described in [RFC7357] 392 and requires no changes to the protocol. However the following 393 optional extensions can be provided for controlling the MAC learning 394 mechanism. 396 a) Way to disable remote MAC Addresses learning through data plane 397 and b) Control over the number of MAC Addresses to be advertised to 398 the remote VTSD's. 400 The mechanism to provide these optional extensions is out side the 401 scope of this document. 403 3.7. Virtualisation and isolation of different instances 405 VTSD provides a way to isolate the TRILL link state databases and the 406 forwarding information across different TRILL sites. As VPTS is 407 similar to VPLS, the mac address and the nickname learnt on a 408 particular VPTS is isolated from other VPTS instance in the system. 410 3.8. MAC mass-withdrawal 412 It is desirable in the data center to have a mechanism to flush a set 413 of MAC addresses from the network, in the event of node failures in 414 the network. This Mass MAC-Address withdrawal may also be applicable 415 when there is any movement in the End-stations. Mass MAC-Address 416 withdrawal is specified in draft [Address-Flush] and require no 417 changes to the protocol. 419 3.9. Significantly larger Name-Space in the Overlay (16M segments) 421 Layer2 DCI technologies can be used to provide overlay connectivity 422 between Top of Rack switches over an IP underlay. When a DCI protocol 423 is used as an overlay, there is a clear requirement to have a larger 424 namespace to provide services to different customers. TRILL FGL 425 [RFC7172] provides 2^24 data labels to isolate different TRILL 426 services. 428 3.10. Extensive OAM Capabilities 430 It is desirable to provide extensive OAM support in the data center 431 network for fault indication, fault localization, performance 432 information and diagnostic functions. TRILL already provides 433 extensive support for OAM capabilities as specified in [RFC7174] and 434 [RFC7175]. These mechanisms can be used for fault indication, 435 localization and performance information. 437 3.11. Supporting Ring topology in the Core Network 439 In most cases, the backbone network that provides connectivity to the 440 data center is deployed as a ring topology to provide fault 441 tolerance. It is highly desirable to provide a similar kind of 442 service with the DCI protocol. Most of the existing DCI technologies 443 like VPLS doesn't provide this support due to split horizon rule 444 running inside the backbone network. 446 In case of VTSD, as TRILL takes care of forming loop-free topology, 447 there is no need to run split horizon in the backbone network. This 448 paves the way for traffic to move from one PW to another PW and 449 eases the formation of service over ring topology in the core, 450 without having any mesh or hub-spoke connections. 452 4. TRILL DCI Operations 454 The below diagram represents a high level overview of TRILL DCI. In 455 the below diagram there are two data centers as DataCenter1 and 456 DataCenter2. DataCenter1 has two core routers (which are also part of 457 the backbone network) as TIR1 and TIR2. Similarly DataCenter2 has 458 only one core router as TIR3. These TIR devices are connected via the 459 backbone network using PSN Tunnels. Pseudowires are configured across 460 these devices. 462 Operations of VTSD is described in draft [VTSD]. There are multiple 463 attachment circuit interfaces which are configured from T2SW to TIR1 464 and TIR2. The T2SW can be part of Layer2 network (Layer2 data center) 465 or TRILL network (TRILL data center). 467 |<-------------- Emulated Service ---------------->| 468 | | 469 | |<------- Pseudo Wire ------>| | 470 | | | | 471 | | |<-- PSN Tunnels-->| | | 472 | V V V V | 473 V AC +----+ +----+ AC V 474 +-----+ | |TIR1|==================| | | +-----+ 475 | |----------|....|..PW1..(active)...|....| | | | 476 | |_ _|T1SW|==================| | | | | 477 | | \ / +----+ |TIR3| | | | 478 | | \ / | | | |T2SW | 479 | | \ / | |----------| | 480 |T2SW | \/ | | | | 481 | | /\ |T1SW| | | 482 | | / \ +----+ | | +-----+ 483 | |_ / \_ |TIR2|==================| | 484 | |----------|....|..PW2..(active)...|....| 485 +-----+ | |T1SW|==================| | 486 AC +----+ +----+ 487 <-----DataCenter1------> <-----DataCenter2------> 489 Figure 1: Data Center DCI 491 4.1. TRILL data center 493 In this case, the VTSD or TIR will form TRILL adjacencies with other 494 VTSDs present in its peer VPTS neighbor, and also with the RBridges 495 present in the TRILL sites (here it is T2SW). As the entire network 496 runs the TRILL protocol (from data center1 to data center2), TRILL 497 will take care of efficiently using the multiple attachment circuit 498 interfaces and PWE3 interfaces. Load balancing of frames between 499 Tier-2 switch and VTSD will be taken care by the TRILL protocol 500 running inside the RBridges (Tier-2 Switch) and VTSD (Tier-1 Switch) 501 as described in draft [VTSD]. 503 4.2. Layer2 data center 505 In case of layer2 data center, as Tier-2 switches are Layer-2 506 Ethernet switches, an Attachment Circuit should work as a normal 507 TRILL Access port. As the data center is not running the TRILL 508 protocol, the mechanism to provide active load balancing for 509 Attachment Circuits differs from the TRILL data center. The 510 subsequent sections describe in detail the operation of TRILL access 511 load-balancing in a layer2 data center. 513 4.2.1. TRILL Access load-balancing 515 This section describes the mechanism to provide active load balancing 516 across Tier1 and Tier2 switch. There are two ways to provide load 517 balancing. 519 a) Using the Appointed Forwarder mechanism [RFC6339bis] (load- 520 balancing based on VLAN), and b) Using TRILL Active-Active Access 521 mechanism [RFC7379] (similar to MC-LAG solution). 523 4.2.1.1. Appointed Forwarder Mechanism 525 The Appointed forwarder mechanism defined in [RFC6439bis] provides a 526 way for actively forwarding the traffic by a RBridge, with the intent 527 that native traffic in each VLAN be handled by at most one RBridge. 528 By default, the DRB (Designated RBridge) on a link is in-charge of 529 native traffic for all VLANs on the link. The DRB may, if it wishes, 530 act as Appointed Forwarder for any VLAN and it may appoint other 531 RBridges that have ports on the link as Appointed Forwarder for one 532 or more VLANs. The DRB may appoint other RBridges on the link with 533 any one of the mechanism described in [RFC6439bis]. Based on the type 534 of attachment circuit (port-based or VLAN based), the DRB chooses the 535 appointed forwarder RBridges/VTSDs, which can distribute the traffic 536 based on the VLANs. 538 4.2.1.1.1. Port-based AC operations. 540 In this case, the VTSDs in TIR1 and TIR2 will form TRILL adjacency 541 via AC ports. If the attachment circuit port can carry N number of 542 end-station service VLANs, then TIR1 and TIR2's VTSDs can equally 543 distribute them using AF Mechanism of TRILL. 545 4.2.1.1.2. VLAN-based AC operations. 547 Likewise in Port-based AC, in this case also the VTSDs in TIR1 and 548 TIR2 will form TRILL adjacency via AC ports. Since only one VLAN end- 549 station service is enabled per VTSD, only one TIR's VTSD can become 550 AF for that VLAN. Hence native traffic can be processed by any one of 551 the AC. 553 4.2.1.2. TRILL Active-Active Access 555 TRILL Active-Active Access is specified in [RFC7379], [Pseudo- 556 Nickname], [Centralized-replication], and [AA-Multi-Attach]. 557 Mechanisms specified in these drafts can be utilized effectively to 558 provide TRILL Active-Active Access. 560 4.2.2. TRILL Pseudowire load-balancing 561 TRILL supports multiple parallel adjacencies between neighbor 562 RBridges. Appendix C of [RFC6325] and section 3.5 of [RFC7177] 563 describes this in detail. Multipathing across such parallel 564 connections can be done for unicast TRILL Data traffic on a per-flow 565 basis, but is restricted for multi-destination traffic. VTSD should 566 also support this functionality. 568 TRILL DCI Pseudowires which belong to the same VTSD instance in a TIR 569 and connect to same remote TIR are referred to as parallel 570 pseudowires. These parallel pseudowires corresponds to a single link 571 inside VTSD. 573 Here all pseudowires should be capable of carrying traffic. 575 |<-------------- Emulated Service ------------------>| 576 | | 577 | |<------- Pseudo Wire ------>| | 578 | | | | 579 | | |<-- PSN Tunnels-->| | | 580 | V V V V | 581 V AC +-----+ PW1 +-----+ AC V 582 +------+ | |VTSD1|==================|VTSD1| | +-------+ 583 | |----------| | | |-------| | 584 |T2SW | | T1SW|==================| T1SW| | T2SW | 585 | | +-----+ PW2 +-----+ | | 586 +------+ +-------+ 587 <-----DataCenter1------> <-----DataCenter2------> 589 Figure 2: Parallel pseudowires with TRILL DCI 591 In above Figure 2, PW1 and PW2 are parallel pseudowires, as these 592 pseudowires belongs to same VTSD and provides a connectivity across 593 same TIRs. 595 This mechanism provides a way for actively increasing and optimally 596 utilizing the bandwidth in the backbone network without affecting the 597 existing traffic. 599 5. MPLS encapsulation and Loop free provider PSN/MPLS 601 TRILL use of MPLS encapsulation over pseudowire is specified in 603 [RFC7173], and requires no changes in the frame format. 605 TRILL DCI doesn't require a Split Horizon mechanism in the backbone 606 PSN network, as TRILL takes care of Loop free topology using 607 Distribution Trees. Any multi-destination frame will traverse a 608 distribution tree path. All distribution trees are calculated based 609 on TRILL base protocol standard [RFC6325] as updated by [RFC7180bis]. 611 6. Frame Processing 613 This section specifies frame processing from data center T2 switch 614 and TIR's 616 6.1. Frame processing between data center T2 switch and TIR. 618 In a multi-homed topology, where in a data center switch (T2SW) is 619 connected to two TIRs, the AF mechanism described in section 4.2.1.1 620 will be used to decide which TIR/VTSD will carry the traffic for a 621 particular VLAN. This is applicable to the case wherein the data 622 center switch is connected to a PE/TIR device via multiple layer 2 623 interfaces to increase the bandwidth. 625 As a frame gets ingressed into a TIR (or any one of the TIR, when the 626 T2SW switches are connected to multiple TIR's) after passing the AF 627 check, the TIR encapsulates the frame with TRILL and MPLS headers and 628 forwards the frame on a pseudowire. If parallel pseudowires are 629 present, the TRILL protocol running in VTSD will select any one of 630 the pseudowires and forward the TRILL Data packet over it. Multi- 631 destination packets will be forwarded on a distribution tree's path 632 [RFC7180bis] 634 Even if any of the paths or links fails between T2SW switch and TIR's 635 or between TIR's, frames can be always be forwarded to any of 636 available UP links or paths through other links/pseudowires. This is 637 one of the key advantage provided by TRILL DCI mechanism. 639 If multiple equal paths are available, TRILL will distribute traffic 640 among all the paths. 642 Also VTSD doesn't depend on the routing or signaling protocol that is 643 running between TIRs, provided there is a PSN tunnel available with 644 proper encapsulation mechanism. 646 Any multi-destination frames, when ingressed to TIR's, will traverse 647 one of the distribution trees, with strong RPF Checks. The Hop count 648 field in TRILL Header will avoid loops or duplication of traffic. 650 6.2. Frame processing between TIR's 651 When a frame arrives from T2SW switch to a VTSD inside TIR, the TRILL 652 protocol will forward the frames to the proper pseudowire. When 653 multiple paths/pseudowires are available between the TIR's then, the 654 shortest path calculated by TRILL protocol will be used. If multiple 655 paths are of equal cost, then TRILL protocol will do ECMP load 656 spreading. If any multi-destination frame gets received by the VTSD 657 through a pseudowire, TRILL will do an RPF check. 659 When a frame arrives from peer TIR/VTSD through a pseudowire, the 660 MPLS header will be de-capsulated and further action will be taken 661 depending on the egress nickname field of TRILL header. If egress 662 nickname is the nickname of this VTSD, MAC address table and AF 663 lookup will be performed and the frame will be forwarded by 664 decapsulating the TRILL header. If egress nickname belongs to some 665 other VTSD, frame will be forwarded on a pseudowire connected to that 666 VTSD by encapsulating with an MPLS header. 668 7. Security Considerations 670 This document does not change the TRILL protocol and thus has minimal 671 security effects. 673 See [RFC6325] for general TRILL Security Considerations. 675 8. IANA Considerations 677 This document requires no IANA actions. 679 RFC Editor: Please delete this section before publication 681 9. References 683 9.1. Normative References 685 [IS-IS] "Intermediate system to Intermediate system routeing 686 information exchange protocol for use in conjunction with 687 the Protocol for providing the Connectionless-mode Network 688 Service (ISO 8473)", ISO/IEC 10589:2002, 2002". 690 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 691 Ghanwani, "Routing Bridges (RBridges): Base Protocol 692 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 693 . 695 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 696 D. Dutt, "Transparent Interconnection of Lots of Links 697 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 698 10.17487/RFC7172, May 2014, . 701 [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 702 "Transparent Interconnection of Lots of Links (TRILL) 703 Transport Using Pseudowires", RFC 7173, DOI 704 10.17487/RFC7173, May 2014, . 707 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 708 3rd, "Transparent Interconnection of Lots of Links (TRILL) 709 Operations, Administration, and Maintenance (OAM) 710 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 711 . 713 [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 714 "Transparent Interconnection of Lots of Links (TRILL): 715 Bidirectional Forwarding Detection (BFD) Support", 716 RFC 7175, DOI 10.17487/RFC7175, May 2014, . 719 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 720 V. Manral, "Transparent Interconnection of Lots of Links 721 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 722 2014, . 724 [RFC7180bis] Eastlake, D., et al, "TRILL: Clarifications, 725 Corrections, and Updates", draft-ietf-trill-rfc7180bis, 726 work in progress. 728 [VTSD] Umair, M., Smiler, K., Eastlake, D., Yong, L., 729 "TRILL Transparent Transport over MPLS" 730 draft-muks-trill-transport-over-mpls, work in 731 progress. 733 [RFC6439bis] Eastlake, D., et al., "TRILL: Appointed Forwarders", 734 draft-ietf-trill-rfc6439bis, work in progress. 736 [IA-APPsub-TLV] Eastlake, D., et al., "TRILL: Interface Addresses 737 APPsub-TLV", draft-ietf-trill-ia-appsubtlv, work in 738 progress. 740 [ARP/ND-Optimization] Li, Y., Eastlake, D., et al., "TRILL: ARP/ND 741 Optimization", draft-ietf-trill-arp-optimization, work in 742 progress. 744 [Address-Flush] Hao, W., Eastlake, D., "TRILL: Address Flush 745 Protocol", draft-hao-trill-address-flush, work in 746 progress. 748 [Pseudo-Nickname] Zhai, H., et al., "TRILL: Pseudo-Nickname for 749 Active-Active Access", draft-ietf-trill-pseudonode- 750 nickname, work in progress. 752 [Centralized-replication] Hao, W., Li, Y., et al., "Centralized 753 Replication for BUM traffic in active-active edge 754 connection", draft-ietf-trill-centralized-replication, 755 work in progress. 757 [AA-Multi-Attach] Zhang, M., et al., "TRILL Active-Active Edge Using 758 Multiple MAC Attachments", draft-ietf-trill-aa-multi- 759 attach, work in progress. 761 9.2. Informative References 763 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 764 Private Network (VPN) Terminology", RFC 4026, DOI 765 10.17487/RFC4026, March 2005, . 768 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 769 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 770 10.17487/RFC4664, September 2006, . 773 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 774 Stokes, "Transparent Interconnection of Lots of Links 775 (TRILL): End Station Address Distribution Information 776 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 777 September 2014, . 779 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 780 "Problem Statement and Goals for Active-Active Connection 781 at the Transparent Interconnection of Lots of Links 782 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 783 2014, . 785 Authors' Addresses 787 Mohammed Umair 788 IPInfusion 789 RMZ Centennial 790 Mahadevapura Post 791 Bangalore - 560048 India 792 EMail: mohammed.umair2@gmail.com 794 Kingston Smiler S 795 IPInfusion 796 RMZ Centennial 797 Mahadevapura Post 798 Bangalore - 560048 India 799 EMail: kingstonsmiler@gmail.com 801 Shaji Ravindranathan 802 IPInfusion 803 3965 Freedom Circle, Suite 200 804 Santa Clara, CA 95054 USA 805 EMail: srnathan2014@gmail.com 807 Lucy Yong 808 Huawei Technologies 809 5340 Legacy Drive 810 Plano, TX 75024 811 USA 812 Phone: +1-469-227-5837 813 EMail: lucy.yong@huawei.com 815 Donald E. Eastlake 3rd 816 Huawei Technologies 817 155 Beaver Street 818 Milford, MA 01757 819 USA 821 Phone: +1-508-333-2270 822 EMail: d3e3e3@gmail.com