idnits 2.17.1 draft-zhang-trill-aa-multi-attach-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7176, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2014) is 3602 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) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) == Outdated reference: A later version (-09) exists of draft-ietf-trill-esadi-07 == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Huawei 4 Updates: 7176 Radia Perlman 5 Intel 6 Hongjun Zhai 7 ZTE 8 Muhammad Durrani 9 Mukhtiar Shaikh 10 Brocade 11 Sujay Gupta 12 IP Infusion 13 Expires: December 19, 2014 June 17, 2014 15 TRILL Active-Active Edge Using Multiple MAC Attachments 16 draft-zhang-trill-aa-multi-attach-04.txt 18 Abstract 20 TRILL active-active service provides end stations with flow level 21 load balance and resilience against link failures at the edge of 22 TRILL campuses. 24 This draft specifies a method in which member RBridges in an active- 25 active edge RBridge group use their own nicknames as ingress RBridge 26 nicknames to encapsulate frames from attached end systems. Thus, 27 remote edge RBridges are required to keep multiple locations of one 28 MAC address in one Data Label. Design goals of this specification are 29 discussed in the document. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 4 71 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Incremental Deployable Options . . . . . . . . . . . . . . . . 5 75 4.1. Detail of Option C . . . . . . . . . . . . . . . . . . . . 6 76 4.2. Capability Flags TLV . . . . . . . . . . . . . . . . . . . 8 77 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.1. No MAC Flip-Floping (Normal Unicast Egress) . . . . . . . . 9 79 5.2. Regular Unicast/Multicast Ingress . . . . . . . . . . . . . 9 80 5.3. Right Multicast Egress . . . . . . . . . . . . . . . . . . 9 81 5.3.1. No Duplication (Single Exit Point) . . . . . . . . . . 9 82 5.3.2. No Echo (Split Horizon) . . . . . . . . . . . . . . . . 10 83 5.4. No Black-hole or Triangular Forwarding . . . . . . . . . . 11 84 5.5. Load Balance Towards the AAE . . . . . . . . . . . . . . . 11 85 5.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. TRILL APPsub-TLVs . . . . . . . . . . . . . . . . . . . . . 12 89 7.2. Active Active Flags . . . . . . . . . . . . . . . . . . . . 12 90 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 94 Appendix A. Scenarios on Split Horizon . . . . . . . . . . . . . . 14 95 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 In the TRILL Active-Active Edge (AAE) topology, a Multi-Chassis Link 100 Aggregation Group (MC-LAG) is used to connect multiple RBridges to a 101 switch, vSwitch or multi-port end station. An endnode clump is 102 attached to this switch or vSwitch. It's required that data traffic 103 within a specific VLAN from this endnode clump (including the multi- 104 port end station) can be ingressed and egressed by any of these 105 RBridges simultaneously. End systems in the clump can spread their 106 traffic among these edge RBridges at the flow level. When a link 107 fails, end systems keep using the rest of links in the MC-LAG without 108 waiting for the convergence of TRILL, which provides resilience to 109 link failures. 111 Since a packet from each endnode can be ingressed by any RBridge in 112 the AAE group, a remote edge RBridge may observe multiple attachment 113 points (i.e., egress RBridges) for this endnode identified by its MAC 114 address and Data Label (VLAN or Fine Grained Label (FGL)). This issue 115 is known as the "MAC flip-flopping". Three potential solutions arise 116 to address this issue: 118 1) AAE member RBridges use a pseudonode nickname, instead of their 119 own, as the ingress nickname for end systems attached to the MC- 120 LAG. [CMT] falls within this category. 122 2) AAE member RBridges split work among themselves for which one 123 will be responsible for which MAC addresses. A member RBridge will 124 encapsulate the packet using its own nickname if it is responsible 125 for the source MAC address. Otherwise, if the frame is known 126 unicast, it encapsulates the packet using the nickname of the 127 responsible RBridge; if the frame is multicast, it needs to 128 redirect the packet to its responsible RBridge for encapsulation. 130 3) AAE member RBridges keep using their own nicknames. Remote edge 131 RBridges are required to keep multiple points of attachment per 132 MAC address and Data Label attached to the AAE. 134 The purpose of this document is to develop an approach based on 135 solution 3. Although it focuses on exploring solution 3, the major 136 design goals discussed here are common for all three AAE solutions. 137 Through mirroring the scenarios studied in this draft, other 138 potential solutions may benefit as well. 140 The main body of the document is organized as follows. Section 2 141 lists the acronyms and terminologies. Section 3 gives the overview 142 model. Section 4 provides three options for incremental deployment. 143 Section 5 describes how this approach meets the design goals. 145 2. Acronyms and Terminology 147 2.1. Acronyms 149 AAE: Active-Active Edge 151 Data Label: VLAN or FGL 153 ESADI: End Station Address Distribution Information [ESADI] 155 FGL: Fine Grained Label [RFC7172] 157 IS-IS: Intermediate System to Intermediate System [ISIS] 159 MC-LAG: Multi-Chassis Link Aggregation Group 161 TRILL: TRansparent Interconnection of Lots of Links [RFC6325] 163 vSwitch: A virtual switch such as a hypervisor that also simulates a 164 bridge. 166 2.2. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 Familiarity with [RFC6325], [RFC6439] and [RFC7177] is assumed in 173 this document. 175 3. Overview 176 +-----+ 177 | RB4 | 178 +----------+-----+----------+ 179 | | 180 | | 181 | Rest of campus | 182 | | 183 | | 184 +-+-----+--+-----+--+-----+-+ 185 | RB1 | | RB2 | | RB3 | 186 +-----\ +-----+ /-----+ 187 \ | / 188 \ | / 189 |||MC-LAG1 190 ||| 191 +---+ 192 | B | 193 +---+ 194 H1 H2 H3 H4: VLAN 10 196 Figure 3.1: An example topology for TRILL Active-Active Edge 198 Figure 3.1 shows an example network for TRILL Active-Active Edge. In 199 this figure, endnodes (H1, H2, H3 and H4) are attached to a bridge 200 (B) which communicates with multiple RBridges (RB1, RB2 and RB3) via 201 the MC-LAG. Suppose RB4 is a 'remote' RBridge out of the AAE group in 202 the TRILL campus. This connection model is also applicable to the 203 virtualized environment where the physical bridge can be replaced 204 with a vSwitch while those bare metal hosts are replaced with virtual 205 machines (VM). 207 For a packet received from their attached endnode clumps, a member 208 RBridge of the AAE group always encapsulates it using its own 209 nickname as the ingress nickname no matter whether it's unicast or 210 multicast. 212 The remote RBridge RB4 will see multiple attachments of one MAC from 213 each of the end nodes. 215 4. Incremental Deployable Options 217 Three options are listed below to cope with incremental deployment 218 scenarios. Among them, Option C can be hardware independent. 220 -- Option A 222 A new capability announcement would appear in LSPs. "I can cope 223 with multiple attachments for an endnode". Only if all edge 224 RBridges announce this capability can the AAE group use this 225 approach. For those legacy RBridges who are not capable of coping 226 with multiple endnode attachments, new type TRILL switches will 227 not establish connectivity with them so that they are isolated 228 from these new type TRILL switches. Note only edge RBridges (those 229 that are Appointed Forwarders [RFC6439]) need to be able to 230 support this. It does not affect totally transit RBridges. 232 -- Option B 234 Each edge RBridge in the AAE group ingress data frames from any 235 MC-LAG into a specific TRILL topology [TRILL-MT]. In this way, the 236 topology ID is used as the discriminator of different locations of 237 a specific MAC address at the remote RBridge. TRILL MAY reserve a 238 list of topology IDs to be dedicated to AAE. RBridges that do not 239 support this reserved list MUST NOT establish connectivity with 240 edge RBridges in the AAE group. 242 -- Option C 244 As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of 245 [ESADI], one MAC address may be persistently claimed to be 246 attached to multiple RBridges within the same Data Label in the 247 TRILL ESADI LSPs. For this option, AAE member RBridges make use of 248 TRILL ESADI protocol to distribute multiple attachments of a MAC 249 address. Remote RBridges disable the data plane learning for such 250 multi-attached MAC addresses. 252 4.1. Detail of Option C 254 An RBridge in an AAE MUST advertise all Data Labels enabled for all 255 its attached MC-LAGs. This causes remote RBridges to disable the MAC 256 learning via the TRILL Data packet decapsulation within these Data 257 Labels for this RBridge. The advertisement of such Data Labels can be 258 realized by allocating one reserved flag from the Interested VLANs 259 and Spanning Tree Roots Sub-TLV (Section 2.3.6 of [RFC7176]) and one 260 reserved flag from the Interested Labels and Spanning Tree Roots Sub- 261 TLV (Section 2.3.8 of [RFC7176]). When this flag is set to 1, the 262 originating IS is advertising Data Labels for MC-LAGs rather than 263 plain LAN links. (See Section 7.2) 265 Whenever a MAC from the MC-LAG of this AAE is learned, it needs to be 266 advertised via the ESADI protocol. In its TRILL ESADI LSPs, the 267 originating IS needs to include the identifier of this AAE. Remote 268 RBridges need to know all nicknames of RBridges in this AAE. This is 269 achieved by listening to the "MC-LAG Group RBridges" TRILL APPsub-TLV 270 defined in Section 5.3.2. MAC Reachability TLVs [RFC6165] are 271 composed in a way that each TLV only contains MAC addresses of end 272 nodes attached to a single MC-LAG. Each such TLV is enclosed in a 273 TRILL APPsub-TLV defined as follows. 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type = MC-LAG-GROUP-MAC | (2 bytes) 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Length | (2 bytes) 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 280 | MC-LAG System ID (8 bytes) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 282 | MAC-Reachability TLV (7 + 6*n bytes) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 285 o Type: MC-LAG Group MAC (TRILL APPsub-TLV type #TBD) 287 o Length: The MAC-Reachability TLV [RFC6165] is contained in the 288 value field as a sub-TLV. The total number of bytes contained in 289 the value field is given by 15+6*n. 291 o MC-LAG System ID: The System ID of the MC-LAG as specified in 292 Section 5.3.2 of [802.1AX]. Here, it also serves as the identifier 293 of the AAE. 295 o MAC-Reachability sub-TLV: The MC-LAG-GROUP-MAC APPsub-TLV value 296 contains the MAC-Reachability TLV as a sub-TLV. 298 This MC-LAG-GROUP-MAC APPsub-TLV SHOULD be included in a GENINFO TLV 299 [RFC6823] in the ESADI-LSP. There may be more than one occurrence of 300 such TRILL APPsub-TLV in one ESADI-LSP fragment. 302 For those MAC addresses contained in an MC-LAG-GROUP-MAC APPsub-TLV, 303 this document applies. Otherwise, [ESADI] applies. For example, an 304 AAE member RBridge continues to enclose MAC addresses learned from 305 TRILL Data packet decapsulation in MAC-Reachability TLV as per 306 [RFC6165] and advertise them using the ESADI protocol. 308 When the remote RBridge learns MAC addresses contained in the MC-LAG- 309 GROUP-MAC APPsub-TLV via the ESADI protocol, it always sends the 310 packets destined to these MAC addresses to the closest one (the one 311 to which the remote RBridge has the least cost forwarding path) of 312 those RBridges in the AAE identified by the MC-LAG System ID in the 313 MC-LAG-GROUP-MAC APPsub-TLV. If there are multiple such member 314 RBridges, the ingress RBridge is required to select a unique one in a 315 pseudo-random way as specified in Section 5.3 of [ESADI]. 317 When another RBridge in the same AAE group receives an ESADI-LSP with 318 the MC-LAG-GROUP-MAC APPsub-TLV, it also learns MAC addresses of 319 those end nodes served by the corresponding MC-LAG. These MAC 320 addresses SHOULD be learned as if those end nodes are locally 321 attached to this RBridge itself. 323 An AAE member RBridge MUST use the MC-LAG-GROUP-MAC APPsub-TLV to 324 advertise the MAC addresses learned from a plain local link (a non 325 MC-LAG link) with Data Labels that happen to be covered by the Data 326 Labels of any attached MC-LAG. The reason is that data plane learning 327 within these Data Labels at the remote RBridge has been disabled for 328 this RBridge. 330 4.2. Capability Flags TLV 332 The following Capability Flags TLV will be included in LSP as a TRILL 333 APPsub-TLV of GENINFO-TLV. 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type = MULTI-MAC-ATTACH-CAP | (2 bytes) 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Length | (2 bytes) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |E|H| Reserved | (1 byte) 341 +-+-+-+-+-+-+-+-+ 343 o Type: Multi-MAC-Attach Capability (TRILL APPsub-TLV type #TBD) 345 o Length: Set to 1. 347 o E: When this bit is set, it indicates the originating IS acts as 348 specified in Option C. 350 o H: When this bit is set, it indicates that the originating IS 351 keeps multiple MAC attachments with fast path hardware at the data 352 plane. 354 o Reserved: Reserved flags for future use. These MUST be sent as 355 zero and ignored on receipt. 357 The Capability Flags TRILL APPsub-TLV is used to notify other 358 RBridges whether the originating IS supports the capability indicated 359 by the E and H bits. For example, if E bit is set, it indicates the 360 originating IS will act as defined in Option C. That is, it will 361 disable the data plane MAC learning for AAE RBridges within Data 362 Labels advertised by them while waiting for the TRILL ESADI LSPs to 363 distribute the {MAC, Nickname, Data Label} association. Meanwhile, 364 this RBridge is able to act as an AAE RBridge. It's required to 365 advertise MAC addresses learned from MC-LAGs in TRILL ESADI LSPs 366 using the MC-LAG-GROUP-MAC APPsub-TLV defined in Section 4.1. AAE 367 RBridges supporting Options C won't establish connectivity with 368 remote edge RBridges unless this RBridge has advertised this 369 Capability Flags TLV with E bit set. 371 Capability specification for Option B is out the scope of this 372 document. It may be specified in documents for TRILL multi-topology 373 [TRILL-MT]. 375 5. Design Goals 377 How this specification meets the major design goals of AAE is 378 explored in this section. 380 5.1. No MAC Flip-Floping (Normal Unicast Egress) 382 Since all RBridges talking with the AAE RBridges in the campus are 383 able to keep multiple locations for one MAC address, a MAC address 384 learned from one AAE member will not be overwritten by the same MAC 385 address learned from another AAE member. Although multiple entries 386 for this MAC address will be created, the remote RBridge is required 387 to adhere to a unique one of the locations (see Section 4.1) for each 388 MAC address rather than keep flip-flopping among them. 390 5.2. Regular Unicast/Multicast Ingress 392 MC-LAG guarantees that each frame will be sent upward to the AAE via 393 exactly one uplink. RBridges in the AAE can simply follow the process 394 per [RFC6325] to ingress the frame. For example, each RBridge uses 395 its own nickname as the ingress nickname to encapsulate the packet. 396 In such scenario, each RBridge takes for granted that it is the 397 Appointed Forwarder for the VLANs enabled on the uplink of the MC- 398 LAG. 400 5.3. Right Multicast Egress 402 A fundamental design goal of AAE is that there is no duplication or 403 forwarding loop. 405 5.3.1. No Duplication (Single Exit Point) 407 When multi-destination packets for a specific Data Label are received 408 from the campus, it's important that exactly one RBridge out of the 409 AAE group let through each multicast packet, therefore no duplication 410 happens. Since AAE member RBridges support MC-LAG, they are able to 411 utilize the hashing function of MC-LAG to determine the single exit 412 point. If the output of the hashing function points to the port 413 attached to the receiver RBridge itself (i.e., the packet should be 414 egressed out of this node), it egresses this packet. Otherwise, the 415 packet MUST be dropped. 417 5.3.2. No Echo (Split Horizon) 419 When a multicast frame originated from an MC-LAG is ingressed by an 420 RBridge of an AAE group, forwarded across the TRILL network and then 421 received by another RBridge in the same AAE group, it is important 422 that this RBridge does not egress this frame back to this MC-LAG. 423 Otherwise, it will cause a forwarding loop (echo). The well known 424 'split horizon' technique can be used to eliminate the echo issue. 426 RBridges in the AAE group need to split horizon based on the ingress 427 RBridge nickname plus the VLAN of the TRILL Data packet. They need to 428 set up per port filtering lists consists of the tuple of . Packets with information matching with any entry of 430 the filtering list MUST NOT be egressed out of that port. The 431 information of such filters is obtained by listening to the following 432 "MC-LAG Group RBridges" TRILL APPsub-TLV included in the GENINFO TLV 433 in LSPs. 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type = MC-LAG-GROUP-RBRIDGES | (2 bytes) 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Length | (2 bytes) 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Sender Nickname | (2 bytes) 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 442 | MC-LAG System ID (8 bytes) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 445 o Type: MC-LAG Group RBridges (TRILL APPsub-TLV type #TBD) 447 o Length: 10 449 o Sender Nickname: The nickname of the originating IS. 451 o MC-LAG System ID: The System ID of the MC-LAG as specified in 452 Section 5.3.2 of [802.1AX]. 454 All enabled VLANs MUST be consistent on all ports connected to an MC- 455 LAG. So that the enabled VLANs need not to be included in the MC-LAG 456 Group RBridges TRILL APPsub-TLV. They can be locally obtained from 457 the port attached to that MC-LAG. 459 Through parsing an MC-LAG Group RBridges TRILL APPsub-TLV, the 460 receiver RBridge discovers all other RBridges connected to the same 461 MC-LAG. The Sender Nickname of the originating IS will be added into 462 the filtering list of the port attached to the MC-LAG. For example, 463 RB3 in Figure 3.1 will set up a filtering list looks like {, } on its port attached to MC-LAG1. According to 465 split horizon, TRILL Data packets within VLAN10 ingressed by RB1 or 466 RB2 will not be egressed out of this port. 468 When there are multiple MC-LAGs connected to the same RBridge, these 469 MC-LAGs may have overlap VLANs. Customer may need hosts within these 470 overlap VLANs to communicate with each other. In Appendix A, several 471 scenarios are given to explain how hosts communicate within the 472 overlap VLANs and how split horizon happens. 474 5.4. No Black-hole or Triangular Forwarding 476 If a sub-link of the MC-LAG fails while remote RBridges continue to 477 send packets towards the failed port, a black-hole happens. If the 478 AAE member RBridge with that failed port starts to redirect the 479 packets to other member RBridges for delivery, triangular forwarding 480 forms. 482 The member RBridge attached to the failed sub-link can make use of 483 the ESADI protocol to flush those failure affected MAC addresses as 484 defined in Section 5.2 of [ESADI]. After doing that, no packets will 485 be sent towards the failed port, hence no black-hole will happen. Nor 486 will the member RBridge need to redirect packets to other member 487 RBridges, which may otherwise lead to the triangular forwarding. 489 5.5. Load Balance Towards the AAE 491 Since a remote RBridge can record multiple attachments of one MAC 492 address, this remote RBridge can choose to spread the traffic towards 493 the AAE members. Each of them is able to act as the egress point. By 494 doing this, the forwarding paths may be not limited to the least cost 495 Equal Cost Multiple Paths from the ingress RBridge to the AAE 496 RBridges. The traffic load from the remote RBridge towards the AAE 497 RBridges can be balanced based on a pseudo-random selection method 498 (see Section 4.1). 500 Note that the load balance method adopted at the ingress RBridge is 501 not to replace the load balance mechanism of MC-LAG. These two load 502 spreading mechanisms should take effect separately. 504 5.6. Scalability 506 With option A, multiple attachments need to be recorded for a MAC 507 address learned from AAE RBridges. More entries may be consumed in 508 the MAC table. However, MAC addresses attached to an MC-LAG are only 509 a small part of all MAC addresses in the whole TRILL campus. As a 510 result, the extra space required by the multi-attached MAC addresses 511 can be accommodated by RBridges' unused MAC table space. 513 With option C, remote RBridges will keep the multiple attachments of 514 a MAC address in the ESADI link state databases. While in the MAC 515 table, an RBridge still establishes only one entry for each MAC 516 address. 518 6. Security Considerations 520 Authenticity for contents transported in IS-IS PDUs is enforced using 521 regular IS-IS security mechanism [ISIS][RFC5310]. 523 For security considerations pertain to extensions hosted by TRILL 524 ESADI, see the Security Considerations section in [ESADI]. 526 For general TRILL security considerations, see [RFC6325]. 528 7. IANA Considerations 530 7.1. TRILL APPsub-TLVs 532 IANA is requested to allocate three new types under the Generic 533 Information TLV (#251) [RFC6823] for the TRILL APPsub-TLVs defined in 534 Section 4.1, 4.2 and 5.3.2 of this document. 536 Reference: [ESADI] and [This document] 538 Type Name Reference 539 ---------- -------- ----------- 540 0 Reserved 541 1 ESADI-PARAM [ESADI] 542 2-254 Unassigned 543 255 Reserved 544 256 MC-LAG-GROUP-MAC This document 545 257 MULTI-MAC-ATTACH-CAP This document 546 258 MC-LAG-GROUP-RBRIDGES This document 547 260-65534 Unassigned 548 65535 Reserved 550 7.2. Active Active Flags 552 IANA is requested to allocate two flag bits, as follows: 554 One flag bit appears in the "Interested VLANs and Spanning Tree Roots 555 Sub-TLV". 557 References: [RFC7176], [ESADI] and [This document] 559 Bit Mnemonic Description Reference 560 --- -------- ----------- --------- 561 0 M4 IPv4 Multicast Router Attached [RFC7176] 562 1 M6 IPv6 Multicast Router Attached [RFC7176] 563 2 - Unassigned 564 3 ES ESADI Participation [ESADI] 565 4-15 - (used for a VLAN ID) [RFC7176] 566 16 AA Enabled VLANs for Active-Active This document 567 17-19 - Unassigned 568 20-31 - (used for a VLAN ID) [RFC7176] 570 One flag bit appears in the "Interested Labels and Spanning Tree 571 Roots Sub-TLV". 573 References: [RFC7176], [ESADI] and [This document] 575 Bit Mnemonic Description Reference 576 --- -------- ----------- --------- 577 0 M4 IPv4 Multicast Router Attached [RFC7176] 578 1 M6 IPv6 Multicast Router Attached [RFC7176] 579 2 BM Bit Map [RFC7176] 580 3 ES ESADI Participation [ESADI] 581 4 AA FGLs for Active-Active This document 582 5-7 - Unassigned 584 Acknowledgements 586 Authors would like to thank the comments and suggestions from Erik 587 Nordmark, Fangwei Hu and Liang Xia. 589 8. References 591 8.1. Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 597 Systems", RFC 6165, April 2011. 599 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 600 Ghanwani, "Routing Bridges (RBridges): Base Protocol 601 Specification", RFC 6325, July 2011. 603 [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, 604 "Routing Bridges (RBridges): Appointed Forwarders", RFC 605 6439, November 2011. 607 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 608 Generic Information in IS-IS", RFC 6823, December 20165 610 [RFC7172] D. Eastlake 3rd and M. Zhang and P. Agarwal and R. Perlman 611 and D. Dutt, "Transparent Interconnection of Lots of Links 612 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 614 [RFC7176] D. Eastlake 3rd and T. Senevirathne and A. Ghanwani and D. 615 Dutt and A. Banerjee, "Transparent Interconnection of Lots 616 of Links (TRILL) Use of IS-IS", RFC7176, May 2014. 618 [RFC7177] D. Eastlake 3rd and R. Perlman and A. Ghanwani and H. Yang 619 and V. Manral, "Transparent Interconnection of Lots of 620 Links (TRILL): Adjacency", RFC 7177, May 2014. 622 [ESADI] H. Zhai, F. Hu, et al, "TRILL (Transparent Interconnection 623 of Lots of Links): ESADI (End Station Address Distribution 624 Information) Protocol", draft-ietf-trill-esadi-07.txt, 625 April 2014, Submitted to IESG for Publication. 627 [802.1AX] IEEE, "IEEE Standard for Local and metropolitan area 628 networks / Link Aggregation", 802.1AX-2008, 1 January 2008. 630 8.2. Informative References 632 [CMT] T. Senevirathne, J. Pathangi, et al, "Coordinated Multicast 633 Trees (CMT)for TRILL", draft-ietf-trill-cmt-03.txt, April 634 2014, working in progress. 636 [TRILL-MT] D. Eastlake, M. Zhang, A. Banerjee, V. Manral, "TRILL: 637 Multi-Topology", draft-eastlake-trill-multi-topology, work 638 in progress. 640 [ISIS] ISO, "Intermediate system to Intermediate system routeing 641 information exchange protocol for use in conjunction with 642 the Protocol for providing the Connectionless-mode Network 643 Service (ISO 8473)", ISO/IEC 10589:2002. 645 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 646 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 647 RFC 5310, February 2009. 649 Appendix A. Scenarios on Split Horizon 650 +------------------+ +------------------+ +------------------+ 651 | RB1 | | RB2 | | RB3 | 652 +------------------+ +------------------+ +------------------+ 653 L1 L2 L3 L1 L2 L3 L1 L2 L3 654 VL10~20 VL15~25 VL15 VL10~20 VL15~25 VL15 VL10~20 VL15~25 VL15 655 MC-LAG1 MC-LAG2 LAN MC-LAG1 MC-LAG2 LAN MC-LAG1 MC-LAG2 LAN 656 B1 B2 B10 B1 B2 B20 B1 B2 B30 658 Figure A.1: An example topology to explain split horizon 660 Suppose RB1, RB2 and RB3 are the Active-Active group connecting MC- 661 LAG1 and MC-LAG2. MC-LAG1 and MC-LAG2 are connected to B1 and B2 at 662 their other ends. Suppose all these RBridges use port L1 to connect 663 MC-LAG1 while they use port L2 to connect MC-LAG2. Assume all three 664 L1 enable VLAN 10~20 while all three L2 enable VLAN 15~25. So that 665 there is an overlap of VLAN 15~20. Customer needs hosts in these 666 overlap VLANs to communicate with each other. That is, hosts attached 667 to B1 in VLAN 15~20 need to communicate with hosts attached to B2 in 668 VLAN 15~20. Assume the remote plain RBridge RB4 also has hosts 669 attached in VLAN 15~20 which need to communicate with those hosts in 670 these VLANs attached to B1 and B2. 672 Two major requirements: 674 1. Frames ingressed from RB1-L1-VLAN 15~20 MUST NOT be egressed out 675 of ports RB2-L1 and RB3-L1. At the same time, 677 2. frames coming from B1-VLAN 15~20 should reach B2-VLAN 15~20. 679 RB3 stores the information for split horizon on its ports L1&L2. On 680 L1: {, } and on L2: {, 682 }. 684 Five clarification scenarios: 686 a. Suppose RB2/RB3 receives a TRILL multicast data packet with VLAN 687 15 and ingress nickname RB1. RB3 is the single exit point 688 (selected out according to the hashing function of MC-LAG) for 689 this packet. On ports L1&L2, RB3 has covered 690 , so that RB3 will not egress this 691 packet out of either L1 or L2. Here, _split horizon_ happens. 693 Beforehand, RB1 obtains a native frame on port L1 from B1 in VLAN 694 15. RB1 judges it should be forwarded as a multicast frame across 695 the TRILL campus. Also, RB1 replicates this frame without TRILL 696 encapsulation and sends it out of port L2, so that B2 will get 697 this frame. 699 b. Suppose RB2/RB3 receives a TRILL multicast data packet with VLAN 700 15 and ingress nickname RB4. RB3 is the single exit point. On 701 ports L1&L2, since RB3 has not stored any tuple with ingress_ 702 nickname_RB4, RB3 will decapsulate the packet and egress it out of 703 both ports L1 and L2. So both B1 and B2 will receive the frame. 705 c. Suppose there is a plain LAN link port L3 on RB1, RB2 and RB3, 706 connecting to B10, B20 and B30 respectively. These L3 ports happen 707 to be configured with VLAN 15. On port L3, RB1 and RB3 stores no 708 information of split horizon for AAE (since this port has not been 709 configured to be in any MC-LAG). They will egress the packet 710 ingressed out of RB1-L1 in VLAN 15. 712 d. If a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, port 713 RB1-L3 will not egress packets with ingress-nickname-RB1. RB1 714 needs to replicate this frame without encapsulation and sends it 715 out of port L3. 717 e. If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2 718 cannot egress packets with VLAN 15 and ingress-nickname-RB1, RB1 719 needs to replicate this frame without encapsulation and sends it 720 out of port L1 and L2. 722 Author's Addresses 724 Mingui Zhang 725 Huawei Technologies 726 No.156 Beiqing Rd. Haidian District, 727 Beijing 100095 P.R. China 729 EMail: zhangmingui@huawei.com 731 Radia Perlman 732 Intel Labs 733 2200 Mission College Blvd. 734 Santa Clara, CA 95054-1549 USA 736 Phone: +1-408-765-8080 737 EMail: radia@alum.mit.edu 739 Hongjun Zhai 740 ZTE Corporation 741 68 Zijinghua Road 742 Nanjing 200012 China 744 Phone: +86-25-52877345 745 EMail: zhai.hongjun@zte.com.cn 747 Muhammad Durrani 748 Brocade 750 EMail: mdurrani@brocade.com 752 Mukhtiar Shaikh 753 Brocade 755 EMail: mshaikh@brocade.com 757 Sujay Gupta 758 IP Infusion 759 Bangalore, India 761 EMail: sujayg@ipinfusion.com