idnits 2.17.1 draft-ietf-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 -- The document date (March 1, 2017) is 2612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Address-Flush' is mentioned on line 415, but not defined Summary: 2 errors (**), 0 flaws (~~), 2 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 Selvaraj 4 Shaji Ravindranathan 5 IPInfusion 6 Lucy Yong 7 Donald Eastlake 3rd 8 Huawei Technologies 9 Expires: September 2, 2017 March 1, 2017 11 Data Center Interconnect using TRILL 12 14 Abstract 16 This document describes a TRILL based Data Center Interconnect (DCI) 17 solution. TRILL is used inside a data center for providing intra-data 18 center switching optimally by utilizing multiple links. This draft 19 described a way to use TRILL to extend a network across different 20 data center via MPLS service provider network using Virtual TRILL 21 Service/Switch Domain (VTSD) as described in draft [VTSD]. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Date Center Topology . . . . . . . . . . . . . . . . . . . . . 7 64 3. Requirements of DCI Protocol . . . . . . . . . . . . . . . . . 7 65 3.1. Multi-homing with all-active forwarding . . . . . . . . . 8 66 3.2. Effectively scaling the bandwidth by adding more links . . 8 67 3.3. Auto-discovery of services . . . . . . . . . . . . . . . . 9 68 3.4. Delivering Layer 2 and Layer 3 services over the same 69 interface . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.5. BUM traffic optimization . . . . . . . . . . . . . . . . . 9 71 3.6. Control plane learning of MAC . . . . . . . . . . . . . . 10 72 3.7. Virtualisation and isolation of different instances . . . 10 73 3.8. MAC mass-withdrawal . . . . . . . . . . . . . . . . . . . 10 74 3.9. Significantly larger Name-Space in the Overlay (16M 75 segments) . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.10. Extensive OAM Capabilities . . . . . . . . . . . . . . . 11 77 3.11. Supporting Ring topology in the Core Network . . . . . . 11 78 4. TRILL DCI Operations . . . . . . . . . . . . . . . . . . . . . 11 79 4.1. TRILL data center . . . . . . . . . . . . . . . . . . . . . 12 80 4.2. Layer2 data center . . . . . . . . . . . . . . . . . . . . 12 81 4.2.1. TRILL Access load-balancing . . . . . . . . . . . . . 13 82 4.2.1.1. Appointed Forwarder Mechanism . . . . . . . . . . 13 83 4.2.1.2. TRILL Active-Active Access . . . . . . . . . . . . 13 84 4.2.2. TRILL Pseudowire load-balancing . . . . . . . . . . . . 14 85 5. MPLS encapsulation and Loop free provider PSN/MPLS . . . . . . 15 86 6. Frame Processing . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. Frame processing between data center T2 switch and TIR. . . 15 88 6.2. Frame processing between TIR's . . . . . . . . . . . . . . 16 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 96 1 Introduction 98 The IETF Transparent Interconnection of Lots of Links (TRILL) 99 protocol [RFC6325] [RFC7177] [RFC7780] provides transparent 100 forwarding in multi-hop networks with arbitrary topology and link 101 technologies using a header with a hop count and link-state routing. 102 TRILL provides optimal pair-wise forwarding without configuration, 103 safe forwarding even during periods of temporary loops, and support 104 for multipathing of both unicast and multicast traffic. Devices 105 implementing TRILL are called Routing Bridges(RBridges)or TRILL 106 Switches. 108 TRILL is used inside data centers for providing intra-data center 109 switching optimally by utilizing multiple links. Though TRILL usually 110 runs within a data center, there is a need to interconnect various 111 data center sites to provide connectivity across data centers. This 112 draft describes a solution to this problem by using VTSD (Virtual 113 TRILL Switch Domain) as described in the draft [VTSD]. 115 The draft [VTSD] introduces a new terminology called VTSD (Virtual 116 TRILL Switch Domain) and VPTS (Virtual Private TRILL Service). 118 The (Virtual Private TRILL Service) VPTS is a L2 TRILL service, that 119 emulates TRILL service across a Wide Area Network (WAN) over MPLS 120 PWE3. VPTS is similar to what VPLS does for bridge domain. 122 The VTSD [Virtual Trill Switch Domain] is similar to VSI (layer 2 123 bridge) in VPLS model, but this acts as a TRILL RBridge. VTSD is a 124 superset of VSI and must support all the functionality provided by 125 the VSI as defined in [RFC4026]. Along with VSI functionality, the 126 VTSD must be capable of supporting TRILL protocols and form TRILL 127 adjacency. The VTSD must be capable of performing all the operations 128 that a standard TRILL Switch can do. 130 Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that 131 emulates the essential attributes of a service such as Ethernet over 132 a Packet Switched Network (PSN). The required functions of PWs 133 include encapsulating service-specific PDUs arriving at an ingress 134 port, and carrying them across a path or tunnel, managing their 135 timing and order, and any other operations required to emulate the 136 behavior and characteristics of the service as faithfully as 137 possible. 139 The PEs may be connected by an MPLS Label Switched Path (LSP) 140 infrastructure, which provides the benefits of MPLS technology. The 141 PEs may also be connected by an IP network, in which case IP/GRE 142 (Generic Routing Encapsulation) tunneling or other IP tunneling can 143 be used to provide PSN functionality. The detailed procedures in 144 this document are specified only for MPLS LSPs as PSN. However, 145 these procedures are designed to be extensible to use IP tunnels as 146 PSN, which is outside the scope of this document. 148 1.1 Terminology 150 Acronyms used in this document include the following: 152 AC - Attachment Circuit [RFC4664] 154 Access Port - A TRILL switch port configured with 155 the "end station service disable" bit 156 off, as described in 157 Section 4.9.1 of [RFC6325]. 158 All AC's, VTSD ports 159 connected to CE's, should configured 160 as TRILL Access Ports. 162 AF - Appointed Forwarder [RFC6325] 163 and [RFC6439bis]. 165 BUM - Broadcast, Unknown destination Unicast 166 and Multicast 168 Data Label - VLAN or FGL 170 DCI - Data Center Interconnect 172 ECMP - Equal Cost Multi Pathing 174 FGL - Fine-Grained Labeling [RFC7172] 176 IS-IS - Intermediate System to Intermediate 177 System [IS-IS] 179 L2 - Layer 2 181 LAN - Local Area Network 183 Link - The means by which adjacent TRILL 184 switches or VTSD are connected. 185 May be a bridged LAN. 187 MC-LAG - Multi-Chassis Link Aggregation 188 MPLS - Multi-Protocol Label Switching 190 PE - Provider Edge Device 192 PSN - Packet Switched Network 194 PW - Pseudowire [RFC4664] 196 RBridge - An alternative name for TRILL Switch 198 TIR - TRILL Intermediate Router 199 (Devices where Pseudowire starts and 200 Terminates) 202 TRILL - Transparent Interconnection of Lots 203 of Links OR Tunneled Routing in the 204 Link Layer [RFC6325] 206 TRILL Site - A part of a TRILL campus that 207 contains at least one RBridge. 209 TRILL switch - A device implementing the TRILL 210 protocol. An alternative name 211 for an RBridge. 213 Trunk port - A TRILL switch port configured with 214 the "end station service disable" 215 bit on, as described in 216 Section 4.9.1 of [RFC6325]. 217 All pseudowires should 218 be configured as TRILL Trunk port. 220 VLAN - Virtual Local Area Network 222 VPLS - Virtual Private LAN Service 224 VPTS - Virtual Private TRILL Service 226 VSI - Virtual Service Instance [RFC4664] 228 VTSI - Virtual TRILL Service Instance 230 VTSD - Virtual TRILL Switch Domain OR 231 Virtual TRILL Service Domain 232 A Virtual RBridge that segregates 233 one tenant's TRILL database as well 234 as traffic from the other. 236 VTSD-AP - A VTSD TRILL Access port can be a 237 AC or a logical port connected with 238 CE's. it can be a combination of 239 physical port and Data Label. 240 OR just Physical port connected to 241 CE's 243 2. Date Center Topology 245 The reference topology used in this document is a 3 tier traditional 246 topology. Although other topologies may be utilized within the data 247 center, most of such L2 based data centers may be modeled as a 3 tier 248 traditional topology. The reference topology is illustrated in Figure 249 1. To keep terminologies simple and uniform, in this document these 250 layers will be referred to as the Tier-1, Tier-2 and Tier-3 "tiers", 251 and the switches in these layers will be termed as T1SW, T2SW etc. 252 For simplicity reasons, the entire data center topology will not be 253 mentioned in the further sections. Only the relevant nodes will be 254 shown identified by this nomenclature. 256 +------+ +------+ 257 | | | | 258 | T1SW1|--| T1SW2| Tier-1 259 | | | | 260 +------+ +------+ 261 | | | | 262 +---------+ | | +----------+ 263 | +-------+--+------+--+-------+ | 264 | | | | | | | | 265 +----+ +----+ +----+ +----+ 266 | | | | | | | | 267 |T2SW|-----|T2SW| |T2SW|-----|T2SW| Tier-2 268 | | | | | | | | 269 +----+ +----+ +----+ +----+ 270 | | | | 271 | | | | 272 | +-----+ | | +-----+ | 273 +-|T3SW |-+ +-|T3SW |-+ Tier-3 274 +-----+ +-----+ 275 | | | | | | 276 <- Servers -> <- Servers -> 278 Figure 1: Typical data center network topology 280 3. Requirements of DCI Protocol 281 This section describes in detail the primary requirements of a data 282 center interconnect (DCI) solution. 284 3.1. Multi-homing with all-active forwarding 286 One of the primary requirements of a data center DCI layer is to 287 efficiently use all the links in the network by spreading load across 288 them. There are two types of links in the DCI layer. The links that 289 provides connectivity to the data center and the links that provides 290 connectivity to other data center via backbone network. The DCI layer 291 should use both of these link types optimally in an all-active 292 forwarding manner. Typically the links towards the data center will 293 have multiple connectivity towards the peer for providing redundancy 294 in the network. TRILL supports multiple active parallel links 295 between the TRILL RBridges / traditional L2 bridges. For providing 296 active load-balance for traffic from layer2 data center TRILL uses 297 the Appointed Forwarder mechanism. 299 The Appointed forwarder mechanism defined in [RFC6439bis] provides a 300 way to actively forward end station traffic by a RBridge, so that 301 native traffic in each VLAN is handled by at most one RBridge. By 302 default, the DRB (Designated RBridge) on a link is in-charge of 303 native traffic for all VLANs on the link. The DRB may, if it wishes, 304 act as Appointed Forwarder for any VLAN and it may appoint other 305 RBridges that have ports on the link as Appointed Forwarder for one 306 or more VLANs with any one of the mechanism described in 307 [RFC6439bis]. 309 An RBridge on a multi-access link forms adjacency [RFC7177] with 310 other RBridges if the VLAN's configured/enabled between them are 311 common. For example there are four RBridges attached to multi-access 312 link, say RB1, RB2, RB3 and RB4. RB1 and RB2 are configured with 313 single VLAN "VLAN 2", whereas RB3 and RB4 are configured with "VLAN 314 3". Assume that there are no Native VLAN's present on any of the 315 RBridges connected to thw multi-access link. If TRILL Hellos are sent 316 with VLAN Tag enabled on the interface, RB3 and RB4 drops the hellos 317 of RB1 and RB2 (since they are not configured for VLAN 2). Similarly 318 RB1 and RB2 drops the Hellos of RB3 and RB4. This results in RB1 and 319 RB2 not forming adjacency with RB3 and RB4. RB1 and RB2 after 320 electing DRB and forming adjacency between them, will decide about 321 VLAN 2 AF. Similarly RB3 and RB4 decide about the VLAN 3 AF. 323 3.2. Effectively scaling the bandwidth by adding more links 325 As more and more services are deployed over the cloud, there is a 326 clear requirement for easily scaling the bandwidth in the network 327 without disturbing the existing running services. One of the ways to 328 scale the bandwidth is to add a link (either physical or logical) 329 across the devices which require higher bandwidth rate. The same 330 requirement is applicable in the DCI layer for interfaces towards the 331 backbone network and towards the data center. 333 TRILL protocol itself, by design, inherently takes care of this by 334 optimally utilizing multiple links. As PWE3 interface, which provides 335 connectivity to different data center is also part of TRILL network, 336 it is possible to dynamically scale the bandwidth in the backbone 337 network / DCI interface by adding more PWE3 to the VTSD instance. 339 3.3. Auto-discovery of services 341 Auto-discovery of services is one of the primary requirements of data 342 center so DCI services will be provisioned with minimal configuration 343 effort. Currently the TRILL protocol doesn't have any mechanism to 344 discover peer VTSD / TIR nodes. Addressing this question in TRILL is 345 left to a future document. 347 3.4. Delivering Layer 2 and Layer 3 services over the same interface 349 It is desirable to provide a mechanism to advertise both layer 2 and 350 layer 3 forwarding information (Route (IP prefix) in case of L3 and 351 MAC in case of L2) to the peer nodes across the data centers. The 352 control plane way of distributing the forwarding information provides 353 multiple benefits in terms of scale, performance and security. 354 [ARP/ND-Optimization] and [RFC7961] provides mechanism to distribute 355 both MAC and IP information over TRILL network. 357 3.5. BUM traffic optimization 359 A key design consideration in a DCI network is handling BUM 360 (Broadcast, Unknown Unicast and Multicast) traffic. If the BUM 361 packets are handled as in the traditional layer 2 network (by 362 forwarding to all the ports which are part of the same broadcast 363 domain), this will create excessive overhead in the network. TRILL 364 takes care of this issue using the distribution tree and pruning 365 mechanism. 367 Any unknown unicast, multicast or broadcast frames inside VTSD should 368 be processed or forwarded through any one of the distribution tree's 369 path. If any multi-destination frame is received from the wrong 370 pseudowire at a VTSD, the TRILL protocol running in VTSD should 371 perform a RPF check as specified in [RFC7780] and drops the packet. 373 Pruning (VLAN (or FGL) and multicast pruning) mechanism of 374 Distribution Tree as specified in [RFC6325] and [RFC7780] can also be 375 used for forwarding of multi-destination data frames on the branches 376 that are not pruned. 378 Also the ARP/ND-proxy and control plane MAC address learning 379 mechanism mentioned in Sections 3.4 and 3.6 will help the 380 VTSD/RBridges in the network to learn the unicast MAC address from 381 ARP/ND packets. This reduces the unknown unicast flow. 383 3.6. Control plane learning of MAC 385 Learning MAC addresses in the data plane brings the scaling 386 limitations of the devices to the DCI layer. Hence the protocol that 387 provides DCI should provide control plane learning to overcome the 388 data plane learning limitation. Mac address learning through ESADI 389 (End Station Address Distribution Information Protocol) is described 390 in [RFC7357] and requires no changes to the protocol. However the 391 following optional extensions can be provided for controlling the MAC 392 learning mechanism. 394 a) Way to disable remote MAC Addresses learning through data 395 plane and 396 b) Control over the number of MAC Addresses to be advertised 397 to the remote VTSD's. 399 The mechanism to provide these optional extensions is out side the 400 scope of this document. 402 3.7. Virtualisation and isolation of different instances 404 VTSD provides a way to isolate the TRILL link state databases and the 405 forwarding information between different TRILL sites. As VPTS is 406 similar to VPLS, the mac address and the nickname learnt on a 407 particular VPTS is isolated from other VPTS instance in the system. 409 3.8. MAC mass-withdrawal 411 It is desirable in the data center to have a mechanism to flush a set 412 of MAC addresses from the network, in the event of node failures in 413 the network. This Mass MAC-Address withdrawal may also be applicable 414 when there is any movement in the End-stations. Mass MAC-Address 415 withdrawal is specified in draft [Address-Flush] and requires no 416 changes to the protocol. 418 3.9. Significantly larger Name-Space in the Overlay (16M segments) 420 Layer2 DCI technologies can be used to provide overlay connectivity 421 between Top of Rack switches over an IP underlay. When a DCI protocol 422 is used as an overlay, there is a clear requirement to have a larger 423 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 eases 449 the formation of service over ring topology in the core, without 450 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 [RFC6439bis] 520 (load-balancing based on VLAN), and 521 b) Using TRILL Active-Active Access mechanism [RFC7379] 522 (similar to MC-LAG solution). 524 4.2.1.1. Appointed Forwarder Mechanism 526 The Appointed Forwarder mechanism defined in [RFC6439bis] provides a 527 way for actively forwarding the traffic by a RBridge, with the intent 528 that native traffic in each VLAN be handled by at most one RBridge. 529 By default, the DRB (Designated RBridge) on a link is in-charge of 530 native traffic for all VLANs on the link. The DRB may, if it wishes, 531 act as Appointed Forwarder for any VLAN and it may appoint other 532 RBridges that have ports on the link as Appointed Forwarder for one 533 or more VLANs. The DRB may appoint other RBridges on the link with 534 any one of the mechanism described in [RFC6439bis]. Based on the type 535 of attachment circuit (port-based or VLAN based), the DRB chooses the 536 appointed forwarder RBridges/VTSDs, which can distribute the traffic 537 based on the VLANs. 539 4.2.1.1.1. Port-based AC operations. 541 In this case, the VTSDs in TIR1 and TIR2 will form TRILL adjacency 542 via AC ports. If the attachment circuit port can carry N number of 543 end-station service VLANs, then TIR1 and TIR2's VTSDs can equally 544 distribute them using AF Mechanism of TRILL. 546 4.2.1.1.2. VLAN-based AC operations. 548 Likewise in Port-based AC, in this case also the VTSDs in TIR1 and 549 TIR2 will form TRILL adjacency via AC ports. Since only one VLAN end- 550 station service is enabled per VTSD, only one TIR's VTSD can become 551 AF for that VLAN. Hence native traffic can be processed by any one of 552 the AC. 554 4.2.1.2. TRILL Active-Active Access 556 TRILL Active-Active Access is specified in [RFC7781], [RFC7379], 557 [Centralized-replication], and [RFC7782] . Mechanisms specified in 558 these drafts can be utilized effectively to provide TRILL Active- 559 Active Access. 561 4.2.2. TRILL Pseudowire load-balancing 563 TRILL supports multiple parallel adjacencies between neighbor 564 RBridges. Appendix C of [RFC6325] and section 3.5 of [RFC7177] 565 describes this in detail. Multipathing across such parallel 566 connections can be done for unicast TRILL Data traffic on a per-flow 567 basis, but is restricted for multi-destination traffic. VTSD should 568 also support this functionality. 570 TRILL DCI Pseudowires which belong to the same VTSD instance in a TIR 571 and connect to same remote TIR are referred to as parallel 572 pseudowires. These parallel pseudowires corresponds to a single link 573 inside VTSD. 575 Here all pseudowires should be capable of carrying traffic. 577 |<-------------- Emulated Service ------------------>| 578 | | 579 | |<------- Pseudo Wire ------>| | 580 | | | | 581 | | |<-- PSN Tunnels-->| | | 582 | V V V V | 583 V AC +-----+ PW1 +-----+ AC V 584 +------+ | |VTSD1|==================|VTSD1| | +-------+ 585 | |----------| | | |-------| | 586 |T2SW | | T1SW|==================| T1SW| | T2SW | 587 | | +-----+ PW2 +-----+ | | 588 +------+ +-------+ 589 <-----DataCenter1------> <-----DataCenter2------> 591 Figure 2: Parallel pseudowires with TRILL DCI 593 In above Figure 2, PW1 and PW2 are parallel pseudowires, as these 594 pseudowires belongs to same VTSD and provides a connectivity across 595 same TIRs. 597 This mechanism provides a way for actively increasing and optimally 598 utilizing the bandwidth in the backbone network without affecting the 599 existing traffic. 601 5. MPLS encapsulation and Loop free provider PSN/MPLS 603 TRILL use of MPLS encapsulation over pseudowire is specified in 604 [RFC7173], and requires no changes in the frame format. 606 TRILL DCI doesn't require a Split Horizon mechanism in the backbone 607 PSN network, as TRILL takes care of Loop free topology using 608 Distribution Trees. Any multi-destination frame will traverse a 609 distribution tree path. All distribution trees are calculated based 610 on TRILL base protocol standard [RFC6325] as updated by [RFC7780]. 612 6. Frame Processing 614 This section specifies frame processing from data center T2 switch 615 and TIR's 617 6.1. Frame processing between data center T2 switch and TIR. 619 In a multi-homed topology, where in a data center switch (T2SW) is 620 connected to two TIRs, the AF mechanism described in section 4.2.1.1 621 will be used to decide which TIR/VTSD will carry the traffic for a 622 particular VLAN. This is applicable to the case wherein the data 623 center switch is connected to a PE/TIR device via multiple layer 2 624 interfaces to increase the bandwidth. 626 As a frame gets ingressed into a TIR (or any one of the TIR, when the 627 T2SW switches are connected to multiple TIR's) after passing the AF 628 check, the TIR encapsulates the frame with TRILL and MPLS headers and 629 forwards the frame on a pseudowire. If parallel pseudowires are 630 present, the TRILL protocol running in VTSD will select any one of 631 the pseudowires and forward the TRILL Data packet over it. Multi- 632 destination packets will be forwarded on a distribution tree's path 633 [RFC7780] 635 Even if any of the paths or links fails between T2SW switch and TIR's 636 or between TIR's, frames can be always be forwarded to any of 637 available UP links or paths through other links/pseudowires. This is 638 one of the key advantage provided by TRILL DCI mechanism. 640 If multiple equal paths are available, TRILL will distribute traffic 641 among all the paths. 643 Also VTSD doesn't depend on the routing or signaling protocol that is 644 running between TIRs, provided there is a PSN tunnel available with 645 proper encapsulation mechanism. 647 Any multi-destination frames, when ingressed to TIR's, will traverse 648 one of the distribution trees, with strong RPF Checks. The Hop count 649 field in TRILL Header will avoid loops or duplication of traffic. 651 6.2. Frame processing between TIR's 653 When a frame arrives from T2SW switch to a VTSD inside TIR, the TRILL 654 protocol will forward the frames to the proper pseudowire. When 655 multiple paths/pseudowires are available between the TIR's then, the 656 shortest path calculated by TRILL protocol will be used. If multiple 657 paths are of equal cost, then TRILL protocol will do ECMP load 658 spreading. If any multi-destination frame gets received by the VTSD 659 through a pseudowire, TRILL will do an RPF check. 661 When a frame arrives from peer TIR/VTSD through a pseudowire, the 662 MPLS header will be de-capsulated and further action will be taken 663 depending on the egress nickname field of TRILL header. If egress 664 nickname is the nickname of this VTSD, MAC address table and AF 665 lookup will be performed and the frame will be forwarded by 666 decapsulating the TRILL header. If egress nickname belongs to some 667 other VTSD, frame will be forwarded on a pseudowire connected to that 668 VTSD by encapsulating with an MPLS header. 670 7. Security Considerations 672 This document does not change the TRILL protocol and thus has minimal 673 security effects. 675 See [RFC6325] for general TRILL Security Considerations. 677 8. IANA Considerations 679 This document requires no IANA actions. 681 RFC Editor: Please delete this section before publication 683 9. References 685 9.1. Normative References 687 [IS-IS] "Intermediate system to Intermediate system routeing 688 information exchange protocol for use in conjunction with 689 the Protocol for providing the Connectionless-mode Network 690 Service (ISO 8473)", ISO/IEC 10589:2002, 2002". 692 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 693 Ghanwani, "Routing Bridges (RBridges): Base Protocol 694 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 695 . 697 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 698 D. Dutt, "Transparent Interconnection of Lots of Links 699 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 700 10.17487/RFC7172, May 2014, . 703 [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 704 "Transparent Interconnection of Lots of Links (TRILL) 705 Transport Using Pseudowires", RFC 7173, DOI 706 10.17487/RFC7173, May 2014, . 709 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 710 3rd, "Transparent Interconnection of Lots of Links (TRILL) 711 Operations, Administration, and Maintenance (OAM) 712 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 713 . 715 [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 716 "Transparent Interconnection of Lots of Links (TRILL): 717 Bidirectional Forwarding Detection (BFD) Support", 718 RFC 7175, DOI 10.17487/RFC7175, May 2014, . 721 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 722 V. Manral, "Transparent Interconnection of Lots of Links 723 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 724 2014, . 726 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 727 Ghanwani, A., and S. Gupta, "Transparent Interconnection 728 of Lots of Links (TRILL): Clarifications, Corrections, and 729 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 730 . 732 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. 733 Li, "Transparent Interconnection of Lots of Links (TRILL): 734 Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 735 10.17487/RFC7781, February 2016, . 738 [RFC7782] Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. 739 Gupta, "Transparent Interconnection of Lots of Links 740 (TRILL) Active-Active Edge Using Multiple MAC 741 Attachments", RFC 7782, DOI 10.17487/RFC7782, February 742 2016, . 744 [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent 745 Interconnection of Lots of Links (TRILL): Interface 746 Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, 747 August 2016, . 749 [VTSD] Umair, M., Smiler, K., Eastlake, D., Yong, L., 750 "TRILL Transparent Transport over MPLS" 751 draft-ietf-trill-transport-over-mpls, work in 752 progress. 754 [RFC6439bis] Eastlake, D., et al., "TRILL: Appointed Forwarders", 755 draft-ietf-trill-rfc6439bis, work in progress. 757 [ARP/ND-Optimization] Li, Y., Eastlake, D., et al., "TRILL: ARP/ND 758 Optimization", draft-ietf-trill-arp-optimization, work in 759 progress. 761 [Centralized-replication] Hao, W., Li, Y., et al., "Centralized 762 Replication for BUM traffic in active-active edge 763 connection", draft-ietf-trill-centralized-replication, 764 work in progress. 766 9.2. Informative References 768 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 769 Private Network (VPN) Terminology", RFC 4026, DOI 770 10.17487/RFC4026, March 2005, . 773 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 774 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 775 10.17487/RFC4664, September 2006, . 778 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 779 Stokes, "Transparent Interconnection of Lots of Links 780 (TRILL): End Station Address Distribution Information 781 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 782 September 2014, . 784 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 785 "Problem Statement and Goals for Active-Active Connection 786 at the Transparent Interconnection of Lots of Links 787 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 788 2014, . 790 Authors' Addresses 792 Mohammed Umair 793 IPInfusion 794 RMZ Centennial 795 Mahadevapura Post 796 Bangalore - 560048 India 797 EMail: mohammed.umair2@gmail.com 799 Kingston Smiler Selvaraj 800 IPInfusion 801 RMZ Centennial 802 Mahadevapura Post 803 Bangalore - 560048 India 804 EMail: kingstonsmiler@gmail.com 806 Shaji Ravindranathan 807 IPInfusion 808 3965 Freedom Circle, Suite 200 809 Santa Clara, CA 95054 USA 810 EMail: srnathan2014@gmail.com 812 Lucy Yong 813 Huawei Technologies 814 5340 Legacy Drive 815 Plano, TX 75024 816 USA 817 Phone: +1-469-227-5837 818 EMail: lucy.yong@huawei.com 820 Donald E. Eastlake 3rd 821 Huawei Technologies 822 155 Beaver Street 823 Milford, MA 01757 824 USA 825 Phone: +1-508-333-2270 826 EMail: d3e3e3@gmail.com