idnits 2.17.1 draft-ietf-trill-cmt-09.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 (October 6, 2015) is 3115 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 October 6, 2015 9 Expires: April2016 11 Coordinated Multicast Trees (CMT) for TRILL 12 draft-ietf-trill-cmt-09.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 March 6,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. Distribution Tree Assignment.............................10 83 5.2. Affinity Sub-TLV advertisement...........................10 84 5.3. Affinity sub-TLV conflict resolution.....................11 85 5.4. Ingress Multi-Destination Forwarding.....................11 86 5.4.1. Forwarding when n < k...............................12 87 5.5. Egress Multi-Destination Forwarding......................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...........................................14 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], provides 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 many 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 do not support Affinity sub-TLV, distribution trees 347 are calculated as specified in the section 4.5.1 of [RFC6325] as 348 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 from 1 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 RB1 to 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 - 481 -OR- 482 2. This RBridge tunnels multi-destination frames received from 483 attached native devices to an RBridge RBy that has an assigned 484 tree. The tunnel destination should forward it to the TRILL 485 network, and also to its local access links. (The mechanism of 486 tunneling and handshake between the tunnel source and 487 destination are out of scope of this specification and may be 488 addressed in other documents such as [ChannelTunnel].) 490 Above fallback options may be specific to active-active forwarding 491 scenario. However, as stated above, Affinity sub-TLV may be used in 492 other applications. In such event the application SHOULD specify 493 applicable fallback options. 495 5.5. Egress Multi-Destination Forwarding 497 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv 499 Multi-destination frames arriving at RBk on a Tree x, where RBk has 500 announced the affinity of RBv via x, MUST be forwarded to CE members 501 of RBv that are in the frame's VLAN. Forwarding to other end-nodes 502 and RBridges that are not part of the network represented by the RBv 503 virtual RBridge MUST follow the forwarding rules specified in 504 [RFC6325]. 506 5.5.2. Traffic Arriving on other Trees 508 Multi-destination frames arriving at RBk on a Tree y, where RBk has 509 not announced the affinity of RBv via y, MUST NOT be forwarded to CE 510 members of RBv. Forwarding to other end-nodes and RBridges that are 511 not part of the network represented by the RBv virtual RBridge MUST 512 follow the forwarding rules specified in [RFC6325]. 514 5.6. Failure scenarios 516 The below failure recovery algorithm is presented only as a 517 guideline. Implementations MAY include other failure recover 518 algorithms. Details of such algorithms are outside the scope of this 519 document. 521 5.6.1. Edge RBridge RBk failure 523 Each of the member RBridges of a given virtual RBridge edge group is 524 aware of its member RBridges through configuration, LSP 525 advertisements, or some other method. 527 Member RBridges detect nodal failure of a member RBridge through IS- 528 IS LSP advertisements or lack thereof. 530 Upon detecting a member failure, each of the member RBridges of the 531 RBv edge group start recovery timer T_rec for failed RBridge RBi. If 532 the previously failed RBridge RBi has not recovered after the expiry 533 of timer T_rec, members RBridges perform the distribution tree 534 assignment algorithm specified in section 5.1. Each of the member 535 RBridges re-advertises the Affinity sub-TLV with new tree 536 assignment. This action causes the campus to update the tree 537 calculation with the new assignment. 539 RBi, upon start-up, advertises its presence through IS-IS LSPs and 540 starts a timer T_i. Other member RBridges of the edge group, 541 detecting the presence of RBi, start a timer T_j. 543 Upon expiry of timer T_j, other member RBridges recalculate the 544 multi-destination tree assignment and advertised the related trees 545 using Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculate 546 the multi-destination tree assignment and advertises the related 547 trees using Affinity TLV. 549 If the new RBridge in the edge group calculates trees and starts to 550 use one or more before the existing RBridges in the edge group 551 recalculate, there could be duplication of packets (for example 552 more than one edge group RBridge could decapsulate and forward a 553 multi-destination frame on links into the active-active group) or 554 loss of packets (for example due to the Reverse Path Forwarding 555 Check in the rest of the campus if two edge group RBridges are 556 trying to forward on the same tree those from one will be 557 discarded). Alternatively, if the new RBridge in the edge group 558 calculates trees and starts to use one or more after the existing 559 RBridges recalculate, there could be loss of data due to frames 560 arriving at the new RBridge being black holed. Timers T_i and T_j 561 should be initialized to values designed to minimize these problems 562 keeping in mind that, in general, duplicating is a more serious 563 problem than dropping. It is RECOMMENDED that T_j be less than T_i 564 and a reasonable default is 1/2 of T_i. 566 5.7. Backward compatibility 568 Implementations MUST support backward compatibility mode to 569 interoperate with pre Affinity sub-TLV RBridges in the network. Such 570 backward compatibility operation MAY include, however is not limited 571 to, tunneling and/or active-standby modes of operations. 573 Example: 575 Step 1. Stop using virtual RBridge nickname for traffic ingressing 576 from CE nodes 577 Step 2. Stop performing active-active forwarding. And fall back to 578 active standby forwarding, based on locally defined policies. 579 Definition of such policies is outside the scope of this document 580 and may be addressed in other documents. 582 6. Security Considerations 584 In general, the RBridges in a campus are trusted routers and the 585 authenticity of their link state information (LSPs) and link local 586 PDUs (Hellos, etc.) can be enforced using regular IS-IS security 587 mechanisms [IS-IS] [RFC5310]. This including authenticating the 588 contents of the PDUs used to transport Affinity sub-TLVs. 590 The particular Security Considerations involved with different 591 applications of the Affinity sub-TLV will be covered in the 592 document(s) specifying those applications. 594 For general TRILL Security Considerations, see [RFC6325]. 596 7. IANA Considerations 597 This document serves as the reference for "TRILL-VER Sub-TLV 598 Capability Flags" registration "Affinity sub-TLV support." (bit 0) 599 so that reference should be updated when this document is published 600 as an RFC. 602 This document mentions "Sub-TLVs for TLV 144" registration 603 "AFFINITY" (value 17), but should not be listed as a reference for 604 that registration which should remain [RFC7176]. 606 8. References 608 8.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC5310] Bhatia, M., et.al. ''IS-IS Generic Cryptographic 614 Authentication'', RFC 5310, February 2009. 616 [RFC6325] Perlman, R., et.al. ''RBridge: Base Protocol 617 Specification'', RFC 6325, July 2011. 619 [RFC7177] Eastlake 3rf, D. et.al., ''RBridge: Adjacency'', RFC 7177, 620 May 2014. 622 [RFC6439] Eastlake 3rd, D. et.al., ''RBridge: Appointed Forwarder'', 623 RFC 6439, November 2011. 625 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 626 D. Dutt, "Transparent Interconnection of Lots of Links 627 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 628 . 630 [RFC7176] Eastlake 3rd, D. et.al., ''Transparent Interconnection of 631 Lots of Links (TRILL) Use of IS-IS'', RFC 7176, May 2014. 633 [RFC7180bis] Eastlake 3rd, D. et.al., ''TRILL: Clarifications, 634 Corrections, and Updates'', draft-ietf-trill-rfc7180bis, 635 work in progress. 637 [IS-IS] ISO/IEC, ''Intermediate System to Intermediate System Routing 638 Information Exchange Protocol for use in Conjunction with 639 the Protocol for Providing the Connectionless-mode Network 640 Service (ISO 8473)'' ISO/IEC 10589:2002. 642 8.2. Informative References 644 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 645 "Problem Statement and Goals for Active-Active Connection 646 at the Transparent Interconnection of Lots of Links (TRILL) 647 Edge", RFC 7379, October 2014. 649 [TRILLPN] Zhai, H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 650 trill-pseudonode-nickname, Work in progress, November 651 2011. 653 [8021AX] IEEE, ''Link Aggregation'', IEEE Std 802.1AX-2014, 654 December 2014. 656 [ChannelTunnel] D. Eastlake and Y. Li, "TRILL: RBridge Channel 657 Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 658 in progress. 660 9. Acknowledgments 662 Authors wish to extend their appreciations towards individuals who 663 volunteered to review and comment on the work presented in this 664 document and provided constructive and critical feedback. Specific 665 acknowledgements are due for Anoop Ghanwani, Ronak Desai, Gayle 666 Noble, and Varun Shah. Very special Thanks to Donald Eastlake for 667 his careful review and constructive comments. 669 This document was prepared using 2-Word-v2.0.template.dot. 671 Appendix A. Change History. 673 From -01 to -02: 675 Replaced all references to ''LAG'' with references to Multi-Chassis 676 (MC-LAG) or the like. 678 Expanded, Security Considerations section. 680 Other editorial changes. 682 From -02 to -03 684 Minor editorial changes 686 From -03 to -04 688 Minor editorial changes and version update. 690 From -04 to -05 692 Editorial, reference, and other minor changes based on Document 693 Shepherd review. 694 From -05 to -6 696 Minot editorial fixes. 698 From -06 to -07 700 Clarifications primarily based on AD review. 702 Authors' Addresses 704 Tissa Senevirathne 705 Consultant 707 Email: tsenevir@gmail.com 709 Janardhanan Pathangi 710 Dell/Force10 Networks 711 Olympia Technology Park, 712 Guindy Chennai 600 032 714 Phone: +91 44 4220 8400 715 Email:Pathangi_Janardhanan@Dell.com 717 Jon Hudson 718 Brocade 719 130 Holger Way 720 San Jose, CA 95134 USA 722 Phone: +1-408-333-4062 723 Email:jon.hudson@gmail.com