idnits 2.17.1 draft-ietf-trill-cmt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 48 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 164 has weird spacing: '...e their forwa...' == Line 336 has weird spacing: '...ing the multi...' (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 (February 14, 2015) is 3356 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) == Missing Reference: 'ChannelTunnel' is mentioned on line 473, but not defined == Unused Reference: 'RFC7172' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) ** Obsolete normative reference: RFC 7180 (Obsoleted by RFC 7780) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 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 CISCO 3 Intended status: Standard Track Janardhanan Pathangi 4 Updates: 6325 DELL 5 Jon Hudson 6 Brocade 8 February 14, 2015 9 Expires: August 2015 11 Coordinated Multicast Trees (CMT) for TRILL 12 draft-ietf-trill-cmt-05.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 August 14, 2015. 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 legacy 55 networks via choice of an Appointed Forwarder for a set of VLANs. 56 Appointed Forwarders provide load sharing based on VLAN with an 57 active-standby model. Mission critical operations such as High 58 Performance Data Centers require an active-active load sharing 59 model. The Active-Active load-sharing model can be accomplished by 60 representing any given non-TRILL legacy network with a single 61 virtual RBridge. Virtual representation of the non-TRILL legacy 62 network with a single RBridge poses serious challenges in multi- 63 destination RPF (Reverse Path Forwarding) check calculations. This 64 document specifies required enhancements to build Coordinated 65 Multicast Trees (CMT) within the TRILL campus to solve related RPF 66 issues. CMT provides flexibility to RBridges in selecting desired 67 path of association to a given TRILL multi-destination distribution 68 tree. This document updates RFC 6325. 70 Table of Contents 72 1. Introduction...................................................3 73 1.1. Scope and Applicability...................................5 74 1.2. Contributors..............................................5 75 2. Conventions used in this document..............................5 76 2.1. Acronyms and Phrases......................................5 77 3. The AFFINITY sub-TLV...........................................6 78 4. Multicast Tree Construction and Use of Affinity Sub-TLV........6 79 4.1. Update to RFC 6325........................................8 80 4.2. Announcing virtual RBridge nickname.......................9 81 4.3. Affinity Sub-TLV Capability...............................9 82 5. Theory of operation............................................9 83 5.1. Distribution Tree provisioning............................9 84 5.2. Affinity Sub-TLV advertisement...........................10 85 5.3. Affinity sub-TLV conflict resolution.....................10 86 5.4. Ingress Multi-Destination Forwarding.....................11 87 5.4.1. Forwarding when n < k...............................11 88 5.5. Egress Multi-Destination Forwarding......................12 89 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv.....12 90 5.5.2. Traffic Arriving on other Trees.....................12 91 5.6. Failure scenarios........................................12 92 5.6.1. Edge RBridge RBk failure............................12 93 5.7. Backward compatibility...................................13 94 6. Security Considerations.......................................13 95 7. IANA Considerations...........................................14 96 8. References....................................................14 97 8.1. Normative References.....................................14 98 8.2. Informative References...................................15 99 9. Acknowledgments...............................................15 100 Appendix A. Change History.......................................16 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 Mission critical applications such as High Performance Data Centers 129 require resiliency during failover. The active-active forwarding 130 model minimizes impact during failures and maximizes the available 131 network bandwidth. A typical deployment scenario, depicted in Figure 132 1, may have either End Stations and/or Legacy bridges attached to 133 the RBridges. These Legacy devices typically are multi-homed to 134 several RBridges and treat all of the uplinks independently using a 135 Local Active-Active Link Protocol (LAALP [RFC7379]) such as a single 136 Multi-Chassis Link Aggregation (MC-LAG) bundle or Distributed 137 Resilient Network Interconnect [8021AX]. The Appointed Forwarder 138 designation presented in [RFC6439] requires each of the edge 139 RBridges to exchange TRILL Hello packets. By design, an LAALP does 140 not forward packets received on one of the member ports of the MC- 141 LAG to other member ports of the same MC-LAG. As a result the AF 142 designation methods presented in [RFC6439] cannot be applied to 143 deployment scenario depicted in Figure 1. [RFC7379] 145 An active-active load-sharing model can be implemented by 146 representing the edge of the network connected to a specific edge 147 group of RBridges by a single virtual RBridge. Each virtual RBridge 148 MUST have a nickname unique within its TRILL campus. In addition to 149 an active-active forwarding model, there may be other applications 150 that may requires similar representations. 152 Sections 4.5.1 and 4.5.2 of [RFC6325] as updated by [RFC7180] 153 specify distribution tree calculation and RPF (Reverse Path 154 Forwarding) check calculation algorithms for multi-destination 155 forwarding. These algorithms strictly depend on link cost and parent 156 RBridge priority. As a result, based on the network topology, it may 157 be possible that a given edge RBridge, if it is forwarding on behalf 158 of the virtual RBridge, may not have a candidate multicast tree that 159 the edge RBridge can forward traffic on because there is no tree for 160 which the virtual RBridge is a leaf node from the edge RBridge. 162 In this document we present a method that allows RBridges to specify 163 the path of association for real or virtual child nodes to 164 distribution trees. Remote RBridges calculate their forwarding 165 tables and derive the RPF for distribution trees based on the 166 distribution tree association advertisements. In the absence of 167 distribution tree association advertisements, remote RBridges derive 168 the SPF (Shortest Path First) based on the algorithm specified in 169 section 4.5.1 of [RFC6325] as updated by [RFC7180]. This document 170 updates [RFC6325] by changing, when CMT sub-TLVs are present, 171 [RFC6325]'s mandatory provisions as to how distribution tree are 172 constructed. 174 Other applications, beside the above mentioned active-active 175 forwarding model, may utilize the distribution tree association 176 framework presented in this document to associate to distribution 177 trees through a preferred path. 179 This proposal requires presence of multiple multi-destination trees 180 within the TRILL campus and updating all the RBridges in the network 181 to support the new Affinity sub-TLV (Section 3. ). It is expected 182 that both of these requirements will be met as they are control 183 plane changes, and will be common deployment scenarios. In case 184 either of the above two conditions are not met RBridges MUST support 185 a fallback option for interoperability. Since the fallback is 186 expected to be a temporary phenomenon till all RBridges are 187 upgraded, this proposal gives guidelines for such fallbacks, and 188 does not mandate or specify any specific set of fallback options. 190 1.1. Scope and Applicability 192 This document specifies an Affinity sub-TLV to solve RPF issues at 193 the active-active edge. Specific methods in this document for making 194 use of the Affinity sub-TLV are applicable where a virtual RBridge 195 is used to represent multiple RBridges are connected to an edge CE 196 through an LAALP such as multi-chassis link aggregation or some 197 similar arrangement where the RBridges cannot see each other's 198 Hellos. 200 This document DOES NOT provide other required operational elements 201 to implement an active-active edge solution, such as methods of 202 multi-chassis link aggregation. Solution specific operational 203 elements are outside the scope of this document and will be covered 204 in other documents. (See, for example [TRILLPN].) 206 Examples provided in this document are for illustration purposes 207 only. 209 1.2. Contributors 211 The work in this document is a result of much passionate discussions 212 and contributions from following individuals. Their names are listed 213 in alphabetical order: 215 Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Mingui Zhang, Radia 216 Perlman, Sam Aldrin, Shivakumar Sundaram and Zhai Hongjun. 218 2. Conventions used in this document 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 In this document, these words will appear with that interpretation 225 only when in ALL CAPS. Lower case uses of these words are not to be 226 interpreted as carrying [RFC2119] significance. 228 2.1. Acronyms and Phrases 230 The following acronyms and phrases are used in this document: 232 AF: Appointed Forwarder [RFC6439]. 234 CE : Customer Ethernet device, that is a device that performs 235 forwarding based on 802.1Q bridging. This also can be end-station or 236 a server. 238 Data Label: VLAN or FGL. 240 LAALP: Local Active-Active Link Protocol [RFC7379]. 242 MC-LAG: . Multi-Chassis Link Aggregation is a proprietary extension 243 to [8021AX], that facilitates connecting group of links from an 244 originating device (A) to a group of discrete devices (B). Device (A) 245 treats, all of the links in a given Multi-Chassis Link Aggregation 246 bundle as a single logical interface and treats all devices in Group 247 (B) as a single logical device for all forwarding purposes. Device 248 (A) does not forward packets receive on Multi-Chassis Link bundle out 249 of the same Multi-Chassis link bundle. Figure 1 depicts a specific 250 use case example. 252 RPF: Reverse Path Forwarding. See section 4.5.2 of [RFC6325]. 254 3. The AFFINITY sub-TLV 256 Association of an RBridge to a multi-destination distribution tree 257 through a specific path is accomplished by using a new IS-IS sub- 258 TLV, the Affinity sub-TLV. 260 The AFFINITY sub-TLV appears in Router Capability TLVs or MT 261 Capability TLVs that are within LSP PDUs, as described in [RFC7176] 262 which specifies the code point and data structure for the Affinity 263 sub-TLV. 265 4. Multicast Tree Construction and Use of Affinity Sub-TLV 267 Figure 1 and Figure 2 below show the reference topology and a 268 logical topology using CMT to provide active-active service. 270 ------------------- 271 / \ 272 | | 273 | TRILL Campus | 274 | | 275 \ / 276 -------------------- 277 | | | 278 ----- | -------- 279 | | | 280 +------+ +------+ +------+ 281 | | | | | | 282 |(RB1) | |(RB2) | | (RBk)| 283 +------+ +------+ +------+ 284 |..| |..| |..| 285 | +----+ | | | | 286 | +---|-----|--|----------+ | 287 | +-|---|-----+ +-----------+ | 288 MC- | | | +------------------+ | | 289 LAG--->(| | |) (| | |) <- MC-LAG 290 +-------+ . . . +-------+ 291 | CE1 | | CEn | 292 | | | | 293 +-------+ +-------+ 295 Figure 1 Reference Topology 297 ------------------ Sample Multicast Tree (T1) 298 / \ 299 | | | 300 | TRILL Campus | o RBn 301 | | / | \ 302 \ / / | ---\ 303 --------------------- RB1o o o 304 | | | | RB2 RBk 305 | | | ---------- | 306 | | | oRBv 307 +------+ +------+ +------+ 308 | | | | | | 309 |(RB1) | |(RB2) | | (RBk)| 310 +------+ +------+ +------+ 311 |..| |..| |..| 312 | +----+ | | | | 313 | +---|--|--|-------------+ | 314 | +-|---|--+ +--------------+ | 315 MC- | | | +------------------+ | | 316 LAG--->(| | |) (| | |) <- MC-LAG 317 +-------+ . . . +-------+ 318 | CE1 | | CEn | 319 | | | | 320 +-------+ +-------+ 322 Figure 2 Example Logical Topology 324 4.1. Update to RFC 6325 326 Section 4.5.1 of [RFC6325], is updated to change the calculation of 327 distribution trees as below: 329 Each RBridge that desires to be the parent RBridge for child Rbridge 330 RBy in a multi-destination distribution tree x announces the desired 331 association using an Affinity sub-TLV. The child RBridge RBy is 332 specified by its nickname (or one of its nicknames if it holds more 333 than one). 335 When such an Affinity sub-TLV is present, the association specified 336 by the affinity sub-TLV MUST be used when constructing the multi- 337 destination distribution tree except in case of conflicting Affinity 338 sub-TLV which are resolved as specified in Section 5.3. In the 339 absence of such an Affinity sub-TLV, or if there are any RBridges in 340 the campus that are do not support Affinity sub-TLV, distribution 341 trees are calculated as specified in the section 4.5.1 of [RFC6325] 342 as updated by [RFC7180]. Section 4.3. below specifies how to 343 identify RBridges that support Affinity sub-TLV capability. 345 4.2. Announcing virtual RBridge nickname 347 Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge 348 nickname RBv using the Nickname sub-TLV (6), [RFC7176], along with 349 their regular nickname or nicknames. 351 It will be possible for any RBridge to determine that RBv is a 352 virtual RBridge because each RBridge (RB1 to RBk) this appears to be 353 advertising that it is holding RBv is also advertising an Affinity 354 sub-TLV asking that RBv be its child in one or more trees. 356 Virtual RBridges are ignored when determining the distribution 357 tree roots for the campus. 359 All RBridges outside the edge group assume that multi-destination 360 packets with ingress nickname RBv might use any of the distribution 361 trees that any member of the edge group is advertising that it might 362 use. 364 4.3. Affinity Sub-TLV Capability. 366 RBridges that announce the TRILL version sub-TLV [RFC7176] and set 367 the Affinity capability bit (Section 7. ) support the Affinity sub- 368 TLV and calculation of multi-destination distribution trees and RPF 369 checks as specified herein. 371 5. Theory of operation 373 5.1. Distribution Tree provisioning 375 Let's assume there are n distribution trees and k edge RBridges in 376 the edge group of interest. 378 If n >= k 380 Let's assume edge RBridges are sorted in numerically ascending 381 order by IS-IS SystemID such that RB1 < RB2 < RBk. Each Rbridge in 382 the numerically sorted list is assigned a monotonically increasing 383 number j such that; RB1=0, RB2=1, RBi=j and RBi+1=j+1. 385 Assign each tree to RBi such that tree number { (tree_number) % 386 k}+1 } is assigned to RBridge i for tree_number from 1 to n. where 387 n is the number of trees, k is the number of RBridges considered 388 for tree allocation, and ''%'' is the integer division remainder 389 operation. 391 If n < k 393 Distribution trees are assigned to RBridges RB1 to RBn, using the 394 same algorithm as n >= k case. RBridges RBn+1 to RBk do not 395 participate in active-active forwarding process on behalf of RBv. 397 5.2. Affinity Sub-TLV advertisement 399 Each RBridge in the RB1 through RBk domain advertises an Affinity 400 TLV for RBv to be its child. 402 As an example, let's assume that RB1 has chosen Trees t1 and tk+1 on 403 behalf of RBv. 405 RB1 advertises affinity TLV; {RBv, Num of Trees=2, t1, tk+1. 407 Other RBridges in the RB1 through RBk edge group follow the same 408 procedure. 410 5.3. Affinity sub-TLV conflict resolution 412 In TRILL, multi-destination distribution trees are built outward 413 from the root. If an RBridge RB1 advertises an Affinity sub-TLV with 414 an AFFINITY RECORD that asks for RBridge RBroot to be its child in a 415 tree rooted at RBroot, that AFFINITY RECORD is in conflict with 416 TRILL distribution tree root determination and MUST be ignored. 418 If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY 419 RECORD that's ask for nickname RBn to be its child in any tree and 420 RB1 is not adjacent to a real or virtual RBridge RBn, that AFFINITY 421 RECORD is in conflict with the campus topology and MUST be ignored. 423 If different RBridges advertise Affinity sub-TLVs that try to 424 associate the same virtual RBridge as their child in the same tree 425 or trees, those Affinity sub-TLVs are in conflict with each other 426 for those trees. The nicknames of the conflicting RBridges are 427 compared to identify which RBridge holds the nickname that is the 428 highest priority to be a tree root, with the System ID as the 429 tiebreaker 431 The RBridge with the highest priority to be a tree root will retain 432 the Affinity association. Other RBridges with lower priority to be a 433 tree root MUST stop advertising their conflicting Affinity sub-TLV, 434 re-calculate the multicast tree affinity allocation, and, if 435 appropriate, advertise a new non-conflicting Affinity sub-TLV. 437 Similarly, remote RBridges MUST honor the Affinity sub-TLV from the 438 RBridge with the highest priority to be a tree root (use system-ID 439 as the tie-breaker in the event of conflicting priorities) and 440 ignore the conflicting Affinity sub-TLV entries advertised by the 441 RBridges with lower priorities to be tree roots. 443 5.4. Ingress Multi-Destination Forwarding 445 If there is at least one tree on which RBv has affinity via RBk, 446 then RBk performs the following operations, for multi-destination 447 frames received from a CE node: 449 1. Flood to locally attached CE nodes subjected to VLAN and multicast 450 pruning. 451 2. Ingress in the TRILL header and assign ingress RBridge nickname as 452 RBv (nickname of the virtual RBridge). 453 3. Forward to one of the distribution trees, tree x in which RBv is 454 associated with RBk. 456 5.4.1. Forwarding when n < k 458 If there is no tree on which RBv can claim affinity via RBk 459 (probably because the number of trees n built is less than number 460 of RBridges k announcing the affinity sub-TLV), then RBk MUST fall 461 back to one of the following 463 1. This RBridge should stop forwarding frames from the CE nodes, 464 and should mark that port as disabled. This will prevent CE 465 nodes from forwarding data on to this RBridge, and only use 466 those RBridges which have been assigned a tree - -OR- 467 2. This RBridge tunnels multi-destination frames received from 468 attached native devices to an RBridge RBy that has an assigned 469 tree. The tunnel destination should forward it to the TRILL 470 network, and also to its local access links. (The mechanism of 471 tunneling and handshake between the tunnel source and 472 destination are out of scope of this specification and may be 473 addressed in other documents such as [ChannelTunnel].) 475 Above fallback options may be specific to active-active forwarding 476 scenario. However, as stated above, Affinity sub-TLV may be used in 477 other applications. In such event the application SHOULD specify 478 applicable fallback options. 480 5.5. Egress Multi-Destination Forwarding 482 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv 484 Multi-destination frames arriving at RBk on a Tree x, where RBk has 485 announced the affinity of RBv via x, MUST be forwarded to CE members 486 of RBv that are in the frame's VLAN. Forwarding to other end-nodes 487 and RBridges that are not part of the network represented by the RBv 488 virtual RBridge MUST follow the forwarding rules specified in 489 [RFC6325]. 491 5.5.2. Traffic Arriving on other Trees 493 Multi-destination frames arriving at RBk on a Tree y, where RBk has 494 not announced the affinity of RBv via y, MUST NOT be forwarded to CE 495 members of RBv. Forwarding to other end-nodes and RBridges that are 496 not part of the network represented by the RBv virtual RBridge MUST 497 follow the forwarding rules specified in [RFC6325]. 499 5.6. Failure scenarios 501 The below failure recovery algorithm is presented only as a 502 guideline. Implementations MAY include other failure recover 503 algorithms. Details of such algorithms are outside the scope of this 504 document. 506 5.6.1. Edge RBridge RBk failure 508 Each of the member RBridges of given virtual RBridge edge group is 509 aware of its member RBridges through configuration, LSP 510 advertisements, or some other method. 512 Member RBridges detect nodal failure of a member RBridge through IS- 513 IS LSP advertisements or lack thereof. 515 Upon detecting a member failure, each of the member RBridges of the 516 RBv edge group start recovery timer T_rec for failed RBridge RBi. If 517 the previously failed RBridge RBi has not recovered after the expiry 518 of timer T_rec, members RBridges perform the distribution tree 519 assignment algorithm specified in section 5.1. Each of the member 520 RBridges re-advertises the Affinity sub-TLV with new tree 521 assignment. This action causes the campus to update the tree 522 calculation with the new assignment. 524 RBi upon start-up, starts advertising its presence through IS-IS 525 LSPs and starts a timer T_i. Member RBridges detecting the presence 526 of RBi start a timer T_j. Timer T_j SHOULD be at least < T_i/2. 527 (Please see note below) 529 Upon expiry of timer T_j, member RBridges recalculate the multi- 530 destination tree assignment and advertised the related trees using 531 Affinity sub-TLV. 533 Upon expiry of timer T_i, RBi recalculate the multi-destination tree 534 assignment and advertises the related trees using Affinity TLV. 536 Note: Timers T_i and T_j are designed so as to minimize traffic down 537 time and avoid multi-destination packet duplication. 539 5.7. Backward compatibility 541 Implementations MUST support backward compatibility mode to 542 interoperate with pre Affinity sub-TLV RBRidges in the network. Such 543 backward compatibility operation MAY include, however is not limited 544 to, tunneling and/or active-standby modes of operations. 546 Example: 548 Step 1. Stop using virtual RBridge nickname for traffic ingressing 549 from CE nodes 550 Step 2. Stop performing active-active forwarding. And fall back to 551 active standby forwarding, based on locally defined policies. 552 Definition of such policies is outside the scope of this document 553 and may be addressed in other documents. 555 6. Security Considerations 557 In general, the RBridges in a campus are trusted routers and the 558 authenticity of their link state information (LSPs) and link local 559 PDUs (Hellos, etc.) can be enforced using regular IS-IS security 560 mechanisms [IS-IS] [RFC5310]. This including authenticating the 561 contents of the PDUs used to transport Affinity sub-TLVs. 563 The particular Security Considerations involve with different 564 applications of the Affinity sub-TLV will be covered in the 565 document(s) specifying those applications. 567 For general TRILL Security Considerations, see [RFC6325]. 569 7. IANA Considerations 571 This document requires no IANA actions because the ''Affinity 572 Supported'' capability bit and the Affinity sub-TLV have been 573 assigned in [RFC7176]. 575 8. References 577 8.1. Normative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 [RFC5310] Bhatia, M., et.al. ''IS-IS Generic Cryptographic 583 Authentication'', RFC 5310, February 2009. 585 [RFC6325] Perlman, R., et.al. ''RBridge: Base Protocol 586 Specification'', RFC 6325, July 2011. 588 [RFC7177] Eastlake 3rf, D. et.al., ''RBridge: Adjacency'', RFC 7177, 589 May 2014. 591 [RFC6439] Eastlake 3rd, D. et.al., ''RBridge: Appointed Forwarder'', 592 RFC 6439, November 2011. 594 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, 595 "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained 596 Labeling", RFC 7172, May 2014, . 599 [RFC7176] Eastlake 3rd, D. et.al., ''Transparent Interconnection of 600 Lots of Links (TRILL) Use of IS-IS'', RFC 7176, May 2014. 602 [RFC7180] Eastlake 3rd, D. et.al., ''TRILL: Clarifications, 603 Corrections, and Updates'', RFC 7180, May 2014. 605 [IS-IS] ISO/IEC, ''Intermediate System to Intermediate System Routing 606 Information Exchange Protocol for use in Conjunction with 607 the Protocol for Providing the Connectionless-mode Network 608 Service (ISO 8473)'' ISO/IEC 10589:2002. 610 8.2. Informative References 612 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem 613 Statement and Goals for Active-Active Connection at the Transparent 614 Interconnection of Lots of Links (TRILL) Edge", RFC 7379, October 615 2014, . 617 [TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 618 trill-pseudonode-nickname, Work in progress, November 619 2011. 621 [8021AX] IEEE, ''Link Aggregration'', IEEE Std 802.1AX-2014, December 622 2014. 624 9. Acknowledgments 626 Authors wish to extend their appreciations towards individuals who 627 volunteered to review and comment on the work presented in this 628 document and provided constructive and critical feedback. Specific 629 acknowledgements are due for Anoop Ghanwani, Ronak Desai, and Varun 630 Shah. Very special Thanks to Donald Eastlake for his careful review 631 and constructive comments. 633 This document was prepared using 2-Word-v2.0.template.dot. 635 Appendix A. Change History. 637 From -01 to -02: 639 Replaced all references to ''LAG'' with references to Multi-Chassis 640 (MC-LAG) or the like. 642 Expanded, Security Considerations section. 644 Other editorial changes. 646 From -02 to -03 648 Minor editorial changes 650 From -03 to -04 652 Minor editorial changes and version update. 654 From -04 to -05 656 Editorial, reference, and other minor changes based on Document 657 Shepherd review. 659 Authors' Addresses 661 Tissa Senevirathne 662 Cisco Systems 663 375 East Tasman Drive, 664 San Jose, CA 95134 666 Phone: +1-408-853-2291 667 Email: tsenevir@cisco.com 669 Janardhanan Pathangi 670 Dell/Force10 Networks 671 Olympia Technology Park, 672 Guindy Chennai 600 032 674 Phone: +91 44 4220 8400 675 Email: Pathangi_Janardhanan@Dell.com 677 Jon Hudson 678 Brocade 679 130 Holger Way 680 San Jose, CA 95134 USA 682 Email: jon.hudson@gmail.com