idnits 2.17.1 draft-ietf-trill-cmt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 48 characters in excess of 72. -- The draft header indicates that this document updates RFC6325, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 66 has weird spacing: '...lecting desir...' == Line 161 has weird spacing: '...e their forwa...' == Line 319 has weird spacing: '...ing the multi...' == Line 324 has weird spacing: '... trees tree ...' (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 1, 2014) is 3494 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: 'RFC5410' is mentioned on line 540, but not defined == Unused Reference: 'RFC5310' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '8021Q' is defined on line 605, 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' -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 5 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 October 1, 2014 9 Expires: April 2015 11 Coordinated Multicast Trees (CMT) for TRILL 12 draft-ietf-trill-cmt-04.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 October 1, 2014. 37 Copyright Notice 39 Copyright (c) 2014 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 Forwarder provides load sharing based on VLAN with an 57 active-standby model. Mission critical operations such as High 58 Performance Data Centers require active-active load sharing model. 59 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. 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..................................................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........................................7 80 4.2. Announcing virtual RBridge nickname.......................8 81 4.3. Affinity Sub-TLV Capability...............................8 82 5. Theory of operation............................................9 83 5.1. Distribution Tree provisioning............................9 84 5.2. Affinity Sub-TLV advertisement............................9 85 5.3. Affinity sub-TLV conflict resolution......................9 86 5.4. Ingress Multi-Destination Forwarding.....................10 87 5.4.1. Forwarding when n < k...............................10 88 5.5. Egress Multi-Destination Forwarding......................11 89 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv.....11 90 5.5.2. Traffic Arriving on other Trees.....................11 91 5.6. Failure scenarios........................................11 92 5.6.1. Edge RBridge RBk failure............................11 93 5.7. Backward compatibility...................................12 94 6. Security Considerations.......................................12 95 7. IANA Considerations...........................................13 96 8. References....................................................13 97 8.1. Normative References.....................................13 98 8.2. Informative References...................................14 99 9. Acknowledgments...............................................14 100 Appendix A. Change History.......................................15 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 Legacy networks. [RFC6439], 113 provide an active-standby solution, where only one of the RBridges 114 on a link with end stations is in the active forwarding state for 115 end station traffic for any given VLAN. That RBridge is referred to 116 as the Appointed Forwarder (AF). All frames ingressed into a TRILL 117 network via the Appointed Forwarder are encapsulated with the TRILL 118 header with a nickname held by the ingress AF RBridge. Due to 119 failures, re-configurations and other network dynamics, the 120 Appointed Forwarder for any set of VLANs may change. RBridges 121 maintain forwarding tables that contain destination MAC address and 122 VLAN to egress RBridge binding. In the event of AF change, 123 forwarding tables of remote RBridges may continue to forward traffic 124 to the previous AF and that traffic may get discarded at the egress, 125 causing traffic disruption. 127 Mission critical applications such as High Performance Data Centers 128 require resiliency during failover. The active-active forwarding 129 model minimizes impact during failures and maximizes the available 130 network bandwidth. A typical deployment scenario, depicted in Figure 131 1, may have either End Stations and/or Legacy bridges attached to 132 the RBridges. These Legacy devices typically are multi-homed to 133 several RBridges and treat all of the uplinks as a single Multi- 134 Chassis Link Aggregation (MC-LAG) bundle. The Appointed Forwarder 135 designation presented in [RFC6439] requires each of the edge 136 RBridges to exchange TRILL hello packets. By design, an MC-LAG does 137 not forward packets received on one of the member ports of the MC- 138 LAG to other member ports of the same MC-LAG. As a result the AF 139 designation methods presented in [RFC6439] cannot be applied to 140 deployment scenario depicted in Figure 1. [AAprob] 142 An active-active load-sharing model can be implemented by 143 representing the edge of the network connected to a specific edge 144 group of RBridges by a single virtual RBridge. Each virtual RBridge 145 MUST have a nickname unique within its TRILL campus. In addition to 146 an active-active forwarding model, there may be other applications 147 that may requires similar representations. 149 Sections 4.5.1 and 4.5.2 of [RFC6325] as updated by [RFC7180] 150 specify distribution tree calculation and RPF (Reverse Path 151 Forwarding) check calculation algorithms for multi-destination 152 forwarding. These algorithms strictly depend on link cost and parent 153 RBridge priority. As a result, based on the network topology, it may 154 be possible that a given edge RBridge, if it is forwarding on behalf 155 of the virtual RBridge, may not have a candidate multicast tree that 156 the edge RBridge can forward traffic on because there is no tree for 157 which the virtual RBridge is a leaf node from the edge RBridge. 159 In this document we present a method that allows RBridges to specify 160 the path of association for real or virtual child nodes to 161 distribution trees. Remote RBridges calculate their forwarding 162 tables and derive the RPF for distribution trees based on the 163 distribution tree association advertisements. In the absence of 164 distribution tree association advertisements, remote RBridges derive 165 the SPF (Shortest Path First) based on the algorithm specified in 166 section 4.5.1 of [RFC6325] as updated by [RFC7180]. 168 Other applications, beside the above mentioned active-active 169 forwarding model, may utilize the distribution tree association 170 framework presented in this document to associate to distribution 171 trees through a preferred path. 173 This proposal requires presence of multiple multi-destination trees 174 within the TRILL campus and updating all the RBridges in the network 175 to support the new Affinity sub-TLV (Section 3. ). It is expected 176 that both of these requirements will be met as they are control 177 plane changes, and will be common deployment scenarios. In case 178 either of the above two conditions are not met RBridges MUST support 179 a fallback option for interoperability. Since the fallback is 180 expected to be a temporary phenomenon till all RBridges are 181 upgraded, this proposal gives guidelines for such fallbacks, and 182 does not mandate or specify any specific set of fallback options. 184 1.1. Scope and Applicability 186 This document specifies an Affinity sub-TLV to solve associated RPF 187 issues at the active-active edge. Specific methods in this document 188 for making use of the Affinity sub-TLV are applicable where multiple 189 RBridges are connected to an edge device through multi-chassis link 190 aggregation or to a multiport server or some similar arrangement 191 where the RBridges cannot see each other's Hellos. 193 This document DOES NOT provide other required operational elements 194 to implement active-active edge solution, such as methods of multi- 195 chassis link aggregation. Solution specific operational elements are 196 outside the scope of this document and will be covered in solution 197 specific documents. (See, for example [TRILLPN].) 199 Examples provided in this document are for illustration purposes 200 only. 202 1.2. Contributors 204 The work in this document is a result of much passionate discussions 205 and contributions from following individuals. Their names are listed 206 in alphabetical order: 208 Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Mingui Zhang, Radia 209 Perlman, Sam Aldrin, Shivakumar Sundaram and Zhai Hongjun. 211 2. Conventions used in this document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 In this document, these words will appear with that interpretation 218 only when in ALL CAPS. Lower case uses of these words are not to be 219 interpreted as carrying [RFC2119] significance. 221 2.1. Acronyms 223 MC-LAG: . Multi-Chassis Link Aggregation is a solution specific 224 extension to [8021AX], that facilitates connecting group of links 225 from an originating device (A) to a group of discrete devices (B). 226 Device (A) treats, all of the links in a given Multi-Chassis Link 227 Aggregation bundle as a single logical interface and treats all 228 devices in Group (B) as a single logical device for all forwarding 229 purposes. Device (A) does not forward packets receive on Multi- 230 Chassis Link bundle out of the same Multi-Chassis link bundle. Figure 231 1 depicts a specific use case example. 233 CE : Classical 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 RPF: Reverse Path Forwarding. See section 4.5.2 of [RFC6325]. 239 3. The AFFINITY sub-TLV 241 Association of an RBridge to a multi-destination distribution tree 242 through a specific path is accomplished by using a new IS-IS sub- 243 TLV, the Affinity sub-TLV. 245 The AFFINITY sub-TLV appears in Router capability TLVs that are 246 within LSP PDUs, as described in [RFC7176] which specifies the code 247 point and data structure for the Affinity sub-TLV. 249 4. Multicast Tree Construction and Use of Affinity Sub-TLV 251 Figure 1 and Figure 2 below show the reference topology and a 252 logical topology using CMT to provide active-active service. 254 ------------------- 255 / \ 256 | | 257 | TRILL Campus | 258 | | 259 \ / 260 -------------------- 261 | | | 262 ----- | -------- 263 | | | 264 +------+ +------+ +------+ 265 | | | | | | 266 |(RB1) | |(RB2) | | (RBk)| 267 +------+ +------+ +------+ 268 |..| |..| |..| 269 | +----+ | | | | 270 | +---|-----|--|----------+ | 271 | +-|---|-----+ +-----------+ | 272 MC- | | | +------------------+ | | 273 LAG--->(| | |) (| | |) <- MC-LAG 274 +-------+ . . . +-------+ 275 | CE1 | | CEn | 276 | | | | 277 +-------+ +-------+ 279 Figure 1 Reference Topology 281 ------------------ Sample Multicast Tree (T1) 282 / \ 283 | | | 284 | TRILL Campus | o RBn 285 | | / | \ 286 \ / / | ---\ 287 --------------------- RB1o o o 288 | | | | RB2 RBk 289 | | | ---------- | 290 | | | oRBv 291 +------+ +------+ +------+ 292 | | | | | | 293 |(RB1) | |(RB2) | | (RBk)| 294 +------+ +------+ +------+ 295 |..| |..| |..| 296 | +----+ | | | | 297 | +---|--|--|-------------+ | 298 | +-|---|--+ +--------------+ | 299 MC- | | | +------------------+ | | 300 LAG--->(| | |) (| | |) <- MC-LAG 301 +-------+ . . . +-------+ 302 | CE1 | | CEn | 303 | | | | 304 +-------+ +-------+ 306 Figure 2 Example Logical Topology 308 4.1. Update to RFC 6325 310 Section 4.5.1 of [RFC6325], is updated as below: 312 Each RBridge that desires to be the parent RBridge for child Rbridge 313 RBy in a multi-destination distribution tree x announces the desired 314 association using an Affinity sub-TLV. The child RBridge RBy is 315 specified by its nickname (or one of its nicknames if it holds more 316 than one). 318 When such an Affinity sub-TLV is present, the association specified 319 by the affinity sub-TLV MUST be used when constructing the multi 320 destination distribution tree except in case of conflicting Affinity 321 sub-TLV which are resolved as specified in Section 5.3. In the 322 absence of such an Affinity sub-TLV, or if there are any RBridges in 323 the campus that are do not support Affinity sub-TLV, distribution 324 trees tree are calculated as specified in the section 4.5.1 of 325 [RFC6325] as updated by [RFC7180]. Section 4.3. below specifies how 326 to identify RBridges that support Affinity sub-TLV capability. 328 4.2. Announcing virtual RBridge nickname 330 Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge 331 nickname RBv using the Nickname sub-TLV (6), [RFC7176], along with 332 their regular nickname or nicknames. 334 It will be possible for any RBridge to determine that RBv is a 335 virtual RBridge because each RBridge (RB1 to RBk) this appears to be 336 advertising that it is holding RBv is also advertising an Affinity 337 sub-TLV asking that RBv be its child in one or more trees. 339 Virtual RBridges are ignored when determining the distribution 340 tree roots for the campus. 342 All RBridges outside the edge group assume that multi-destination 343 packets with ingress nickname RBv might use any of the distribution 344 trees that any member of the edge group is advertising that it might 345 use. 347 4.3. Affinity Sub-TLV Capability. 349 RBridges that announce the TRILL version sub-TLV [RFC7176] and set 350 the Affinity capability bit (Section 7. ) support the Affinity sub- 351 TLV and calculation of multi-destination distribution trees and RPF 352 checks as specified herein. 354 5. Theory of operation 356 5.1. Distribution Tree provisioning 358 Let's assume there are n distribution trees and k edge RBridges in 359 the edge group of interest. 361 If n >= k 363 Let's assume edge RBridges are sorted in numerically ascending 364 order by SystemID such that RB1 < RB2 < RBk. Each Rbridge in the 365 numerically sorted list is assigned a monotonically increasing 366 number j such that; RB1=0, RB2=1, RBi=j and RBi+1=j+1. 368 Assign each tree to RBi such that tree number { (tree_number) % 369 k}+1 is assigned to RBridge i for tree_number from 1 to n. where n 370 is the number of trees and k is the number of RBridges considered 371 for tree allocation. 373 If n < k 375 Distribution trees are assigned to RBridges RB1 to RBn, using the 376 same algorithm as n >= k case. RBridges RBn+1 to RBk do not 377 participate in active-active forwarding process on behalf of RBv. 379 5.2. Affinity Sub-TLV advertisement 381 Each RBridge in the RB1..RBk domain advertises an Affinity TLV for 382 RBv to be its child. 384 As an example, let's assume that RB1 has chosen Trees t1 and tk+1 on 385 behalf of RBv. 387 RB1 advertises affinity TLV; {RBv, Num of Trees=2, t1, tk+1. 389 Other RBridges in the RB1..RBk edge group follow the same procedure. 391 5.3. Affinity sub-TLV conflict resolution 393 In TRILL, multi-destination distribution trees are built outward 394 from the root. If an RBridges RB1 advertises an Affinity sub-TLV 395 with an AFFINITY RECORD that asks for RBridge RBroot to be its child 396 in a tree rooted at RBroot, that AFFINITY RECORD is in conflict with 397 TRILL distribution tree root determination and MUST be ignored. 399 If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY 400 RECORD that's ask for nickname RBn to be its child in any tree and 401 RB1 is not adjacent to a real or virtual RBridge RBn, that AFFINITY 402 RECORD is in conflict with the campus topology and MUST be ignored. 404 If different RBridges advertise Affinity sub-TLVs that try to 405 associate the same virtual RBridge as their child in the same tree 406 or trees, those Affinity sub-TLVs are in conflict for those trees. 407 The nicknames of the conflicting RBridges are compared to identify 408 which RBridge holds the nickname that is the highest priority to be 409 a tree root, with the System ID as the tie breaker 411 The RBridge with the highest priority to be a tree root will retain 412 the Affinity association. Other RBridges with lower priority to be a 413 tree root MUST stop advertising their conflicting Affinity sub-TLV, 414 re-calculate the multicast tree affinity allocation, and, if 415 appropriate, advertise a new non-conflict Affinity sub-TLV. 417 Similarly, remote RBridges MUST honor the Affinity sub-TLV from the 418 RBridge with the highest priority to be a tree root (use system-ID 419 as the tie-breaker in the event of conflicting priorities) and 420 ignore the conflicting Affinity sub-TLV entries advertised by the 421 RBridges with lower priorities to be tree roots. 423 5.4. Ingress Multi-Destination Forwarding 425 If there is at least one tree on which RBv has affinity via RBk, 426 then RBk performs the following operations, for multi-destination 427 frames received from a CE node: 429 1. Flood to locally attached CE nodes subjected to VLAN and multicast 430 pruning. 431 2. Ingress in the TRILL header and assign ingress RBridge nickname as 432 RBv. (nickname of the virtual RBridge). 433 3. Forward to one of the distribution trees, tree x in which RBv is 434 associated with RBk 436 5.4.1. Forwarding when n < k 438 If there is no tree on which RBv can claim affinity via RBk 439 (Probably because the number of trees n built is less than number 440 of RBridges k announcing the affinity sub-TLV), then RBk MUST fall 441 back to one of the following 443 1. This RBridge should stop forwarding frames from the CE nodes, 444 and should mark that port as disabled. This will prevent CE 445 nodes from forwarding data on to this RBridge, and only use 446 those RBridges which have been assigned a tree - -OR- 447 2. This RBridge tunnels multi-destination frames received from 448 attached native devices to an RBridge RBy that has an assigned 449 tree. The tunnel destination should forward it to the TRILL 450 network, and also to its local access links. (The mechanism of 451 tunneling and handshake between the tunnel source and 452 destination are out of scope of this specification and may be 453 addressed in future documents). 455 Above fallback options may be specific to active-active forwarding 456 scenario. However, as stated above, Affinity sub-TLV may be used in 457 other applications. In such event the application SHOULD specify 458 applicable fallback options. 460 5.5. Egress Multi-Destination Forwarding 462 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv 464 Multi-destination frames arriving at RBk on a Tree x, where RBk has 465 announced the affinity of RBv via x, MUST be forwarded to CE members 466 of RBv that are in the frame's VLAN. Forwarding to other end-nodes 467 and RBridges that are not part of the network represented by the RBv 468 virtual RBridge MUST follow the forwarding rules specified in 469 [RFC6325]. 471 5.5.2. Traffic Arriving on other Trees 473 Multi-destination frames arriving at RBk on a Tree y, where RBk has 474 not announced the affinity of RBv via y, MUST NOT be forwarded to CE 475 members of RBv. Forwarding to other end-nodes and RBridges that are 476 not part of the network represented by the RBv virtual RBridge MUST 477 follow the forwarding rules specified in RFC6325. 479 5.6. Failure scenarios 481 The below failure recovery algorithm is presented only as a 482 guideline. Implementations MAY include other failure recover 483 algorithms. Details of such algorithms are outside the scope of this 484 document. 486 5.6.1. Edge RBridge RBk failure 488 Each of the member RBridges of given virtual RBridge edge group is 489 aware of its member RBridges through configuration or some other 490 method. 492 Member RBridges detect nodal failure of a member RBridge through IS- 493 IS LSP advertisements or lack thereof. 495 Upon detecting a member failure, each of the member RBridges of the 496 RBv edge group start recovery timer T_rec for failed RBridge RBi. If 497 the previously failed RBridge RBi has not recovered after the expiry 498 of timer T_rec, members RBridges perform distribution tree 499 assignment algorithm specified in section 5.1. Each of the member 500 RBridges re-advertises the Affinity sub-TLV with new tree 501 assignment. This action causes the campus to update the tree 502 calculation with the new assignment. 504 RBi upon start-up, starts advertising its presence through IS-IS 505 LSPs and starts a timer T_i. Member RBridges detecting the presence 506 of RBi start a timer T_j. Timer T_j SHOULD be at least < T_i/2. 507 (Please see note below) 509 Upon expiry of timer T_j, member RBridges recalculate the multi- 510 destination tree assignment and advertised the related trees using 511 Affinity sub-TLV. 513 Upon expiry of timer T_i, RBi recalculate the multi-destination tree 514 assignment and advertises the related trees using Affinity TLV. 516 Note: Timers T_i and T_j are designed so as to minimize traffic down 517 time and avoid multi-destination packet duplication. 519 5.7. Backward compatibility 521 Implementations MUST support backward compatibility mode to 522 interoperate with pre Affinity sub-TLV RBRidges in the network. Such 523 backward compatibility operation MAY include, however is not limited 524 to, tunneling and/or active-standby modes of operations. 526 Example: 528 Step 1. Stop using virtual RBridge nickname for traffic ingressing 529 from CE nodes 530 Step 2. Stop performing active-active forwarding. And fall back to 531 active standby forwarding, based on locally defined policies. 532 Definition of such policies is outside the scope of this document 533 and may be addressed in future documents. 535 6. Security Considerations 537 In general, the RBridges in a campus are trusted routers and the 538 authenticity of their link state information (LSPs) and link local 539 PDUs (Hellos, etc.) can be enforced using regular IS-IS security 540 mechanisms [IS-IS] [RFC5410]. This including authenticating the 541 contents of the PDUs used to transport Affinity sub-TLVs. 543 The particular Security Considerations involve with different 544 applications of the Affinity sub-TLV will be covered in the 545 document(s) specifying those applications. 547 For general TRILL Security Considerations, see [RFC6325]. 549 7. IANA Considerations 551 IANA is requested to allocate a capability bit for ''Affinity 552 Supported'' in the TRILL-VER sub-TLV. ''Affinity Supported'' capability 553 bit and Affinity sub-TLV are specified and allocated in [RFC7176]. 555 8. References 557 8.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC5310] Bhatia, M., et.al. ''IS-IS Generic Cryptographic 563 Authentication'', RFC 5310, February 2009. 565 [RFC6325] Perlman, R., et.al. ''RBridge: Base Protocol 566 Specification'', RFC 6325, July 2011. 568 [RFC7177] Eastlake 3rf, D. et.al., ''RBridge: Adjacency'', RFC 7177, 569 May 2014. 571 [RFC6439] Eastlake 3rd, D. et.al., ''RBridge: Appointed Forwarder'', 572 RFC 6439, November 2011. 574 [RFC7176] Eastlake 3rd, D. et.al., ''Transparent Interconnection of 575 Lots of Links (TRILL) Use of IS-IS'', RFC 7176, May 2014. 577 [RFC7180] Eastlake 3rd, D. et.al., ''TRILL: Clarifications, 578 Corrections, and Updates'', RFC 7180, May 2014. 580 [IS-IS] ISO/IEC, ''Intermediate System to Intermediate System Routing 581 Information Exchange Protocol for use in Conjunction with 582 the Protocol for Providing the Connectionless-mode Network 583 Service (ISO 8473)'' ISO/IEC 10589:2002. 585 8.2. Informative References 587 [AAprob] Li, Y. et.al ''Problem Statement and Goals for Active-Active 588 TRILL Edge'', draft-ietf-trill-active-active-connection- 589 prob, in RFC Editor's queue. 591 [RFC6165] Banerjee, A. and Ward, D. ''Extensions to IS-IS for Layer-2 592 Systems'', RFC 6165, April 2011. 594 [RFC4971] Vasseur, JP. et.al ''Intermediate System to Intermediate 595 System (IS-IS) Extensions for Advertising Router 596 Information'', RFC 4971, July 2007. 598 [TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 599 trill-pseudonode-nickname, Work in progress, November 600 2011. 602 [8021AX] IEEE, ''Link Aggregration'', IEEE Std 802.1AX-2008, November 603 2008. 605 [8021Q] IEEE, ''Media Access Control (MAC) Bridges and Virtual 606 Bridged Local Area Networks'', IEEE Std 802.1Q-2011, 607 August, 2011 609 9. Acknowledgments 611 Authors wish to extend their appreciations towards individuals who 612 volunteered to review and comment on the work presented in this 613 document and provided constructive and critical feedback. Specific 614 acknowledgements are due for Anoop Ghanwani, Ronak Desai, and Varun 615 Shah. Very special Thanks to Donald Eastlake for his careful review 616 and constructive comments. 618 This document was prepared using 2-Word-v2.0.template.dot. 620 Appendix A. Change History. 622 From -01 to -02: 624 Replaced all references to ''LAG'' with references to Multi-Chassis 625 (MC-LAG) or the like. 627 Expanded, Security Considerations section. 629 Other editorial changes. 631 From -02 to -03 633 Minor editorial changes 635 From -03 to -04 637 Minor editorial changes and version update. 639 Authors' Addresses 641 Tissa Senevirathne 642 Cisco Systems 643 375 East Tasman Drive, 644 San Jose, CA 95134 646 Phone: +1-408-853-2291 647 Email: tsenevir@cisco.com 649 Janardhanan Pathangi 650 Dell/Force10 Networks 651 Olympia Technology Park, 652 Guindy Chennai 600 032 654 Phone: +91 44 4220 8400 655 Email: Pathangi_Janardhanan@Dell.com 657 Jon Hudson 658 Brocade 659 130 Holger Way 660 San Jose, CA 95134 USA 662 Email: jon.hudson@gmail.com