idnits 2.17.1 draft-ietf-trill-multi-topology-00.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 (September 1, 2015) is 3154 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' -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Vishwas Manral 7 Ionos 8 Expires: February 27, 2016 September 1, 2015 10 TRILL: Multi-Topology 11 13 Abstract 14 This document specifies extensions to the IETF TRILL (Transparent 15 Interconnection of Lots of Links) protocol to support multi-topology 16 routing of unicast and multi-destination traffic based on IS-IS 17 (Intermediate System to Intermediate System) multi-topology specified 18 in RFC 5120. This document updates RFC 6325 and RFC 7177. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the TRILL working group mailing list. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Terminology............................................4 48 2. Topologies..............................................5 49 2.1 Special Topology Zero..................................5 50 2.2 Links and Multi-Topology...............................5 51 2.3 TRILL Switches and Multi-Topology......................5 52 2.4 TRILL Data Packets and Multi-Topology..................6 53 2.4.1 Explicit Topology Labeling Support...................6 54 2.4.2 Explicit Topology Labels.............................7 56 3. TRILL Multi-Topology Adjacency and Routing..............9 57 3.1 Adjacency (Updates to RFC 7177)........................9 58 3.2 TRILL Switch Nicknames.................................9 59 3.3 TRILL Unicast Routing.................................10 60 3.4 TRILL Multi-Destination Routing.......................10 61 3.4.1 Distribution Trees..................................10 62 3.4.2 Multi-Access Links..................................12 64 4. Mixed Links............................................13 66 5. Other Multi-Topology Considerations....................14 67 5.1 Address Learning......................................14 68 5.1.1 Data Plane Learning.................................14 69 5.1.2 Multi-Topology ESADI................................14 70 5.2 Legacy Stubs..........................................14 71 5.3 RBridge Channel Messages..............................14 72 5.4 Implementations Considerations........................15 74 6. Allocation Considerations..............................16 75 6.1 IEEE Registration Authority Considerations............16 76 6.2 IANA Considerations...................................16 78 7. Security Considerations................................17 80 Normative References......................................18 81 Informative References....................................19 83 Acknowledgements..........................................20 84 Appendix A: Differences from RFC 5120.....................21 85 Authors' Addresses........................................22 87 1. Introduction 89 This document specifies extensions to the IETF TRILL (Transparent 90 Interconnection of Lots of Links) protocol [RFC6325] [RFC7176] 91 [RFC7177] to support multi-topology routing for both unicast and 92 multi-destination traffic based on IS-IS (Intermediate System to 93 Intermediate System, [IS-IS]) multi-topology [RFC5120]. 94 Implementation and use of multi-topology are optional and use 95 requires configuration. It is anticipated that not all TRILL campuses 96 will need or use multi-topology. 98 Multi-topology creates different topologies or subsets from a single 99 physical TRILL campus topology. This is different from Data Labels 100 (VLANs and Fine Grained Labels [RFC7172]). Data Labels specify 101 communities of end stations and can be viewed as creating virtual 102 topologies of end station connectivity. However, in a single topology 103 TRILL campus, TRILL Data packets can use any part of the physical 104 topology of TRILL switches and links between TRILL switches, 105 regardless of the Data Label of that packet's payload. In a multi- 106 topology TRILL campus, TRILL data packets in a topology are 107 restricted to the TRILL switches and links that are in their topology 108 but may still use any of the TRILL switches and links in their 109 topology regardless of the Data Label of their payload. 111 The essence of multi-topology behavior is that a multi-topology 112 router classifies packets as to the topology within which they should 113 be routed and uses logically different routing tables for different 114 topologies. If routers in the network do not agree on the topology 115 classification of packets or links, persistent routing loops can 116 occur. 118 The multi-topology TRILL extensions can be used for a wide variety of 119 purposes, such as maintaining separate routing domains for isolated 120 multicast or IPv6 islands, routing a class of traffic so that it 121 avoids certain TRILL switches that lack some characteristic needed by 122 that traffic, or making a class of traffic avoid certain links due to 123 security, reliability, or other concerns. 125 It is possible for a particular topology to not be fully connected 126 resulting in two or more islands of that topology. In that case, end 127 station connected in that topology to different islands will be 128 unable to communicate with each other. 130 Multi-topology TRILL supports regions of topology ignorant TRILL 131 switches as part of an multi-topology campus; however, such regions 132 can only ingress, egress, or transit TRILL Data frames in the special 133 base topology zero. 135 1.1 Terminology 137 The terminology and acronyms of [RFC6325] are used in this document. 138 Some of these are listed below for convenience along with some 139 additional terms. 141 campus - The name for a TRILL network, like "bridged LAN" is a 142 name for a bridged network. It does not have any academic 143 implication. 145 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine- 146 Grained Label [RFC7172]. 148 LSP - [IS-IS] Link State PDU (Protocol Data Unit). For TRILL this 149 includes L1-LSPs and E-L1FS-LSPs [rfc7180bis]. 151 MT - Multi-Topology, this document and [RFC5120]. 153 MT TRILL Switch - A FGL TRILL switch supporting the multi-topology 154 feature specified in this document. 156 RBridge - "Routing Bridge", an alternative name for a TRILL 157 switch. 159 TRILL - Transparent Interconnecton of Lots of Links or Tunneled 160 Routing in the Link Layer [RFC6325]. 162 TRILL Switch - A switch implementing the TRILL protocol. 164 VL - VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2. Topologies 172 In TRILL multi-topology, a topology is a subset of the TRILL switches 173 and of the links between TRILL switches in a TRILL campus. TRILL Data 174 packets are constrained to the subset of switches and links 175 corresponding to the packet's topology. TRILL multi-topology is based 176 on [RFC5120] IS-IS multi-topology. See Appendix A for differences 177 between TRILL multi-topology and [RFC5120]. 179 The zero topology is special as described in Section 2.1. Sections 180 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and 181 TRILL Data packets respectively. 183 2.1 Special Topology Zero 185 The zero topology is special as the default base topology. All TRILL 186 switches and links are considered to be in and MUST support topology 187 zero. Thus, for example, topology zero can be used for general TRILL 188 switch access within a campus for management messages, BFD messages 189 [RFC7175], RBridge Channel messages [RFC7178], and the like. 191 2.2 Links and Multi-Topology 193 Multi-topology TRILL switches advertise the topologies for which they 194 are willing to send and received TRILL Data packets on a port by 195 listing those topologies in one or more MT TLVs [RFC5120] appearing 196 in every TRILL Hello [RFC7177] they send out that port, except that 197 they MUST handle topology zero, which it is optional to list. 199 A link is only usable for TRILL Data packets in non-zero topology T 200 if 201 (1) all TRILL switch ports on the link advertise topology T support 202 in their Hellos and 203 (2) if any TRILL switch port on the link requires explicit TRILL Data 204 packet topology labeling (see Section 2.4) every other TRILL 205 switch port on the link is capable of generating explicit packet 206 topology labeling. 208 2.3 TRILL Switches and Multi-Topology 210 A TRILL switch advertises the topologies that it supports by listing 211 them in one or more MT TLVs [RFC5120] in its LSP except that it MUST 212 support topology zero which is optional to list. 214 There is no general "MT capability bit". A TRILL switch advertises 215 that it is MT capable by advertising in its LSP support for any 216 topology or topologies with the MT TLV, even if it just explicitly 217 advertises support for topology zero. 219 2.4 TRILL Data Packets and Multi-Topology 221 Commonly, the topology of a TRILL Data packet is determined from 222 either (1) some field or fields present in the packet itself or (2) 223 the port on which the packet was received; however optional explicit 224 topology labeling of TRILL Data packets is also proved. This can be 225 included in the data labeling area of TRILL Data packets as specified 226 below. 228 Examples of fields that might be used to determine topology are 229 values or ranges of values of the payload VLAN or Fine Grained Label 230 [RFC7172], packet priority, IP version (IPv6 versus IPv4) or IP 231 protocol, Ethertype, unicast versus multi-destination payload, IP 232 Differentiated Services Code Point (DSCP) bits, or the like. 234 "Multi-topology" does not apply to TRILL IS-IS packets or to link 235 level control frames. Those messages are link local and can be 236 thought of as being above all topologies. "Multi-topology" only 237 applies to TRILL Data packets. 239 2.4.1 Explicit Topology Labeling Support 241 Support of the explicit topology label is optional even for MT TRILL 242 switches. Support could depend on port hardware and is indicated by 243 a two-bit capability field in the Port TRILL Version sub-TLV 244 [RFC7176] appearing in the Port Capabilities TLV in Hellos. If there 245 is no Port TRILL Capabilities sub-TLV in a Hello, then it is assumed 246 that explicit topology labeling is not supported on that port. See 247 the table below for the meaning of values of the Explicit Topology 248 capability field: 250 Value Meaning 251 ----- ------- 252 0 No support. Cannot send TRILL Data packets with an explicit 253 topology label and should treat as erroneous and discard any 254 data packet received with a topology label. 255 1 Capable of inserting an explicit topology label in data 256 packets sent and tolerant of such labels in received data 257 packets. Such a port is capable of determining TRILL Data 258 packet topology without an explicit lable for all of the 259 topologies it supports and thus does not require such a label 260 in received TRILL Data packets. On receiving a packet whose 261 explicit topology label differs from the ports topology 262 determination for that packet, the TRILL switch MUST discard 263 the packet. 264 2/3 Requires an explicit topology label in received TRILL Data packets 265 except for topology zero. Any TRILL Data packets received 266 without such a label is classified as being in topology zero. 267 Also capable of inserting an explicit topology label in TRILL 268 Data packets sent. (Values 2 and 3 are treated the same, 269 which is the same as saying that if the 2 bit is on, the 1 270 bit is ignored.) 272 A TRILL switch advertising in a Hello on Port P support for topology 273 T but not advertising in those Hellos that it requires explicit 274 topology labeling is assumed to have the ability and configuration to 275 correctly classify TRILL Data packets into topology T by examination 276 of those TRILL Data packets and/or by using the fact that they are 277 arriving at port P. 279 When a TRILL switch transmits a TRILL Data packet onto a link, if any 280 other TRILL switch on that link requires explicit topology labeling, 281 an explicit topology label MUST be included. If a label is not so 282 required but all other TRILL switches on that link support explicit 283 topology labeling, then such a label MAY be included. 285 2.4.2 Explicit Topology Labels 287 The TRILL MT label is structured as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | TRILL-MT Ethertype TBD | RESV | MT-ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 1. TRILL MT Label 297 where RESV is a 4-bit reserved field that MUST be sent as zero and 298 ignored on receipt and MT-ID is the 12-bit topology of the TRILL Data 299 packet using the topology number space of the MT TLV [RFC5120]. With 300 the addition of the TRILL MT label, the four standardized content 301 varieties for the TRILL Data packet data labeling area (the area 302 after the Inner.MacSA and before the payload) are as show below. 303 {PRI, D} is a 3-bit priority and a drop eligibility indicator bit 304 [rfc7180bis]. All MT TRILL switches MUST support FGL and thus MUST 305 support all four data labeling area contents shown below. 307 1. C-VLAN [RFC6325] 309 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | 0x8100 | PRI |D| VLAN ID | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 2. FGL [RFC7172] 317 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | 0x893B | PRI |D| FGL High Part | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | 0x893B | PRI |D| FGL Low Part | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 3. MT C-VLAN [this document] 327 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | TRILL-MT Ethertype TBD | RESV | MT-ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | 0x8100 | PRI |D| VLAN ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 4. MT FGL [this document] [RFC7172] 337 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | TRILL-MT Ethertype TBD | RESV | MT-ID | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | 0x893B | PRI |D| FGL High Part | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | 0x893B | PRI |D| FGL Low Part | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Inclusion of S-VLAN or other stacked tags is beyond the scope of this 348 document but, as stated in [RFC6325], is an obvious extension. 350 3. TRILL Multi-Topology Adjacency and Routing 352 Routing calculations in IS-IS are based on adjacency. Section 3.1 353 specifies multi-topology updates to the TRILL adjacency 354 specification. Section 3.2 describes the handling of nicknames. 355 Sections 3.3 and 3.4 specify how unicast and multi-destination TRILL 356 multi-topology routing differ from the TRILL base protocol. 358 3.1 Adjacency (Updates to RFC 7177) 360 There is no change in the determination or announement of adjacency 361 for topology zero which is as specified in [RFC7177]. When an 362 adjacency reaches the Report state as specified in [RFC7177], the 363 adjacency is announced for topology zero in LSPs using the Extended 364 Intermediate System Reachability TLV (#22). 366 Adjacency is announced for non-zero topologies in LSPs using the MT 367 Reachable Intermediate Systems TLV as specified in [RFC5120]. The 368 ports on a TRILL link are reported as adjacent for non-zero topology 369 T if and only if that adjacency is in the Report state [RFC7177] and 370 the two conditions listed in Section 2.2 are true, namely: 372 1. All the ports on the link are announcing support of topology T. 374 2. If any port announces that it requires explicit topology labeling 375 (Explicit Topology capability field value 2 or 3), all other ports 376 advertise that they are capable of producing such labeling 377 (Explicit Topology capability field value of 1, 2, or 3). 379 3.2 TRILL Switch Nicknames 381 TRILL switches are usually identified within the TRILL protocol (for 382 example in the TRILL Header) by nicknames [RFC6325] [rfc7180bis]. 383 Such nicknames can be viewed as simply 16-bit abbreviation for a 384 TRILL switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL 385 switch or pseudo-node can have more than one nickname, each of which 386 identifies it. 388 Nicknames are common across all topologies, just as IS-IS System IDs 389 are. Nicknames are determined as specified in [RFC6325] and 390 [rfc7180bis] using only the Nickname sub-TLVs appearing in Router 391 Capabilities TLVs (#242) advertised by TRILL switches. In particular, 392 the nickname allocation algorithm ignores Nickname sub-TLVs that 393 appear in MT Router Capability TLVs (#144). (However, nickname sub- 394 TLVs that appear in MT Router Capability TLVs with a non-zero 395 topology do affect the choice of distribution tree roots as described 396 in Section 3.4.1.) 398 To minimize transient inconsistencies, all Nickname sub-TLVs 399 advertised by a TRILL switch for a particular nickname, whether in 400 Router Capability or MT Router Capability TLVs, SHOULD appear in the 401 same LSP. If that is not the case, then all LSPs in which they do 402 occur SHOULD be flooded as an atomic action. 404 3.3 TRILL Unicast Routing 406 TRILL Data packets being TRILL unicast (those with TRILL Header M bit 407 = 0) are routed based on the egress nickname using logically separate 408 forwarding tables per topology where each such table has been 409 calculated based on least cost routing within the particular 410 topology. Thus, the next hop when forwarding TRILL Data packets is 411 determined by a lookup logically based on {topology, egress 412 nickname}. 414 3.4 TRILL Multi-Destination Routing 416 TRILL sends multi-destination data packets (those packets with TRILL 417 Header M bit = 1) over a distribution tree. Trees are designated by 418 nicknames that appear in the "egress nickname" field of multi- 419 destination TRILL Data packets. To constrain multi-destination 420 packets to a topology and still distribute them properly requires the 421 use of a distribution tree constrained to that topology. Handling 422 such TRILL Data packets and distribution trees in MT is as described 423 in the subsections below. 425 3.4.1 Distribution Trees 427 General provisions for distribution trees and how those trees are 428 determined are as specified in [RFC6325], [RFC7172], and 429 [rfc7180bis]. The distribution trees for topology zero are determined 430 as specified in those references and are the same as they would be 431 with topology-ignorant TRILL switches. 433 The TRILL distribution tree construction and packet handling for some 434 non-zero topology T are determine as specified in [RFC6325], 435 [RFC7172], and [rfc7180bis] with the following changes: 437 o As specified in [RFC5120], only links usable with topology T 438 TRILL Data frames are considered when building a distribution 439 tree for topology T. As a result, such trees are automatically 440 limited to and separately span every internally connected 441 island of topology T. In other words, if non-zero topology T 442 consists of disjoint islands, distribution tree construction 443 for topology T is local to each such island. 445 o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub- 446 TLV, and Trees Used sub-TLV occurring in an MT Router 447 Capabilities TLV (#144) specifying topology T are used in 448 determining the tree root(s), if any, for non-zero topology T. 450 + There may be non-zero topologies with no multi-destination 451 traffic. For example, if only known destination unicast IPv6 452 TRILL Data packets were in topology T and all multi- 453 destination IPv6 TRILL Data packets were in some other 454 topology, there would be no need for a distribution tree for 455 topology T. For this reasons, a Number of Trees to Compute 456 of zero in the Trees sub-TLV for the TRILL switch holding 457 the highest priority to be a tree root for a non-zero 458 topology T is honored and causes no distribution trees to be 459 calculated for non-zero topology T. This is different from 460 the base topology zero where, as specified in [RFC6325], a 461 zero Number of Trees to Compute causes one tree to be 462 computed. 464 o Nicknames are allocated as described in Section 3.2. If a 465 TRILL switch advertising that it provides topology T service 466 holds nickname N, the priority of N to be a tree root is given 467 by the tree root priority field of the Nickname sub-TLV that 468 has N in its nickname field and occurs in a topology T MT 469 Router Capabilities TLV advertised by that TRILL switch. If no 470 such Nickname sub-TLV can be found, the priority of N to be a 471 tree root is the default for an FGL TRILL switch as specified 472 in [RFC7172]. 474 + There could be multiple topology T Nickname sub-TLVs for N 475 being advertised for a particular RBridge or pseudo-node, 476 due to transient conditions or errors. In that case, the one 477 in the lowest numbered LSP fragment is used and if there are 478 multiple in that fragment, the one with the smallest offset 479 from the beginning of the LSP is used. 481 o Tree pruning for topology T uses only the Interested VLANs and 482 Interested Labels sub-TLVs [RFC7176] advertised in MT Router 483 Capabilities TLVs for topology T. 485 An MT TRILL switch MUST have logically separate routing tables per 486 topology for the forwarding of multi-destination traffic. 488 3.4.2 Multi-Access Links 490 Multi-destination TRILL Data packets are forwarded on broadcast 491 (multi-access) links in such a way as to be received by all other 492 TRILL switch ports on the link. For example, on Ethernet links they 493 are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken 494 that a TRILL Data packet in a non-zero topology is only forwarded by 495 an MT TRILL switch. 497 For this reason, a non-zero topology TRILL Data packet MUST NOT be 498 forwarded onto a link unless the link meets the requirements 499 specified in Section 2.2 for use in that topology even if there are 500 one or more MT TRILL switch ports on the link. 502 4. Mixed Links 504 A link might have any combination of MT, FGL, or even VL TRILL 505 switches on it [RFC7172]. DRB (Designated RBridge) election and 506 Forwarder appointment on the link work as previously specified in 507 [RFC6439] and [RFC7177]. It is up to the network manager to configure 508 and manage the TRILL switches on a link so that the desired switch is 509 DRB and the desired switch is the Appointed Forwarder for the 510 appropriate VLANs. 512 Frames ingressed by MT TRILL switches can potentially be in any 513 topology recognized by the switch and permitted on the ingress port. 514 Frames ingressed by VL or FGL TRILL switches can only be in the base 515 zero topology. Because FGL and VL TRILL switches do not understand 516 topologies, all occurrences of the following sub-TLVs MUST occur only 517 in MT Port Capability TLVs with a zero MT-ID. Any occurrence of these 518 sub-TVLs in an MT Port Capability TLV with a nonzero MT-ID is 519 ignored. 521 Special VLANs and Flags Sub-TLV 522 Enabled-VLANs Sub-TLV 523 Appointed Forwarders Sub-TLV 524 VLANs Appointed Sub-TLV 526 Native frames cannot be explicitly labeled (see Section 2.4) as to 527 their topology. 529 5. Other Multi-Topology Considerations 531 5.1 Address Learning 533 The learning of end station MAC addresses is per topology as well as 534 per label (VLAN or FGL). The same MAC address can occur within a 535 TRILL campus for different end stations that differ only in topology. 537 5.1.1 Data Plane Learning 539 End station MAC addresses learned from ingressing native frames or 540 egressing TRILL Data packets are, for MT TRILL switches, qualified by 541 topology. That is, either the topology into which that TRILL switch 542 classified the ingressed native frame or the topology that the 543 egressed TRILL Data frame was in. 545 5.1.2 Multi-Topology ESADI 547 In an MT TRILL switch, ESADI [RFC7357] operates per label (VLAN or 548 FGL) per topology. Since ESADI messages appear, to transit TRILL 549 switches, like normal multi-destination TRILL Data packets, ESADI 550 link state databases are per topology as well as per label and local 551 to each area of multi-destination TRILL data connectivity for that 552 topology. 554 5.2 Legacy Stubs 556 Areas of topology ignorant TRILL switches can be connected to and 557 become part of an MT TRILL campus but will only be able to ingress, 558 transit, or egress topology zero TRILL Data packets. 560 5.3 RBridge Channel Messages 562 RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175] 563 appear, to transit TRILL switches, like normal multi-destination 564 TRILL Data packets. Thus, they have a topology and are constrained by 565 topology like other TRILL Data packets. Generally, when sent for 566 network management purposes, they are sent in topology zero. 568 5.4 Implementations Considerations 570 MT is an optional TRILL switch capability. 572 Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] 573 indicates that a single router handling more than eight topologies is 574 rare. There may be many more than eight distinct topologies in a 575 routed area, such as a TRILL campus, but in that case many of these 576 topologies will be handled by disjoint sets of routers and/or links. 578 Based on this deployment experience, a TRILL switch capable of 579 handling 8 or more topologies can be considered a full implementation 580 while a TRILL switch capable of handling 4 topologies can be 581 considered a minimal implementation but still useful under some 582 circumstances. 584 6. Allocation Considerations 586 IEEE Registration Authority and IANA considerations are given below. 588 6.1 IEEE Registration Authority Considerations 590 The IEEE Registration Authority will be requested to allocate a new 591 Ethertype for TRILL-MT (see Section 2.4). 593 6.2 IANA Considerations 595 IANA is requested to assign a field of two adjacent bits TBD from 596 bits 14 through 31 of the Capabilities bits of the Port TRILL Version 597 Sub-TLV for the Explicit Topology capability field. 599 7. Security Considerations 601 Multiple topologies are sometimes used for the isolation or security 602 of traffic. For example, if some links was more likely than others to 603 be subject to adversarial observation it might be desirable to 604 classify certain sensitive traffic in a topology that excluded those 605 links. 607 Delivery of data originating in one topology outside of that topology 608 is generally a security policy violation to be avoided at all 609 reasonable costs. 611 For general TRILL security considerations, see [RFC6325]. 613 Normative References 615 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 616 Intermediate System Intra-Domain Routeing Exchange Protocol for 617 use in Conjunction with the Protocol for Providing the 618 Connectionless-mode Network Service (ISO 8473)", 2002. 620 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 624 Topology (MT) Routing in Intermediate System to Intermediate 625 Systems (IS-ISs)", RFC 5120, February 2008. 627 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 628 Ghanwani, "Routing Bridges (RBridges): Base Protocol 629 Specification", RFC 6325, July 2011. 631 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 632 and D. Dutt, "Transparent Interconnection of Lots of Links 633 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 635 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 636 D., and A. Banerjee, "Transparent Interconnection of Lots of 637 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 639 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 640 and V. Manral, "Transparent Interconnection of Lots of Links 641 (TRILL): Adjacency", RFC 7177, May 2014. 643 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 644 Ward, "Transparent Interconnection of Lots of Links (TRILL): 645 RBridge Channel Support", RFC 7178, May 2014. 647 [RFC7357] - Hhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 648 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 649 End Station Address Distribution Information (ESADI) Protocol", 650 RFC 7357, DOI 10.17487/RFC7357, September 2014, 651 . 653 [rfc7180bis] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, 654 A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of 655 Lots of Links (TRILL): Clarifications, Corrections, and 656 Updates", draft-ietf-trill-rfc7180bis, work in progress. 658 Informative References 660 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 661 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 662 6439, November 2011. 664 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 665 "Transparent Interconnection of Lots of Links (TRILL): 666 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 667 May 2014. 669 Acknowledgements 671 The comments and suggestions of the following are gratefully 672 acknowledged: 674 TBD 676 The document was prepared in raw nroff. All macros used were defined 677 within the source file. 679 Appendix A: Differences from RFC 5120 681 This document differs from RFC 5120 as follows: 683 1. [RFC5120] provides for unicast multi-topology. This document 684 extends that to cover multi-destination TRILL data distribution 685 (see Section 3.4). 687 2. [RFC5120] assumes the topology of data packets is always 688 determined implicitly, that is, based on the port over which the 689 packets are received and/or pre-existing fields within the packet. 690 This document supports implicit determination but extends this for 691 TRILL by providing for optional explicit topology labeling of 692 TRILL Data packets (see Section 2.4). 694 3. [RFC5120] makes support of the default topology zero optional for 695 MT routers and links. For simplicity and ease in network 696 management, this document requires all TRILL switches and links 697 between TRILL switches to support topology zero (see Section 2.1). 699 Authors' Addresses 701 Donald Eastlake 3rd 702 Huawei Technologies 703 155 Beaver Street 704 Milford, MA 01757 USA 706 Phone: +1-508-333-2270 707 Email: d3e3e3@gmail.com 709 Mingui Zhang 710 Huawei Technologies Co., Ltd 711 HuaWei Building, No.3 Xinxi Rd., Shang-Di 712 Information Industry Base, Hai-Dian District, 713 Beijing, 100085 P.R. China 715 Email: zhangmingui@huawei.com 717 Ayan Banerjee 718 Cisco 719 170 W. Tasman Drive 720 San Jose, CA 95134 722 Email: ayabaner@cisco.com 724 Vishwas Manral 725 Ionos Corp. 726 4100 Moorpark Ave. 727 San Jose, CA 95117 USA 729 EMail: vishwas@ionosnetworks.com 731 Copyright, Disclaimer, and Additional IPR Provisions 733 Copyright (c) 2015 IETF Trust and the persons identified as the 734 document authors. All rights reserved. 736 This document is subject to BCP 78 and the IETF Trust's Legal 737 Provisions Relating to IETF Documents 738 (http://trustee.ietf.org/license-info) in effect on the date of 739 publication of this document. Please review these documents 740 carefully, as they describe your rights and restrictions with respect 741 to this document. Code Components extracted from this document must 742 include Simplified BSD License text as described in Section 4.e of 743 the Trust Legal Provisions and are provided without warranty as 744 described in the Simplified BSD License. The definitive version of 745 an IETF Document is that published by, or under the auspices of, the 746 IETF. Versions of IETF Documents that are published by third parties, 747 including those that are translated into other languages, should not 748 be considered to be definitive versions of IETF Documents. The 749 definitive version of these Legal Provisions is that published by, or 750 under the auspices of, the IETF. Versions of these Legal Provisions 751 that are published by third parties, including those that are 752 translated into other languages, should not be considered to be 753 definitive versions of these Legal Provisions. For the avoidance of 754 doubt, each Contributor to the IETF Standards Process licenses each 755 Contribution that he or she makes as part of the IETF Standards 756 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 757 language to the contrary, or terms, conditions or rights that differ 758 from or are inconsistent with the rights and licenses granted under 759 RFC 5378, shall have any effect and shall be null and void, whether 760 published or posted by such Contributor, or included with or in such 761 Contribution.