idnits 2.17.1 draft-ietf-trill-multi-topology-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 : ---------------------------------------------------------------------------- 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 (November 28, 2016) is 2700 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Mingui Zhang 3 Updates: 6325, 7177 Huawei 4 Ayan Banerjee 5 Cisco 6 Expires: May 27, 2017 November 28, 2016 8 TRILL: Multi-Topology 9 11 Abstract 12 This document specifies extensions to the IETF TRILL (Transparent 13 Interconnection of Lots of Links) protocol to support multi-topology 14 routing of unicast and multi-destination traffic based on IS-IS 15 (Intermediate System to Intermediate System) multi-topology specified 16 in RFC 5120. This document updates RFC 6325 and RFC 7177. 18 Status of This Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Distribution of this document is unlimited. Comments should be sent 24 to the TRILL working group mailing list. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 38 Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Introduction............................................3 44 1.1 Terminology............................................4 46 2. Topologies..............................................6 47 2.1 Special Topology Zero..................................6 48 2.2 Links and Multi-Topology...............................6 49 2.3 TRILL Switches and Multi-Topology......................6 50 2.4 TRILL Data Packets and Multi-Topology..................7 51 2.4.1 Explicit Topology Labeling Support...................7 52 2.4.2 The Explicit Topology Label..........................8 53 2.4.3 TRILL Use of the MT Label............................9 55 3. TRILL Multi-Topology Adjacency and Routing.............11 56 3.1 Adjacency (Updates to RFC 7177).......................11 57 3.2 TRILL Switch Nicknames................................11 58 3.3 TRILL Unicast Routing.................................12 59 3.4 TRILL Multi-Destination Routing.......................12 60 3.4.1 Distribution Trees..................................12 61 3.4.2 Multi-Access Links..................................14 63 4. Mixed Links............................................15 65 5. Other Multi-Topology Considerations....................16 66 5.1 Address Learning......................................16 67 5.1.1 Data Plane Learning.................................16 68 5.1.2 Multi-Topology ESADI................................16 69 5.2 Legacy Stubs..........................................16 70 5.3 RBridge Channel Messages..............................16 71 5.4 Implementations Considerations........................17 73 6. Allocation Considerations..............................18 74 6.1 IEEE Registration Authority Considerations............18 75 6.2 IANA Considerations...................................18 77 7. Security Considerations................................19 79 Normative References......................................20 80 Informative References....................................21 81 Acknowledgements..........................................22 83 Appendix A: Differences from RFC 5120.....................23 85 1. Introduction 87 This document specifies extensions to the IETF TRILL (Transparent 88 Interconnection of Lots of Links) protocol [RFC6325] [RFC7177] 89 [RFC7780] to support multi-topology routing for both unicast and 90 multi-destination traffic based on IS-IS (Intermediate System to 91 Intermediate System, [IS-IS]) multi-topology [RFC5120]. 92 Implementation and use of multi-topology are optional and use 93 requires configuration. It is anticipated that not all TRILL campuses 94 will need or use multi-topology. 96 This document updates [RFC7177] as specified in Section 3.1. This 97 document updates numerous aspects of [RFC6325] including changing 98 routing (Sections 3.3 and 3.4), address learning (Section 5.1), and 99 distribution tree construction (Section 3.4), to take multi-topology 100 into account. 102 Multi-topology creates different topologies or subsets from a single 103 physical TRILL campus topology. This is different from Data Labels 104 (VLANs and Fine Grained Labels [RFC7172]). Data Labels specify 105 communities of end stations and can be viewed as creating virtual 106 topologies of end station connectivity. However, in a single topology 107 TRILL campus, TRILL Data packets can use any part of the physical 108 topology of TRILL switches and links between TRILL switches, 109 regardless of the Data Label of that packet's payload. In a multi- 110 topology TRILL campus, TRILL data packets in a topology are 111 restricted to the TRILL switches and links that are in their topology 112 but may still use any of the TRILL switches and links in their 113 topology regardless of the Data Label of their payload. 115 The essence of multi-topology behavior is that a multi-topology 116 router classifies packets as to the topology within which they should 117 be routed and uses logically different routing tables for different 118 topologies. If routers in the network do not agree on the topology 119 classification of packets or links, persistent routing loops can 120 occur. It is the responsibility of the network manager to 121 consistently configure multi-topology to avoid such routing loops. 123 The multi-topology TRILL extensions can be used for a wide variety of 124 purposes, such as maintaining separate routing domains for isolated 125 multicast or IPv6 islands, routing a class of traffic so that it 126 avoids certain TRILL switches that lack some characteristic needed by 127 that traffic, or making a class of traffic avoid certain links due to 128 security, reliability, or other concerns. 130 It is possible for a particular topology to not be fully connected, 131 either intentionally or due to node or link failures or incorrect 132 configuration. This results in two or more islands of that topology 133 that cannot communicate. In such a case, end station connected in 134 that topology to different islands will be unable to communicate with 135 each other. 137 Multi-topology TRILL supports regions of topology-ignorant TRILL 138 switches as part of a multi-topology campus; however, such regions 139 can only ingress to, egress from, or transit TRILL Data packets in 140 the special base topology zero. 142 1.1 Terminology 144 The terminology and acronyms of [RFC6325] are used in this document. 145 Some of these are listed below for convenience along with some 146 additional terms. 148 campus - The name for a TRILL network, like "bridged LAN" is a 149 name for a bridged network. It does not have any academic 150 implication. 152 DRB - Designated RBridge [RFC7177]. 154 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine- 155 Grained Label [RFC7172]. By implication, an "FGL TRILL 156 switch" does not support MT. 158 IS - Intermediate System [IS-IS]. 160 LSP - [IS-IS] Link State PDU (Protocol Data Unit). For TRILL this 161 includes L1-LSPs and E-L1FS-LSPs [RFC7780]. 163 MT - Multi-Topology, this document and [RFC5120]. 165 MT TRILL Switch - A TRILL switch supporting the multi-topology 166 feature specified in this document. An MT TRILL switch MUST 167 support FGL in the sense that it MUST be FGL safe [RFC7172]. 169 RBridge - "Routing Bridge", an alternative name for a TRILL 170 switch. 172 TRILL - Transparent Interconnection of Lots of Links or Tunneled 173 Routing in the Link Layer [RFC6325]. 175 TRILL Switch - A device implementing the TRILL protocol. TRILL 176 switches are [IS-IS] Intermediate Systems (routers). 178 VL - VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. By 179 implication, a "VL RBridge" or "VL TRILL switch" does not 180 support FGL or MT. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 2. Topologies 188 In TRILL multi-topology, a topology is a subset of the TRILL switches 189 and of the links between TRILL switches in the TRILL campus. TRILL 190 Data packets are constrained to the subset of switches and links 191 corresponding to the packet's topology. TRILL multi-topology is based 192 on [RFC5120] IS-IS multi-topology. See Appendix A for differences 193 between TRILL multi-topology and [RFC5120]. 195 The zero topology is special as described in Section 2.1. Sections 196 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and 197 TRILL Data packets respectively. 199 2.1 Special Topology Zero 201 The zero topology is special as the default base topology. All TRILL 202 switches and links are considered to be in and MUST support topology 203 zero. Thus, for example, topology zero can be used for general TRILL 204 switch access within a campus for management messages, BFD messages 205 [RFC7175], RBridge Channel messages [RFC7178], and the like. 207 2.2 Links and Multi-Topology 209 Multi-topology TRILL switches advertise the topologies for which they 210 are willing to send and receive TRILL Data packets on a port by 211 listing those topologies in one or more MT TLVs [RFC5120] appearing 212 in every TRILL Hello [RFC7177] they send out that port, except that 213 they MUST handle topology zero, which it is optional to list. 215 A link is only usable for TRILL Data packets in non-zero topology T 216 if 217 (1) all TRILL switch ports on the link advertise topology T support 218 in their Hellos and 219 (2) if any TRILL switch port on the link requires explicit TRILL Data 220 packet topology labeling (see Section 2.4) every other TRILL 221 switch port on the link is capable of generating explicit packet 222 topology labeling. 224 2.3 TRILL Switches and Multi-Topology 226 A TRILL switch advertises the topologies that it supports by listing 227 them in one or more MT TLVs [RFC5120] in its LSP except that it MUST 228 support topology zero which is optional to list. For robust and rapid 229 flooding, MT TLV(s) SHOULD be advertised in core LSP fragment zero. 231 There is no "MT capability bit". A TRILL switch advertises that it is 232 MT capable by advertising in its LSP support for any topology or 233 topologies with the MT TLV, even if it just explicitly advertises 234 support for topology zero. 236 2.4 TRILL Data Packets and Multi-Topology 238 The topology of a TRILL Data packet is commonly determined from 239 either (1) some field or fields present in the packet itself or (2) 240 the port on which the packet was received; however optional explicit 241 topology labeling of TRILL Data packets is also proved. This can be 242 included in the data labeling area of TRILL Data packets as specified 243 below. 245 Examples of fields that might be used to determine topology are 246 values or ranges of values of the payload VLAN or FGL [RFC7172], 247 packet priority, IP version (IPv6 versus IPv4) or IP protocol, 248 Ethertype, unicast versus multi-destination payload, IP 249 Differentiated Services Code Point (DSCP) bits, or the like. 251 "Multi-topology" does not apply to TRILL IS-IS packets or to link 252 level control frames. Those messages are link local and can be 253 thought of as being above all topologies. "Multi-topology" only 254 applies to TRILL Data packets. 256 2.4.1 Explicit Topology Labeling Support 258 Support of the topology label is optional. Support could depend on 259 port hardware and is indicated by a two-bit capability field in the 260 Port TRILL Version sub-TLV [RFC7176] appearing in the Port 261 Capabilities TLV in Hellos. If there is no Port TRILL Capabilities 262 sub-TLV in a Hello, then it is assumed that explicit topology 263 labeling is not supported on that port. See the table below for the 264 meaning of values of the Explicit Topology capability field: 266 Value Meaning 267 ----- ------- 268 0 No support. Cannot send TRILL Data packets with an explicit 269 topology label and will likely treat as erroneous and discard 270 any TRILL Data packet received with a topology label. Such a 271 port is assumed to have the ability and configuration to 272 correctly classify TRILL data packets into all topologies for 273 which it is advertising support in its Hellos, either by 274 examining those packets or because they are arriving at that 275 port. 276 1 Capable of inserting an explicit topology label in TRILL Data 277 packets sent and tolerant of such labels in received TRILL 278 Data packets. Such a port is capable, for all of the 279 topologies it supports, of determining TRILL Data packet 280 topology without an explicit label. Thus it does not require 281 such a label in received TRILL Data packets. On receiving a 282 packet whose explicit topology label differs from the port's 283 topology determination for that packet, the TRILL switch MUST 284 discard the packet. 285 2 and 3 Requires an explicit topology label in received TRILL 286 Data packets except for topology zero. Any TRILL Data packets 287 received without such a label is classified as being in 288 topology zero. Also capable of inserting an explicit 289 topology label in TRILL Data packets sent. (Values 2 and 3 290 are treated the same, which is the same as saying that if the 291 2 bit is on, the 1 bit is ignored.) 293 A TRILL switch advertising in a Hello on Port P support for topology 294 T but not advertising in those Hellos that it requires explicit 295 topology labeling is assumed to have the ability and configuration to 296 correctly classify TRILL Data packets into topology T by examination 297 of those TRILL Data packets and/or by using the fact that they are 298 arriving at port P. 300 When a TRILL switch transmits a TRILL Data packet onto a link, if any 301 other TRILL switch on that link requires explicit topology labeling, 302 an explicit topology label MUST be included unless the TRILL data 303 packet is in topology zero in which case an explicit topology label 304 MAY be included. If a topology label is not so required but all other 305 TRILL switches on that link support explicit topology labeling, then 306 such a label MAY be included. 308 2.4.2 The Explicit Topology Label 310 This section specifies the explicit topology label. Its use by TRILL 311 is specified in Section 2.4.3. This label may be used by other 312 technologies besides TRILL. The MT label is structured as follows: 314 0 1 2 3 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | MT Ethertype TBD | V | R | MT-ID | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 1. MT Label 322 where the fields are as follows: 324 MT Ethertype - The MT label Ethertype (see Section 6.1). 326 V - The version number of the MT label. This document specifies 327 version zero. 329 R - A 2-bit reserved field that MUST be sent as zero and ignored 330 on receipt. 332 MT-ID - The 12-bit topology using the topology number space of the 333 MT TLV [RFC5120]. 335 2.4.3 TRILL Use of the MT Label 337 With the addition of the MT label, the four standardized content 338 varieties for the TRILL Data packet data labeling area (the area 339 after the Inner.MacSA (or Flag Word if the Flag Word is present 340 [RFC7780]) and before the payload) are as show below. {PRI, D} is a 341 3-bit priority and a drop eligibility indicator bit [RFC7780]. All 342 MT TRILL switches MUST support FGL, in the sense of being FGL safe 343 [RFC7172], and thus MUST support all four data labeling area contents 344 shown below. 346 1. C-VLAN [RFC6325] 348 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | C-VLAN = 0x8100 | PRI |D| VLAN ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 2. FGL [RFC7172] 356 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | FGL = 0x893B | PRI |D| FGL High Part | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | FGL = 0x893B | PRI |D| FGL Low Part | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 3. MT C-VLAN [this document] 366 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | MT Ethertype = TBD | 0 | R | MT-ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | C-VLAN = 0x8100 | PRI |D| VLAN ID | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 4. MT FGL [this document] [RFC7172] 376 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | MT Ethertype = TBD | 0 | R | MT-ID | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | FGL = 0x893B | PRI |D| FGL High Part | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | FGL = 0x893B | PRI |D| FGL Low Part | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Inclusion or use of S-VLAN or further stacked tags are beyond the 387 scope of this document but, as stated in [RFC6325], are obvious 388 extensions. 390 3. TRILL Multi-Topology Adjacency and Routing 392 Routing calculations in IS-IS are based on adjacency. Section 3.1 393 specifies multi-topology updates to the TRILL adjacency specification 394 [RFC7177]. Section 3.2 describes the handling of nicknames. 395 Sections 3.3 and 3.4 specify how unicast and multi-destination TRILL 396 multi-topology routing differ from the TRILL base protocol routing. 398 3.1 Adjacency (Updates to RFC 7177) 400 There is no change in the determination or announcement of adjacency 401 for topology zero which is as specified in [RFC7177]. When a 402 topology zero adjacency reaches the Report state as specified in 403 [RFC7177], the adjacency is announced in core LSPs using the Extended 404 Intermediate System Reachability TLV (#22). This will be compatible 405 with any legacy topology-ignorant RBridges that might not support E- 406 L1FS FS-LSPs [RFC7780]. 408 Adjacency is announced for non-zero topologies in LSPs using the MT 409 Reachable Intermediate Systems TLV (#222) as specified in [RFC5120]. 410 A TRILL switch reports adjacency for non-zero topology T if and only 411 if that adjacency is in the Report state [RFC7177] and the two 412 conditions listed in Section 2.2 are true, namely: 414 1. All the ports on the link are announcing support of topology T. 416 2. If any port announces that it requires explicit topology labeling 417 (Explicit Topology capability field value 2 or 3), all other ports 418 advertise that they are capable of producing such labeling 419 (Explicit Topology capability field value of 1, 2, or 3). 421 3.2 TRILL Switch Nicknames 423 TRILL switches are usually identified within the TRILL protocol (for 424 example in the TRILL Header) by nicknames [RFC6325] [RFC7780]. Such 425 nicknames can be viewed as simply 16-bit abbreviation for a TRILL 426 switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch or 427 pseudo-node can have more than one nickname, each of which identifies 428 it. 430 Nicknames are common across all topologies, just as IS-IS System IDs 431 are. Nicknames are determined as specified in [RFC6325] and [RFC7780] 432 using only the Nickname sub-TLVs appearing in Router Capabilities 433 TLVs (#242) advertised by TRILL switches. In particular, the nickname 434 allocation algorithm ignores Nickname sub-TLVs that appear in MT 435 Router Capability TLVs (#144). (However, nickname sub-TLVs that 436 appear in MT Router Capability TLVs with a non-zero topology do 437 affect the choice of distribution tree roots as described in Section 438 3.4.1.) 440 To minimize transient inconsistencies, all Nickname sub-TLVs 441 advertised by a TRILL switch for a particular nickname, whether in 442 Router Capability or MT Router Capability TLVs, SHOULD appear in the 443 same LSP PDU. If that is not the case, then all LSP PDUs in which 444 they do occur SHOULD be flooded as an atomic action. 446 3.3 TRILL Unicast Routing 448 TRILL Data packets being TRILL unicast (those with TRILL Header M bit 449 = 0) are routed based on the egress nickname using logically separate 450 forwarding tables per topology T where each such table has been 451 calculated based on least cost routing within T, that is, only using 452 links and nodes that support T. Thus, the next hop when forwarding 453 TRILL Data packets is determined by a lookup logically based on 454 {topology, egress nickname}. 456 3.4 TRILL Multi-Destination Routing 458 TRILL sends multi-destination data packets (those packets with TRILL 459 Header M bit = 1) over a distribution tree. Trees are designated by 460 nicknames that appear in the "egress nickname" field of multi- 461 destination TRILL Data packet TRILL Headers. To constrain multi- 462 destination packets to a topology T and still distribute them 463 properly requires the use of a distribution tree constrained to T. 464 Handling such TRILL Data packets and distribution trees in TRILL MT 465 is as described in the subsections below. 467 3.4.1 Distribution Trees 469 General provisions for distribution trees and how those trees are 470 determined are as specified in [RFC6325], [RFC7172], and [RFC7780]. 471 The distribution trees for topology zero are determined as specified 472 in those references and are the same as they would be with topology- 473 ignorant TRILL switches. 475 The TRILL distribution tree construction and packet handling for some 476 non-zero topology T are determine as specified in [RFC6325], 477 [RFC7172], and [RFC7780] with the following changes: 479 o As specified in [RFC5120], only links usable with topology T 480 TRILL Data packets are considered when building a distribution 481 tree for topology T. As a result, such trees are automatically 482 limited to and separately span every internally connected 483 island of topology T. In other words, if non-zero topology T 484 consists of disjoint islands, each distribution tree 485 construction for topology T is local to one such island. 487 o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub- 488 TLV, and Trees Used sub-TLV occurring in an MT Router 489 Capabilities TLV (#144) specifying topology T are used in 490 determining the tree root(s), if any, for a connected area of 491 non-zero topology T. 493 + There may be non-zero topologies with no multi-destination 494 traffic or, as descried in [RFC5120], even topologies with 495 no traffic at all. For example, if only known destination 496 unicast IPv6 TRILL Data packets were in topology T and all 497 multi-destination IPv6 TRILL Data packets were in some other 498 topology, there would be no need for a distribution tree for 499 topology T. For this reasons, a Number of Trees to Compute 500 of zero in the Trees sub-TLV for the TRILL switch holding 501 the highest priority to be a tree root for a non-zero 502 topology T is honored and causes no distribution trees to be 503 calculated for non-zero topology T. This is different from 504 the base topology zero where, as specified in [RFC6325], a 505 zero Number of Trees to Compute causes one tree to be 506 computed. 508 o Nicknames are allocated as described in Section 3.2. If a 509 TRILL switch advertising that it provides topology T service 510 holds nickname N, the priority of N to be a tree root is given 511 by the tree root priority field of the Nickname sub-TLV that 512 has N in its nickname field and occurs in a topology T MT 513 Router Capabilities TLV advertised by that TRILL switch. If no 514 such Nickname sub-TLV can be found, the priority of N to be a 515 tree root is the default for an FGL TRILL switch as specified 516 in [RFC7172]. 518 + There could be multiple topology T Nickname sub-TLVs for N 519 being advertised for a particular RBridge or pseudo-node, 520 due to transient conditions or errors. In that case, any 521 advertised in a core LSP PDU are preferred to those 522 advertised in an E-L1FS FS-LSP PDU. Within those categories, 523 the one in the lowest numbered fragment is used and if there 524 are multiple in that fragment, the one with the smallest 525 offset from the beginning of the PDU is used. 527 o Tree pruning for topology T uses only the Interested VLANs sub- 528 TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT 529 Router Capabilities TLVs for topology T. 531 An MT TRILL switch MUST have logically separate routing tables per 532 topology for the forwarding of multi-destination traffic. 534 3.4.2 Multi-Access Links 536 Multi-destination TRILL Data packets are forwarded on broadcast 537 (multi-access) links in such a way as to be received by all other 538 TRILL switch ports on the link. For example, on Ethernet links they 539 are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken 540 that a TRILL Data packet in a non-zero topology is only forwarded by 541 an MT TRILL switch. 543 For this reason, a non-zero topology TRILL Data packet MUST NOT be 544 forwarded onto a link unless the link meets the requirements 545 specified in Section 2.2 for use in that topology even if there are 546 one or more MT TRILL switch ports on the link. 548 4. Mixed Links 550 There might be any combination of MT, FGL, or even VL TRILL switches 551 [RFC7172] on a link. DRB (Designated RBridge) election and Forwarder 552 appointment on the link work as previously specified in [rfc6439bis] 553 and [RFC7177]. It is up to the network manager to configure and 554 manage the TRILL switches on a link so that the desired switch is DRB 555 and the desired switch is the Appointed Forwarder for the appropriate 556 VLANs. 558 Frames ingressed by MT TRILL switches can potentially be in any 559 topology recognized by the switch and permitted on the ingress port. 560 Frames ingressed by VL or FGL TRILL switches can only be in the base 561 zero topology. Because FGL and VL TRILL switches do not understand 562 topologies, all occurrences of the following sub-TLVs MUST occur only 563 in MT Port Capability TLVs with a zero MT-ID. Any occurrence of these 564 sub-TVLs in an MT Port Capability TLV with a nonzero MT-ID is 565 ignored. 567 Special VLANs and Flags Sub-TLV 568 Enabled-VLANs Sub-TLV 569 Appointed Forwarders Sub-TLV 570 VLANs Appointed Sub-TLV 572 Native frames cannot be explicitly labeled (see Section 2.4) as to 573 their topology. 575 5. Other Multi-Topology Considerations 577 5.1 Address Learning 579 The learning of end station MAC addresses is per topology as well as 580 per label (VLAN or FGL). The same MAC address can occur within a 581 TRILL campus for different end stations that differ only in topology 582 without confusion. 584 5.1.1 Data Plane Learning 586 End station MAC addresses learned from ingressing native frames or 587 egressing TRILL Data packets are, for MT TRILL switches, qualified by 588 topology. That is, either the topology into which that TRILL switch 589 classified the ingressed native frame or the topology that the 590 egressed TRILL Data frame was in. 592 5.1.2 Multi-Topology ESADI 594 In an MT TRILL switch, ESADI [RFC7357] operates per label (VLAN or 595 FGL) per topology. Since ESADI messages appear, to transit TRILL 596 switches, like normal multi-destination TRILL Data packets, ESADI 597 link state databases and ESADI protocol operation are per topology as 598 well as per label and local to each area of multi-destination TRILL 599 data connectivity for that topology. 601 5.2 Legacy Stubs 603 Areas of topology ignorant TRILL switches can be connected to and 604 become part of an MT TRILL campus but will only be able to ingress 605 to, transit, or egress from topology zero TRILL Data packets. 607 5.3 RBridge Channel Messages 609 RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175] 610 appear, to transit TRILL switches, like normal multi-destination 611 TRILL Data packets. Thus, they have a topology and, if that topology 612 is non-zero, are constrained by topology like other TRILL Data 613 packets. Generally, when sent for network management purposes, they 614 are sent in topology zero to avoid such constraint. 616 5.4 Implementations Considerations 618 MT is an optional TRILL switch capability. 620 Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] 621 indicates that a single router handling more than eight topologies is 622 rare. There may be many more than eight distinct topologies in a 623 routed area, such as a TRILL campus, but in that case many of these 624 topologies will be handled by disjoint sets of routers and/or links. 626 Based on this deployment experience, a TRILL switch capable of 627 handling 8 or more topologies can be considered a full implementation 628 while a TRILL switch capable of handling 4 topologies can be 629 considered a minimal implementation but still useful under some 630 circumstances. 632 6. Allocation Considerations 634 IEEE Registration Authority and IANA considerations are given below. 636 6.1 IEEE Registration Authority Considerations 638 The IEEE Registration Authority will be requested to allocate a new 639 Ethertype for the MT label (see Section 2.4). 641 6.2 IANA Considerations 643 IANA is requested to assign a field of two adjacent bits TBD from 644 bits 14 through 31 of the Capabilities bits of the Port TRILL Version 645 Sub-TLV for the Explicit Topology capability field and update the 646 "PORT-TRILL-VER Capability Bits" registry as follows [shown with the 647 suggested bits 14 and 15]: 649 Bit Description Reference 650 ----- ------------------------- --------------- 651 14-15 Topology labeling support [this document] 653 7. Security Considerations 655 Multiple topologies are sometimes used for the isolation or security 656 of traffic. For example, if some links were more likely than others 657 to be subject to adversarial observation it might be desirable to 658 classify certain sensitive traffic in a topology that excluded those 659 links. 661 Delivery of data originating in one topology outside of that topology 662 is generally a security policy violation to be avoided at all 663 reasonable costs. Using IS-IS security [RFC5310] on all IS-IS PDUs 664 and link security appropriate to the link technology on all links 665 involved, particularly those between RBridges, supports the avoidance 666 of such violations. 668 For general TRILL security considerations, see [RFC6325]. 670 Normative References 672 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 673 Intermediate System Intra-Domain Routeing Exchange Protocol for 674 use in Conjunction with the Protocol for Providing the 675 Connectionless-mode Network Service (ISO 8473)", 2002. 677 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 679 March 1997, . 681 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 682 Topology (MT) Routing in Intermediate System to Intermediate 683 Systems (IS-ISs)", RFC 5120, February 2008. 685 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 686 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 687 5310, DOI 10.17487/RFC5310, February 2009, . 690 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 691 Ghanwani, "Routing Bridges (RBridges): Base Protocol 692 Specification", RFC 6325, July 2011. 694 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 695 and D. Dutt, "Transparent Interconnection of Lots of Links 696 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 698 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 699 D., and A. Banerjee, "Transparent Interconnection of Lots of 700 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 702 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 703 and V. Manral, "Transparent Interconnection of Lots of Links 704 (TRILL): Adjacency", RFC 7177, May 2014. 706 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 707 Ward, "Transparent Interconnection of Lots of Links (TRILL): 708 RBridge Channel Support", RFC 7178, May 2014. 710 [RFC7357] - Hhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 711 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 712 End Station Address Distribution Information (ESADI) Protocol", 713 RFC 7357, DOI 10.17487/RFC7357, September 2014, 714 . 716 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 717 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 718 Lots of Links (TRILL): Clarifications, Corrections, and 719 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 720 . 722 Informative References 724 [rfc6439bis] - D. Eastlake, Y. Li, M. Umair, A. Banerjee, and F. Hu, 725 "TRILL: Appointed Forwarders", draft-ietf-trill-rfc6439bis, 726 work in progress. 728 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 729 "Transparent Interconnection of Lots of Links (TRILL): 730 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 731 May 2014. 733 Acknowledgements 735 The comments and contributions of the following are gratefully 736 acknowledged: 738 Vishwas Manral and Martin Vigoureux 740 The document was prepared in raw nroff. All macros used were defined 741 within the source file. 743 Appendix A: Differences from RFC 5120 745 TRILL multi-topology, as specified in this document, differs from RFC 746 5120 as follows: 748 1. [RFC5120] provides for unicast multi-topology. This document 749 extends that to cover multi-destination TRILL data distribution 750 (see Section 3.4). 752 2. [RFC5120] assumes the topology of data packets is always 753 determined implicitly, that is, based on the port over which the 754 packets are received and/or pre-existing fields within the packet. 755 This document supports such implicit determination but extends 756 this by providing for optional explicit topology labeling of data 757 packets (see Section 2.4). 759 3. [RFC5120] makes support of the default topology zero optional for 760 MT routers and links. For simplicity and ease in network 761 management, this document requires all TRILL switches and links 762 between TRILL switches to support topology zero (see Section 2.1). 764 Authors' Addresses 766 Donald Eastlake 3rd 767 Huawei Technologies 768 155 Beaver Street 769 Milford, MA 01757 USA 771 Phone: +1-508-333-2270 772 Email: d3e3e3@gmail.com 774 Mingui Zhang 775 Huawei Technologies Co., Ltd 776 HuaWei Building, No.3 Xinxi Rd., Shang-Di 777 Information Industry Base, Hai-Dian District, 778 Beijing, 100085 P.R. China 780 Email: zhangmingui@huawei.com 782 Ayan Banerjee 783 Cisco 784 170 W. Tasman Drive 785 San Jose, CA 95134 787 Email: ayabaner@cisco.com 789 Copyright, Disclaimer, and Additional IPR Provisions 791 Copyright (c) 2016 IETF Trust and the persons identified as the 792 document authors. All rights reserved. 794 This document is subject to BCP 78 and the IETF Trust's Legal 795 Provisions Relating to IETF Documents 796 (http://trustee.ietf.org/license-info) in effect on the date of 797 publication of this document. Please review these documents 798 carefully, as they describe your rights and restrictions with respect 799 to this document. Code Components extracted from this document must 800 include Simplified BSD License text as described in Section 4.e of 801 the Trust Legal Provisions and are provided without warranty as 802 described in the Simplified BSD License. The definitive version of 803 an IETF Document is that published by, or under the auspices of, the 804 IETF. Versions of IETF Documents that are published by third parties, 805 including those that are translated into other languages, should not 806 be considered to be definitive versions of IETF Documents. The 807 definitive version of these Legal Provisions is that published by, or 808 under the auspices of, the IETF. Versions of these Legal Provisions 809 that are published by third parties, including those that are 810 translated into other languages, should not be considered to be 811 definitive versions of these Legal Provisions. For the avoidance of 812 doubt, each Contributor to the IETF Standards Process licenses each 813 Contribution that he or she makes as part of the IETF Standards 814 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 815 language to the contrary, or terms, conditions or rights that differ 816 from or are inconsistent with the rights and licenses granted under 817 RFC 5378, shall have any effect and shall be null and void, whether 818 published or posted by such Contributor, or included with or in such 819 Contribution.