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