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