idnits 2.17.1 draft-ietf-trill-cmt-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 11, 2015) is 3151 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft Consultant 3 Intended status: Standard Track Janardhanan Pathangi 4 Updates: 6325 DELL 5 Jon Hudson 6 Brocade 8 September 11, 2015 9 Expires: March2016 11 Coordinated Multicast Trees (CMT) for TRILL 12 draft-ietf-trill-cmt-07.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on February 11,2009. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 TRILL facilitates loop free connectivity to non-TRILL networks via 55 choice of an Appointed Forwarder for a set of VLANs. Appointed 56 Forwarders provide load sharing based on VLAN with an active-standby 57 model. High performance applications require an active-active load- 58 sharing model. The Active-Active load-sharing model can be 59 accomplished by representing any given non-TRILL network with a 60 single virtual RBridge. Virtual representation of the non-TRILL 61 network with a single RBridge poses serious challenges in multi- 62 destination RPF (Reverse Path Forwarding) check calculations. This 63 document specifies required enhancements to build Coordinated 64 Multicast Trees (CMT) within the TRILL campus to solve related RPF 65 issues. CMT provides flexibility to RBridges in selecting desired 66 path of association to a given TRILL multi-destination distribution 67 tree. This document updates RFC 6325. 69 Table of Contents 71 1. Introduction...................................................3 72 1.1. Scope and Applicability...................................5 73 1.2. Contributors..............................................5 74 2. Conventions used in this document..............................5 75 2.1. Acronyms and Phrases......................................5 76 3. The AFFINITY sub-TLV...........................................6 77 4. Multicast Tree Construction and Use of Affinity Sub-TLV........6 78 4.1. Update to RFC 6325........................................8 79 4.2. Announcing virtual RBridge nickname.......................9 80 4.3. Affinity Sub-TLV Capability...............................9 81 5. Theory of operation...........................................10 82 5.1. DistributionTree Assignment..............................10 83 5.2. Affinity Sub-TLV advertisement...........................10 84 5.3. Affinity sub-TLV conflict resolution.....................11 85 5.4. Ingress Multi-DestinationForwarding......................11 86 5.4.1. Forwarding when n < k...............................12 87 5.5. Egress Multi-DestinationForwarding.......................12 88 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv.....12 89 5.5.2. Traffic Arriving on other Trees.....................12 90 5.6. Failure scenarios........................................13 91 5.6.1. Edge RBridge RBk failure............................13 93 5.7. Backward compatibility...................................14 94 6. Security Considerations.......................................14 95 7. IANA Considerations...........................................15 96 8. References....................................................15 97 8.1. Normative References.....................................15 98 8.2. Informative References...................................16 99 9. Acknowledgments...............................................16 100 Appendix A. Change History.......................................17 102 1. Introduction 104 TRILL (Transparent Interconnection of Lots of Links) presented in 105 [RFC6325] and other related documents, provides methods of utilizing 106 all available paths for active forwarding, with minimum 107 configuration. TRILL utilizes IS-IS (Intermediate System to 108 Intermediate System [IS-IS]) as its control plane and uses a TRILL 109 header with hop count. 111 [RFC6325], [RFC7177], and [RFC6439] provide methods for 112 interoperability between TRILL and Ethernet end stations and bridged 113 networks. [RFC6439], provide an active-standby solution, where only 114 one of the RBridges on a link with end stations is in the active 115 forwarding state for end station traffic for any given VLAN. That 116 RBridge is referred to as the Appointed Forwarder (AF). All frames 117 ingressed into a TRILL network via the Appointed Forwarder are 118 encapsulated with the TRILL header with a nickname held by the 119 ingress AF RBridge. Due to failures, re-configurations and other 120 network dynamics, the Appointed Forwarder for any set of VLANs may 121 change. RBridges maintain forwarding tables that contain destination 122 MAC address and Data Label (VLAN or Fine Grained Label (FGL)) to 123 egress RBridge binding. In the event of an AF change, forwarding 124 tables of remote RBridges may continue to forward traffic to the 125 previous AF and that traffic may get discarded at the egress, 126 causing traffic disruption. 128 High performance applications require resiliency during failover. 129 The active-active forwarding model minimizes impact during failures 130 and maximizes the available network bandwidth. A typical deployment 131 scenario, depicted in Figure 1, may have either End Stations and/or 132 bridges attached to the RBridges. These devices typically are 133 multi-homed to several RBridges and treat all of the uplinks 134 independently using a Local Active-Active Link Protocol (LAALP 135 [RFC7379]) such as a single Multi-Chassis Link Aggregation (MC-LAG) 136 bundle or Distributed Resilient Network Interconnect [8021AX]. The 137 Appointed Forwarder designation presented in [RFC6439] requires each 138 of the edge RBridges to exchange TRILL Hello packets. By design, an 139 LAALP does not forward packets received on one of the member ports 140 of the MC-LAG to other member ports of the same MC-LAG. As a result 141 the AF designation methods presented in [RFC6439] cannot be applied 142 to deployment scenario depicted in Figure 1. [RFC7379] 144 An active-active load-sharing model can be implemented by 145 representing the edge of the network connected to a specific edge 146 group of RBridges by a single virtual RBridge. Each virtual RBridge 147 MUST have a nickname unique within its TRILL campus. In addition to 148 an active-active forwarding model, there may be other applications 149 that may requires similar representations. 151 Sections 4.5.1 and 4.5.2 of [RFC6325] as updated by [RFC7180bis] 152 specify distribution tree calculation and RPF (Reverse Path 153 Forwarding) check calculation algorithms for multi-destination 154 forwarding. These algorithms strictly depend on link cost and parent 155 RBridge priority. As a result, based on the network topology, it may 156 be possible that a given edge RBridge, if it is forwarding on behalf 157 of the virtual RBridge, may not have a candidate multicast tree that 158 the edge RBridge can forward traffic on because there is no tree for 159 which the virtual RBridge is a leaf node from the edge RBridge. 161 In this document we present a method that allows RBridges to specify 162 the path of association for real or virtual child nodes to 163 distribution trees. Remote RBridges calculate their forwarding 164 tables and derive the RPF for distribution trees based on the 165 distribution tree association advertisements. In the absence of 166 distribution tree association advertisements, remote RBridges derive 167 the SPF(Shortest Path First) based on the algorithm specified in 168 section 4.5.1 of [RFC6325] as updated by [RFC7180bis]. This document 169 updates [RFC6325] by changing, when CMT sub-TLVs are present, 170 [RFC6325] mandatory provisions as to how distribution tree are 171 constructed. 173 Other applications, beside the above mentioned active-active 174 forwarding model, may utilize the distribution tree association 175 framework presented in this document to associate to distribution 176 trees through a preferred path. 178 This proposal requires the presence of multiple multi-destination 179 trees within the TRILL campus and updating all the RBridges in the 180 network to support the new Affinity sub-TLV (Section 3. ). It is 181 expected that both of these requirements will be met as they are 182 control plane changes, and will be common deployment scenarios. In 183 case either of the above two conditions are not met, RBridges MUST 184 support a fallback option for interoperability. Since the fallback 185 is expected to be a temporary phenomenon till all RBridges are 186 upgraded, this proposal gives guidelines for such fallbacks, and 187 does not mandate or specify any specific set of fallback options. 189 1.1. Scope and Applicability 191 This document specifies an Affinity sub-TLV to solve RPF issues at 192 the active-active edge. Specific methods in this document for making 193 use of the Affinity sub-TLV are applicable where a virtual RBridge 194 is used to represent multiple RBridges connected to an edge CE 195 through an LAALP such as multi-chassis link aggregation or some 196 similar arrangement where the RBridges cannot see each other's 197 Hellos. 199 This document DOES NOT provide other required operational elements 200 to implement an active-active edge solution, such as methods of 201 multi-chassis link aggregation. Solution specific operational 202 elements are outside the scope of this document and will be covered 203 in other documents. (See, for example [TRILLPN].) 205 Examples provided in this document are for illustration purposes 206 only. 208 1.2. Contributors 210 The work in this document is a result of much passionate discussions 211 and contributions from following individuals. Their names are listed 212 in alphabetical order: 214 Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Mingui Zhang, Radia 215 Perlman, Sam Aldrin, Shivakumar Sundaram, and Zhai Hongjun. 217 2. Conventions used in this document 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 In this document, these words will appear with that interpretation 224 only when in ALL CAPS. Lower case uses of these words are not to be 225 interpreted as carrying [RFC2119] significance. 227 2.1. Acronyms and Phrases 229 The following acronyms and phrases are used in this document: 231 AF: Appointed Forwarder [RFC6439]. 233 CE: Customer Ethernet device, that is, a device that performs 234 forwarding based on 802.1Q bridging. This also can be end-station or 235 a server. 237 Data Label: VLAN or FGL. 239 FGL: Fine Grained Label [RFC7172]. 241 LAALP: Local Active-Active Link Protocol [RFC7379]. 243 MC-LAG: Multi-Chassis Link Aggregation is a proprietary extension to 244 [8021AX], that facilitates connecting group of links from an 245 originating device (A) to a group of discrete devices (B). Device (A) 246 treats, all of the links in a given Multi-Chassis Link Aggregation 247 bundle as a single logical interface and treats all devices in Group 248 (B) as a single logical device for all forwarding purposes. Device 249 (A) does not forward packets receive on Multi-Chassis Link bundle out 250 of the same Multi-Chassis link bundle. Figure 1 depicts a specific 251 use case example. 253 RPF: Reverse Path Forwarding. See section 4.5.2 of [RFC6325]. 255 3. The AFFINITY sub-TLV 257 Association of an RBridge to a multi-destination distribution tree 258 through a specific path is accomplished by using a new IS-IS sub- 259 TLV, the Affinity sub-TLV. 261 The AFFINITY sub-TLV appears in Router Capability TLVs or MT 262 Capability TLVs that are within LSP PDUs, as described in [RFC7176] 263 which specifies the code point and data structure for the Affinity 264 sub-TLV. 266 4. Multicast Tree Construction and Use of Affinity Sub-TLV 268 Figure 1 and Figure 2 below show the reference topology and a 269 logical topology using CMT to provide active-active service. 271 ------------------- 272 / \ 273 | | 274 | TRILL Campus | 275 | | 276 \ / 277 -------------------- 278 | | | 279 ----- | -------- 280 | | | 281 +------+ +------+ +------+ 282 | | | | | | 283 |(RB1) | |(RB2) | | (RBk)| 284 +------+ +------+ +------+ 285 |..| |..| |..| 286 | +----+ | | | | 287 | +---|-----|--|----------+ | 288 | +-|---|-----+ +-----------+ | 289 MC- | | | +------------------+ | | 290 LAG--->(| | |) (| | |) <- MC-LAG 291 +-------+ . . . +-------+ 292 | CE1 | | CEn | 293 | | | | 294 +-------+ +-------+ 296 Figure 1 Reference Topology 298 ------------------ Sample Multicast Tree (T1) 299 / \ 300 | | | 301 | TRILL Campus | o RBn 302 | | / | \ 303 \ / / | ---\ 304 --------------------- RB1o o o 305 | | | | RB2 RBk 306 | | ---------- | 307 | | | oRBv 308 +------+ +------+ +------+ 309 | | | | | | 310 |(RB1) | |(RB2) | | (RBk)| 311 +------+ +------+ +------+ 312 |..| |..| |..| 313 | +----+ | | | | 314 | +---|--|--|-------------+ | 315 | +-|---|--+ +--------------+ | 316 MC- | | | +------------------+ | | 317 LAG--->(| | |) (| | |)<- MC-LAG 318 +-------+ . . . +-------+ 319 | CE1 | | CEn | 320 | | | | 321 +-------+ +-------+ 323 Figure 2 Example Logical Topology 325 4.1. Update to RFC 6325 327 Section 4.5.1 of [RFC6325], is updated to change the calculation of 328 distribution trees as below: 330 Each RBridge that desires to be the parent RBridge for child 331 RBridge RBy in a multi-destination distribution tree x announces 332 the desired association using an Affinity sub-TLV. The child is 333 specified by its nickname. If an RBridge RB1 advertises an AFFINITY 334 sub-TLV designating one its own nicknames N1 as its ''child'' in some 335 distribution tree, the effect is that that nickname N1 is ignored 336 when constructing other distribution trees. Thus the RPF check will 337 enforce that only RB1 can use nickname N1 to do ingress/egress on 338 tree x. (This has no effect on least cost path calculations for 339 unicast traffic.) 341 When such an Affinity sub-TLV is present, the association specified 342 by the affinity sub-TLV MUST be used when constructing the multi- 343 destination distribution tree except in case of conflicting Affinity 344 sub-TLV, which are resolved as specified in Section 5.3. In the 345 absence of such an Affinity sub-TLV, or if there are any RBridges in 346 the campus that are do not support Affinity sub-TLV, distribution 347 trees are calculated as specified in the section 4.5.1 of [RFC6325] 348 as updated by [RFC7180bis]. Section 4.3. below specifies how to 349 identify RBridges that support Affinity sub-TLV capability. 351 4.2. Announcing virtual RBridge nickname 353 Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge 354 nickname RBv using the Nickname sub-TLV (6), [RFC7176], along with 355 their regular nickname or nicknames. 357 It will be possible for any RBridge to determine that RBv is a 358 virtual RBridge because each RBridge (RB1 to RBk) this appears to be 359 advertising that it is holding RBv is also advertising an Affinity 360 sub-TLV asking that RBv be its child in one or more trees. 362 Virtual RBridges are ignored when determining the distribution 363 tree roots for the campus. 365 All RBridges outside the edge group assume that multi-destination 366 packets with ingress nickname RBv might use any of the distribution 367 trees that any member of the edge group is advertising that it might 368 use. 370 4.3. Affinity Sub-TLV Capability. 372 RBridges that announce the TRILL version sub-TLV [RFC7176] and set 373 the Affinity capability bit (Section 7. ) support the Affinity sub- 374 TLV and calculation of multi-destination distribution trees and RPF 375 checks as specified herein. 377 5. Theory of operation 379 5.1. Distribution Tree Assignment 381 Let's assume there are n distribution trees and k edge RBridges in 382 the edge group of interest. 384 If n >= k 386 Let's assume edge RBridges are sorted in numerically ascending 387 order by IS-IS System ID such that RB1 < RB2 < RBk. Each RBridge 388 in the numerically sorted list is assigned a monotonically 389 increasing number j such that; RB1=0, RB2=1, RBi=j and 390 RBi+1=j+1. (See Section 4.5 of [RFC6325] as modified by Section 391 3.4 of [RFC7180bis] for how tree numbers are determined.) 393 Assign each tree to RBi such that tree number {(tree_number) % 394 k}+1} is assigned to edge group RBridge i for tree_number from1 395 to n. where n is the number of trees, k is the number of edge 396 group RBridges considered for tree allocation, and ''%'' is the 397 integer division remainder operation. 399 If n < k 401 Distribution trees are assigned to edge group RBridges RB1to 402 RBn, using the same algorithm as n >= k case. RBridges RBn+1 to 403 RBk do not participate in active-active forwarding process on 404 behalf of RBv. 406 5.2. Affinity Sub-TLV advertisement 408 Each RBridge in the RB1 through RBk domain advertises an Affinity 409 TLV for RBv to be its child. 411 As an example, let's assume that RB1 has chosen Trees t1 and tk+1 on 412 behalf of RBv. 414 RB1 advertises affinity TLV; {RBv, Num of Trees=2, t1, tk+1. 416 Other RBridges in the RB1 through RBk edge group follow the same 417 procedure. 419 5.3. Affinity sub-TLV conflict resolution 421 In TRILL, multi-destination distribution trees are built outward 422 from the root by each RBridge so that they all derive the same set 423 of distribution trees [RFC6325]. 425 If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY 426 RECORD that asks for RBridge RBroot to be its child in a tree rooted 427 at RBroot, that AFFINITY RECORD is in conflict with TRILL 428 distribution tree root determination and MUST be ignored. 430 If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY 431 RECORD that asks for nickname RBn to be its child in any tree and 432 RB1 is neither adjacent to RBn nor does nickname RBn identify RB1 433 itself, that AFFINITY RECORD is in conflict with the campus 434 topology and MUST be ignored. 436 If different RBridges advertise Affinity sub-TLVs that try to 437 associate the same virtual RBridge as their child in the same tree 438 or trees, those Affinity sub-TLVs are in conflict with each other 439 for those trees. The nicknames of the conflicting RBridges are 440 compared to identify which RBridge holds the nickname that is the 441 highest priority to be a tree root, with the System ID as the 442 tiebreaker 444 The RBridge with the highest priority to be a tree root will retain 445 the Affinity association. Other RBridges with lower priority to be a 446 tree root MUST stop advertising their conflicting Affinity sub-TLV, 447 re-calculate the multicast tree affinity allocation, and, if 448 appropriate, advertise a new non-conflicting Affinity sub-TLV. 450 Similarly, remote RBridges MUST honor the Affinity sub-TLV from the 451 RBridge with the highest priority to be a tree root (use system-ID 452 as the tie-breaker in the event of conflicting priorities) and 453 ignore the conflicting Affinity sub-TLV entries advertised by the 454 RBridges with lower priorities to be tree roots. 456 5.4. Ingress Multi-Destination Forwarding 458 If there is at least one tree on which RBv has affinity via RBk, 459 then RBk performs the following operations, for multi-destination 460 frames received from a CE node: 462 1. Flood to locally attached CE nodes subjected to VLAN and multicast 463 pruning. 465 2. Ingress in the TRILL header and assign ingress RBridge nickname as 466 RBv (nickname of the virtual RBridge). 467 3. Forward to one of the distribution trees, tree x in which RBv is 468 associated with RBk. 470 5.4.1. Forwarding when n < k 472 If there is no tree on which RBv can claim affinity via RBk 473 (probably because the number of trees n built is less than number 474 of RBridges k announcing the affinity sub-TLV), then RBk MUST fall 475 back to one of the following 477 1. This RBridge should stop forwarding frames from the CE nodes, 478 and should mark that port as disabled. This will prevent CE 479 nodes from forwarding data on to this RBridge, and only use 480 those RBridges which have been assigned a tree - -OR- 481 2. This RBridge tunnels multi-destination frames received from 482 attached native devices to an RBridge RBy that has an assigned 483 tree. The tunnel destination should forward it to the TRILL 484 network, and also to its local access links.(The mechanism of 485 tunneling and handshake between the tunnel source and 486 destination are out of scope of this specification and may be 487 addressed in other documents such as [ChannelTunnel].) 489 Above fallback options may be specific to active-active forwarding 490 scenario. However, as stated above, Affinity sub-TLV may be used in 491 other applications. In such event the application SHOULD specify 492 applicable fallback options. 494 5.5. Egress Multi-Destination Forwarding 496 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv 498 Multi-destination frames arriving at RBk on a Tree x, where RBk has 499 announced the affinity of RBv via x, MUST be forwarded to CE members 500 of RBv that are in the frame's VLAN. Forwarding to other end-nodes 501 and RBridges that are not part of the network represented by the RBv 502 virtual RBridge MUST follow the forwarding rules specified in 503 [RFC6325]. 505 5.5.2. Traffic Arriving on other Trees 507 Multi-destination frames arriving at RBk on a Tree y, where RBk has 508 not announced the affinity of RBv via y, MUST NOT be forwarded to CE 509 members of RBv. Forwarding to other end-nodes and RBridges that are 510 not part of the network represented by the RBv virtual RBridge MUST 511 follow the forwarding rules specified in [RFC6325]. 513 5.6. Failure scenarios 515 The below failure recovery algorithm is presented only as a 516 guideline. Implementations MAY include other failure recover 517 algorithms. Details of such algorithms are outside the scope of this 518 document. 520 5.6.1. Edge RBridge RBk failure 522 Each of the member RBridges of a given virtual RBridge edge group is 523 aware of its member RBridges through configuration, LSP 524 advertisements, or some other method. 526 Member RBridges detect nodal failure of a member RBridge through IS- 527 IS LSP advertisements or lack thereof. 529 Upon detecting a member failure, each of the member RBridges of the 530 RBv edge group start recovery timer T_rec for failed RBridge RBi. If 531 the previously failed RBridge RBi has not recovered after the expiry 532 of timer T_rec, members RBridges perform the distribution tree 533 assignment algorithm specified in section 5.1. Each of the member 534 RBridges re-advertises the Affinity sub-TLV with new tree 535 assignment. This action causes the campus to update the tree 536 calculation with the new assignment. 538 RBi, upon start-up, advertises its presence through IS-IS LSPs and 539 starts a timer T_i. Other member RBridges of the edge group, 540 detecting the presence of RBi, start a timer T_j. 542 Upon expiry of timer T_j, other member RBridges recalculate the 543 multi-destination tree assignment and advertised the related trees 544 using Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculate 545 the multi-destination tree assignment and advertises the related 546 trees using Affinity TLV. 548 If the new RBridge in the edge group calculates trees and starts to 549 use one or more before the existing RBridges in the edge group 550 recalculate, there could be duplication of packets (for example 551 more than one edge group RBridge could decapsulate and forward a 552 multi-destination frame on links into the active-active group) or 553 loss of packets (for example due to the Reverse Path Forwarding 554 Check in the rest of the campus if two edge group RBridges are 555 trying to forward on the same tree those from one will be 556 discarded). Alternatively, if the new RBridge in the edge group 557 calculates trees and starts to use one or more after the existing 558 RBridges recalculate, there could be loss of data due to frames 559 arriving at the new RBridge being black holed. Timers T_i and T_j 560 should be initialized to values designed to minimize these problems 561 keeping in mind that, in general, duplicating is a more serious 562 problem than dropping. It is RECOMMENDED that T_j be less than T_i 563 and a reasonable default is 1/2 of T_i. 565 5.7. Backward compatibility 567 Implementations MUST support backward compatibility mode to 568 interoperate with pre Affinity sub-TLV RBridges in the network. Such 569 backward compatibility operation MAY include, however is not limited 570 to, tunneling and/or active-standby modes of operations. 572 Example: 574 Step 1. Stop using virtual RBridge nickname for traffic ingressing 575 from CE nodes 576 Step 2. Stop performing active-active forwarding. And fall back to 577 active standby forwarding, based on locally defined policies. 578 Definition of such policies is outside the scope of this document 579 and may be addressed in other documents. 581 6. Security Considerations 583 In general, the RBridges in a campus are trusted routers and the 584 authenticity of their link state information (LSPs) and link local 585 PDUs (Hellos, etc.) can be enforced using regular IS-IS security 586 mechanisms [IS-IS] [RFC5310]. This including authenticating the 587 contents of the PDUs used to transport Affinity sub-TLVs. 589 The particular Security Considerations involve with different 590 applications of the Affinity sub-TLV will be covered in the 591 document(s) specifying those applications. 593 For general TRILL Security Considerations, see [RFC6325]. 595 7. IANA Considerations 597 This document requires no IANA actions because the ''Affinity 598 Supported'' capability bit and the Affinity sub-TLV have been 599 assigned in [RFC7176]. 601 8. References 603 8.1. Normative References 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997. 608 [RFC5310] Bhatia, M., et.al. ''IS-IS Generic Cryptographic 609 Authentication'', RFC 5310, February 2009. 611 [RFC6325] Perlman, R., et.al. ''RBridge: Base Protocol 612 Specification'', RFC 6325, July 2011. 614 [RFC7177] Eastlake 3rf, D. et.al., ''RBridge: Adjacency'', RFC 7177, 615 May 2014. 617 [RFC6439] Eastlake 3rd, D. et.al., ''RBridge: Appointed Forwarder'', 618 RFC 6439, November 2011. 620 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 621 D. Dutt, "Transparent Interconnection of Lots of Links 622 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 623 . 625 [RFC7176] Eastlake 3rd, D. et.al., ''Transparent Interconnection of 626 Lots of Links (TRILL) Use of IS-IS'', RFC 7176, May 2014. 628 [RFC7180bis] Eastlake 3rd, D. et.al., ''TRILL: Clarifications, 629 Corrections, and Updates'', draft-ietf-trill-rfc7180bis, 630 work in progress. 632 [IS-IS] ISO/IEC, ''Intermediate System to Intermediate System Routing 633 Information Exchange Protocol for use in Conjunction with 634 the Protocol for Providing the Connectionless-mode Network 635 Service (ISO 8473)'' ISO/IEC 10589:2002. 637 8.2. Informative References 639 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 640 "Problem Statement and Goals for Active-Active Connection 641 at the Transparent Interconnection of Lots of Links 642 (TRILL) Edge", RFC 7379, October 2014. 644 [TRILLPN] Zhai, H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 645 trill-pseudonode-nickname, Work in progress, November 646 2011. 648 [8021AX] IEEE, ''Link Aggregation'', IEEE Std 802.1AX-2014, 649 December 2014. 651 [ChannelTunnel] D. Eastlake and Y. Li, "TRILL: RBridge Channel 652 Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 653 in progress. 655 9. Acknowledgments 657 Authors wish to extend their appreciations towards individuals who 658 volunteered to review and comment on the work presented in this 659 document and provided constructive and critical feedback. Specific 660 acknowledgements are due for Anoop Ghanwani, Ronak Desai, Gayle 661 Noble, and Varun Shah. Very special Thanks to Donald Eastlake for 662 his careful review and constructive comments. 664 This document was prepared using 2-Word-v2.0.template.dot. 666 Appendix A. Change History. 668 From -01 to -02: 670 Replaced all references to ''LAG'' with references to Multi-Chassis 671 (MC-LAG) or the like. 673 Expanded, Security Considerations section. 675 Other editorial changes. 677 From -02 to -03 679 Minor editorial changes 681 From -03 to -04 683 Minor editorial changes and version update. 685 From -04 to -05 687 Editorial, reference, and other minor changes based on Document 688 Shepherd review. 689 From -05 to -6 691 Minot editorial fixes. 693 From -06 to -07 695 Clarifications primarily based on AD review. 697 Authors' Addresses 699 Tissa Senevirathne 700 Consultant 702 Email: tsenevir@gmail.com.com 704 Janardhanan Pathangi 705 Dell/Force10 Networks 706 Olympia Technology Park, 707 Guindy Chennai 600 032 709 Phone: +91 44 4220 8400 710 Email:Pathangi_Janardhanan@Dell.com 712 Jon Hudson 713 Brocade 714 130 Holger Way 715 San Jose, CA 95134 USA 716 Phone: +1-408-333-4062 717 Email:jon.hudson@gmail.com