idnits 2.17.1 draft-eastlake-trill-rbridge-multi-topo-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates 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 (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 (July 16, 2012) is 4302 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Mingui Zhang 3 Updates: 6325 Huawei 4 Intended status: Proposed Standard Radia Perlman 5 Intel Labs 6 Vishwas Manral 7 Hewlett-Packard 8 Ayan Banerjee 9 Cumulus 10 Expires: January 15, 2013 July 16, 2012 12 Multiple Topology TRILL 13 15 Abstract 17 The IETF TRILL (TRansparent Interconnection of Lots of Links) 18 protocol is a solution for least cost transparent frame routing in 19 multi-hop networks with arbitrary topologies and link technologies, 20 using IS-IS (Intermediate System to Intermediate System) link-state 21 routing and encapsulation with a hop count. IS-IS supports multiple 22 topology routing. This document specifies a TRILL data plane encoding 23 and procedures to make use of such routing. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the TRILL working group mailing list. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 1.1 Terminology............................................3 53 2. TRILL Multi-Topology....................................4 54 2.1 Nicknames and Topology Abbreviation....................4 55 2.2 Nickname Allocation....................................5 56 2.3 SPF and Distribution Tree Calculation..................6 57 2.3.1 Base Topology SPF....................................6 58 2.3.2 Non-Zero Topology SPF................................6 59 2.3.3 Distribution Tree Calculation........................6 61 3. Processing Multi-Topology Frames........................8 62 3.1 Ingress Processing.....................................8 63 3.2 Transit Processing.....................................8 64 3.3 Egress Processing......................................9 65 3.4 Address Learning and Asymmetric Topologies.............9 67 5. IS-IS Extensions.......................................10 68 6. IANA Considerations....................................11 69 7. Security Considerations................................11 70 8. Acknowledgements.......................................11 72 9. References.............................................12 73 9.1 Normative References..................................12 74 9.2 Informative References................................12 76 1. Introduction 78 The IETF has standardized RBridges (Routing Bridges), devices that 79 implement the TRILL (TRansparent Interconnection of Lots of Links) 80 protocol [RFC6325], a solution for least cost transparent frame 81 routing in multi-hop networks with arbitrary topologies, using IS-IS 82 (Intermediate System to Intermediate System) link-state routing [IS- 83 IS] [RFC1195] [RFC6326bis] and encapsulation with a hop count. 85 TRILL supports VLANs (Virtual Local Area Networks) but the 86 segregation provided by VLANs in TRILL is logical, not physical. 87 While maintaining logical separation, the base TRILL standard shares 88 inter-RBridge links across all VLANs and by default interconnects all 89 end stations that are in the same VLAN and have connectivity to any 90 RBridge in the campus. 92 IS-IS multi-topology [RFC5120] can provide physical separation of 93 sub-sets of TRILL Data frames, assuming that the RBridges in a campus 94 can be trusted. This can be used for a variety of purposes including 95 such things as confining a sub-set traffic to an island within an 96 RBridge campus, quality of service traffic engineering, excluding 97 some frames from links that are particularly exposed to interception, 98 and providing significant protection against some covert channels 99 [RFC4949]. 101 Familiarity with the TRILL base protocol standard [RFC6325], TRILL 102 use of IS-IS [RFC6326bis], and IS-IS multi-topology [RFC5120] is 103 assumed in this document. 105 1.1 Terminology 107 The terminology and acronyms of [RFC6325] are used in this document 108 with the additions listed below. 110 Highest Priority RBridge - The RBridge in the campus that is the 111 highest priority to be a base topology tree root. 113 MT - Multi-Topology 115 TAS - Topology Abbreviation Size 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. TRILL Multi-Topology 123 The essence of TRILL multi-topology (MT) is that (a) when TRILL Data 124 frames are ingressed or created they are assigned to a topology, (b) 125 links can be labeled with one or more topologies and different cost, 126 etc., for different topologies, and (c) a TRILL Data frame is only 127 allowed on a link labeled with the frame's topology. In addition, 128 there is a base topology: all links are considered to be in the base 129 topology, and, by default, TRILL Data frames are considered to be 130 base topology frames. 132 With minor exceptions, it is important that all transit RBridges 133 believe a TRILL Data frame is in the same topology to avoid 134 persistent routing loops. This document specifies how to encode this 135 information into the egress nickname in a TRILL Data frame. (Note: It 136 is believed that this technique is supportable by most if not all 137 TRILL fast path silicon implementations.) 139 Implementation of MT has a significant impact on shortest path and 140 distribution tree computation. In general, it multiplies the level of 141 effort by the number of different topologies in which the average 142 RBridge participates. Using the technique in this document, it also 143 reduces the number of of available nicknames, generally dividing it 144 by the number of topologies rounded up to the next power of two. For 145 these reasons, the number of overlapping topologies in use should be 146 minimized. 148 2.1 Nicknames and Topology Abbreviation 150 The TRILL base protocol standard [RFC6325] specifies 16-bit nicknames 151 as abbreviations for 7-bytes IS-IS IDs. In MT TRILL the nickname is 152 subdivided into two fields. The least significant TAS (Topology 153 Abbreviation Size) number of bits indicate the topology constraint of 154 the nickname while the most significant ( 16 - TAS ) bits continue to 155 act as an abbreviation for an RBridge System ID. 157 The TAS value for an MT RBridge campus is dictated by the highest 158 priority RBridge. To prevent transient disruption, other RBridges 159 that might become the highest priority RBridge SHOULD be configured 160 with the same TAS value. The value of TAS can vary from zero to 161 seven. Zero indicates that only the base topology can be used. 163 In IS-IS, topologies have a 12-bit ID which we refer to as an 164 absolute topology number. Topology zero is the base topology. All 165 links are considered to be part of the base topology. Absolute 166 topology numbers are mapped into abbreviations by a table dictated by 167 the highest priority RBridge. To prevent transient disruption, other 168 RBridges that might become the highest priority RBridge should be 169 configured with the same TAS topology abbreviation table. In the 170 opening remarks to this Section 2, "topology" should be read as 171 referring to topology abbreviation. 173 Multiple absoolute topology numbers MAY be mapped into the same 174 abbreviation. This may or may not result in the merger of the mapped 175 absolute topologies depending on whether their use is disjoint or 176 overlapping. Absolute topology zero and topology abbreviation zero 177 always refers to the base topology. 179 For example, assume that absolute topologies Tp1 and Tp2 exist and 180 are both mapped into the same specific abbreviation. If all RBridges 181 in the campus reachable by links labeled Tp1 or Tp2 are connected 182 through such links, then, since MT TRILL forwarding is based on the 183 topology abbreviation, Tp1 and Tp2 are necessarily merged to the 184 extent both topologies are in use. On the other hand, such RBridges 185 could be divided into disjoint islands with no connection between the 186 islands via links allowing Tp1 or Tp2. In that case, depending on how 187 frames are topologically classified, each such island could 188 independently be exclusively Tp1, exclusively Tp2, merged Tp1 and 189 Tp2, or unused. 191 2.2 Nickname Allocation 193 RBridges indicate in their LSP whether they support MT by the 194 presence of the MT TLV [RFC5120]. If all RBridges in a campus support 195 MT, then RBridges can be configured for and contend for nicknames as 196 provided in [RFC6325], but only for nicknames that have TAS number of 197 low order zero bits. If there are any RBridges in the campus that do 198 not support MT, then MT RBridges must hold all nicknames from ( k * 199 2**TAS ) through ( (k+1) * 2**TAS - 1 ) in order to, in effect, hold 200 nickname ( k * 2**TAS ). 202 RBridges not supporting MT are unaware of the subdivision of the 203 TRILL nickname into subfields. Thus, they may hold artbirary 16-bit 204 allowed quanities as nicknames. MT aware RBridges know that the 205 bottom TAS bits of any nicknames held by such MT unaware RBridges are 206 not topologically significant. 208 The nickname allocation described above and in [RFC6325] runs based 209 on the nickname priority values appearing in Router Capabilities TLVs 210 (TLV #242), which is what MT unaware RBridges will use. The Nicknames 211 sub-TLV is allowed in the MT Router Capabilities TLV (TLV #144) for 212 the sole purpose of permitting nicknames to have different priorities 213 to be root in different topologies; in particular, the Nicknames sub- 214 TLV field giving the priority to hold that nickname is ignore for 215 Nicknames sub-TLVs in the MT Router Capabilities TLV. 217 2.3 SPF and Distribution Tree Calculation 219 This section discusses MT SPF and distribution tree calculation. 221 2.3.1 Base Topology SPF 223 Since MT TRILL cannot impose any changes on MT unaware RBridges, 224 those RBridges will perform their SPF and distribution tree 225 calculations as specified in [RFC6325]. For compatibility, MT aware 226 RBridge MUST perform their base topology SPF and distribution tree 227 calculations in the same way. In particular, the base topology 228 consists of those links listed in Extended IS Reachability TLVs (TLV 229 #22). For backward compatibility, MT aware RBridges use only links 230 listed in TLV #22 for the base topology, which SHOULD be all links, 231 even if there exist MT-ISN TLVs (TLV #222) listing topology zero or 232 if one or more non-zero absolute topologies are being mapped into the 233 base topology abbreviation zero. 235 2.3.2 Non-Zero Topology SPF 237 For MT aware RBridges, least cost (SPF) paths are also calculated per 238 topology abbreviation for the non-zero abbreviations labeling any 239 link connected to that RBridge. When paths are being calculated for a 240 topology abbreviation, only links labeled with absolute topologies 241 that map to that abbreviation are considered. 243 For topologies other than the base toplogy, link costs from the MT- 244 ISN TLV (TLV #222 [RFC5120]) are used; however, such costs are 245 reported per absolute topology, not per topology abbreviation. This 246 is resolved for non-zero abbreviations by using, in SPF calculations, 247 the lowest cost reported for the link for any absolute topology 248 corresponding the topology abbreviation for which the calculation is 249 being performed. Non-base topologies do not necessarily span the 250 campus and there may be RBridges that are unreachable in such 251 topologies. Frames destined for unreachable RBridges are discarded. 253 2.3.3 Distribution Tree Calculation 255 Distribution trees are also calculated per topology abbreviation by 256 MT aware RBridges. At least one distribution tree is always built as 257 described in [RFC6325] for the base topology using the tree root 258 nickname priorities advertised in the Router Capabilities TLV. That 259 tree will span the campus. Care should be taken that the highest 260 priority RBridge is configured to not request too many distribution 261 trees be calculated in the base topology. There may be silicon limits 262 to how many distribution trees can be efficienlty handled and too 263 many base topology trees could starve other topologies that should 264 have a distributon tree. 266 For non-zero topology abbreviations, a distribution tree will be 267 composed only of links that are in at least one of the absolute 268 topologies that map to that abbreviation and the tree may not span 269 the campus. Such distribution trees might not span the campus and 270 there might be multiple disjoint distribution trees for a particular 271 topology abbreviation. 273 The calculation of additional distribution trees for non-zero 274 topology abbreviations is accomplished using the same method of 275 building from root as described in [RFC6325] but using link costs as 276 described in the preceding section on TRILL non-zero topology SPF 277 calculations. The number of such trees may be constrained by the 278 capabilities of RBridges in the campus as advertised in the Trees 279 sub-TLV in the Router Capabilities TLV. However, that limit is of the 280 number of trees actually including that RBridge and would not 281 include, for example, a distribution tree for some topology present 282 only in a remote island of RBridges. 284 After the base topology trees are calculated, trees for non-zero 285 topologies are calculated, one per topology abbreviation, starting 286 with the highest topology abbreviation in use and working down to the 287 lowest non-zero topology. If additional tree are available and 288 requested, they are distrubted to the topology abbreviations. For the 289 details see Appendix ... [[Since it is important that all RBridges 290 agree on the calculation of distribution trees, I think this is going 291 to need some psudo code in an appendix.]] 293 3. Processing Multi-Topology Frames 295 This section specifies ingress, transit, and egress processing of MT 296 TRILL Data frames, how asymetric topologies can occur, and address 297 learning. 299 3.1 Ingress Processing 301 On ingressing or creating a frame, an RBridge assigns it to an 302 absolute topology ID. The method by which this 12-bit topology ID is 303 assigned is beyond the scope of this document; however, different 304 frames with the same source MAC address, VLAN, and egress RBridge 305 SHOULD be assigned to the same topology. In TRILL, topology does not 306 provide another level of VLAN but identifies a subset of traffic. 308 The resulting absolute ID is mapped to a topology abbreviation. That 309 abbreviation is used as the bottom TAS bits in the ingress nickname 310 field of the resulting TRILL Data frame. 312 For a unicast native frame the VLAN and the destination MAC address 313 are used to look up the egress nickname field. 315 If the destination is unknown, or the native frame is multicast or 316 broadcast, the ingress RBridge selects a distribution tree for that 317 topology abbreviation that includes the ingress RBridge. If more than 318 one tree is available, the method of choice is beyond the scope of 319 this document, but by default, it should pick the tree whose root is 320 least cost from the ingress RBridge. 322 3.2 Transit Processing 324 No change is required in transit frame processing assuming that SPF 325 and distribution tree calculations have been performed as specified 326 in Section 2.3. 328 The next hop RBridge for TRILL unicast frames will automatically be 329 restricted to the appropriate topology. The same applies to the zero 330 or more next hops for the tree that a TRILL multi-destination frame 331 is being distributed on. There is no change in the Reverse Path 332 Forwarding Check. 334 3.3 Egress Processing 336 There is no change in egress processing. 338 3.4 Address Learning and Asymmetric Topologies 340 There is no change in address learning. This can result in 341 asymmetric topology use. 343 For example assume end stations ESa and ESb in the same VLAN-x 344 attached to RB1 and RB2 respectively want to communicate. Generally, 345 the initial frame from RB1 will be classified in topology 346 abbreviation T1 and sent on a T1 distribution tree which should be 347 pruned for VLAN-x. If that tree includes RB2, the frame will be 348 delivered to RB2 that will egress it to ESb or, if it has not yet 349 learned which of its links ESb is attached to, RB2 will egress the 350 frame to all of its links in VLAN-x for which it is appointed 351 forwarder [RFC6439]. In addition, RB2 will learn that ESa in VLAN-x 352 is attached to RB1 but the nickname it learns from RB1 will have T1 353 encoded in it so that RB1 also learns, that ESa is in T1. When ESb 354 send a return frame to ESa, RB2 will classify that frame as in 355 topology abbreviation T2, encode that in the ingress nickname of the 356 TRILL header, and send the frame to RB1 in T1 because the egress 357 nickname RB2 will use was that learned from the receipt of the above 358 frame from RB1 in T1. At this point, ESa and ESb can continue 359 communicating using TRILL unicast frames in each direction with 360 frames from ESa to ESb in T1 while those from ESb to ESa will be in 361 T2. 363 If it is desired that T1 equal T2, then RB1 and RB2 must be 364 configured to classify the incoming native frames as in the same 365 topology. Note that, if many topologies are in use but there are 366 fewer distribution trees, the initial ESa frame in the example above 367 might have been distributed in a T3 distribution tree. This will not 368 affect RB2 learning which will learn from the T1 topology encoded 369 into the ingress nickname in the encapsulated frame's TRILL Header. 371 5. IS-IS Extensions 373 For the extensions to the TRILL use of IS-IS to make use multi- 374 topology, see [trill-mt]. 376 These include the addition of a topology mapping sub-TLV. This sub- 377 TLV is across all topologies and occurs in the Router Capabilities 378 TLV. It specifies the TAS for the campus and provides a mapping from 379 absolute topology IDs to topology abbreviations. Absolute topology 380 zero is always mapped to topology abbreviation zero. No entry is 381 needed for this base topology mapping and any other mapping for 382 topology zero is ignored. Multiple absolute topologies may be mapped 383 to the same abbreviation. If there are mappings of the same absolute 384 topology to multiple abbreviations, the largest abbreviation, 385 considered as an unsigned integer dominates, and mappings of that 386 absolute topology to smaller abbreviations are ignored. 388 6. IANA Considerations 390 IANA coniderations for this draft are in [trill-mt]. 392 7. Security Considerations 394 See [RFC6325] for general RBridge Security Considerations. 396 As with any communications system, end-to-end encryption and 397 authentication should be considered for particularly sensitive data. 399 More TBD 401 8. Acknowledgements 403 The comments and contributions of the following are gratefully 404 acknowledged: 406 Meenakshi Kaushik and Dinesh Dutt. 408 9. References 410 The following sections list normative and informative references for 411 this document. 413 9.1 Normative References 415 [IS-IS] - International Organization for Standardization, 416 "Intermediate system to Intermediate system intra-domain 417 routeing information exchange protocol for use in conjunction 418 with the protocol for providing the connectionless-mode Network 419 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 420 2002. 422 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 423 dual environments", RFC 1195, December 1990. 425 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997 428 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 429 Topology (MT) Routing in Intermediate System to Intermediate 430 Systems (IS-ISs)", RFC 5120, February 2008. 432 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 433 Ghanwani, "Routing Bridges (RBridges): Base Protocol 434 Specification", RFC 6325, July 2011. 436 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 437 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 438 6439, November 2011. 440 [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A. 441 Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis, 442 work in progress. 444 [trill-mt] - Manral, V., D. Eastlake, M. Zhang, A. Banerjee, "Multi 445 Topology Routing Extensions for Transparent Interconnection of 446 Lots of Links (TRILL)", draft-manral-isis-trill-multi-topo, 447 work in progress. 449 9.2 Informative References 451 [RFC4949] - Shirey, R., "Internet Security Glossary, Version 2", FYI 452 36, RFC 4949, August 2007. 454 Authors' Addresses 456 Donald Eastlake 3rd 457 Huawei R&D USA 458 155 Beaver Street 459 Milford, MA 01757 USA 461 Phone: +1-508-333-2270 462 EMail: d3e3e3@gmail.com 464 Mingui Zhang 465 Huawei Technologies Co., Ltd 466 HuaWei Building, No.3 Xinxi Rd., Shang-Di 467 Information Industry Base, Hai-Dian District, 468 Beijing, 100085 P.R. China 470 Email: zhangmingui@huawei.com 472 Radia Perlman 473 Intel Labs 474 2200 Mission College Blvd. 475 Santa Clara, CA 95054 USA 477 Phone: +1-408-765-8080 478 Email: radia@alum.mit.edu 480 Vishwas Manral 481 Hewlett-Packard Co. 482 19111 Pruneridge Ave. 483 Cupertino, CA 95014 USA 485 Phone: 1-408-447-0000 486 Email: vishwas.manral@hp.com 488 Ayan Banerjee 489 Cumulus Networks 490 1089 West Evelyn Avenue 491 Sunnyvale, CA 94086 USA 493 Email: ayabaner@gmail.com 495 Copyright, Disclaimer, and Additional IPR Provisions 497 Copyright (c) 2012 IETF Trust and the persons identified as the 498 document authors. All rights reserved. 500 This document is subject to BCP 78 and the IETF Trust's Legal 501 Provisions Relating to IETF Documents 502 (http://trustee.ietf.org/license-info) in effect on the date of 503 publication of this document. Please review these documents 504 carefully, as they describe your rights and restrictions with respect 505 to this document. Code Components extracted from this document must 506 include Simplified BSD License text as described in Section 4.e of 507 the Trust Legal Provisions and are provided without warranty as 508 described in the Simplified BSD License. The definitive version of 509 an IETF Document is that published by, or under the auspices of, the 510 IETF. Versions of IETF Documents that are published by third parties, 511 including those that are translated into other languages, should not 512 be considered to be definitive versions of IETF Documents. The 513 definitive version of these Legal Provisions is that published by, or 514 under the auspices of, the IETF. Versions of these Legal Provisions 515 that are published by third parties, including those that are 516 translated into other languages, should not be considered to be 517 definitive versions of these Legal Provisions. For the avoidance of 518 doubt, each Contributor to the IETF Standards Process licenses each 519 Contribution that he or she makes as part of the IETF Standards 520 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 521 language to the contrary, or terms, conditions or rights that differ 522 from or are inconsistent with the rights and licenses granted under 523 RFC 5378, shall have any effect and shall be null and void, whether 524 published or posted by such Contributor, or included with or in such 525 Contribution.