idnits 2.17.1 draft-ietf-trill-fine-labeling-07.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 17, 2013) is 3997 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 normative reference: RFC 6327 (Obsoleted by RFC 7177) -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Mingui Zhang 3 Intended status: Proposed Standard Huawei 4 Updates: 6325 Puneet Agarwal 5 Broadcom 6 Radia Perlman 7 Intel Labs 8 Dinesh Dutt 9 Cumulus Networks 10 Expires: November 16, 2013 May 17, 2013 12 TRILL (Transparent Interconnection of Lots of Links): 13 Fine-Grained Labeling 14 16 Abstract 18 The IETF has standardized TRILL (Transparent Interconnection of Lots 19 of Links), a protocol for least cost transparent frame routing in 20 multi-hop networks with arbitrary topologies and link technologies, 21 using link-state routing and a hop count. The TRILL base protocol 22 standard supports labeling of TRILL data with up to 4K IDs. However, 23 there are applications that require a larger number of labels 24 providing configurable isolation of data. This document updates RFC 25 6325 by specifying optional extensions to the TRILL base protocol to 26 safely accomplish this. These extensions, called fine grained 27 labeling, are primarily intended for use in large Data Centers, those 28 with >4K users requiring configurable data isolation from each other. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Distribution of this document is unlimited. Comments should be sent 36 to the TRILL working group mailing list. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................4 55 1.1 Terminology............................................5 56 1.2 Contributors...........................................5 58 2. Fine-Grained Labeling...................................6 59 2.1 Goals..................................................6 60 2.2 Base Protocol TRILL Data Labeling......................7 61 2.3 Fine-Grained Labeling (FGL)............................8 62 2.4 Reasons for VL and FGL Co-existence....................9 64 3. VL versus FGL Label Differences........................10 66 4. FGL Processing.........................................11 67 4.1 Ingress Processing....................................11 68 4.1.1 Multi-Destination FGL Ingress.......................11 69 4.2 Transit Processing....................................12 70 4.2.1 Unicast Transit Processing..........................12 71 4.2.2 Multi-Destination Transit Processing................12 72 4.3 Egress Processing.....................................13 73 4.4 Appointed Forwarders and the DRB......................14 74 4.5 Distribution Tree Construction........................14 75 4.6 Address Learning......................................15 76 4.7 ESADI Extension.......................................15 78 5. FGL TRILL Interaction with VL TRILL....................16 79 5.1 FGL and VL Mixed Campus...............................16 80 5.2 FGL and VL Mixed Links................................18 81 5.3 Summary of FGL-safe Requirements......................18 83 6. IS-IS Extensions.......................................20 84 7. Comparison to Goals....................................21 86 8. Allocation Considerations..............................22 87 8.1 IEEE Allocation Considerations........................22 88 8.2 IANA Considerations...................................22 90 9. Security Considerations................................23 91 Acknowledgements..........................................24 92 Normative References......................................25 93 Informative References....................................25 95 Appendix A: Serial Unicast................................26 97 Appendix B: Mixed Campus Characteristics..................27 98 B.1 Mixed Campus with High Cost Adjacencies...............27 99 B.2 Mixed Campus with Data Blocked Adjacencies............28 101 Appendix Z: Change History................................29 102 Authors' Addresses........................................31 104 1. Introduction 106 The IETF has standardized the TRILL (Transparent Interconnection of 107 Lots of Links) protocol [RFC6325] that provides a solution for least 108 cost transparent routing in multi-hop networks with arbitrary 109 topologies and link technologies, using [IS-IS] [RFC6165] 110 [RFC6326bis] link-state routing and a hop count. TRILL switches are 111 sometimes called RBridges (Routing Bridges). 113 The TRILL base protocol standard supports labeling of TRILL data with 114 up to 4K IDs. However, there are applications that require a larger 115 number of labels of data for configurable isolation based on 116 different tenants, service instances, or the like. This document 117 updates [RFC6325] by specifying optional extensions to the TRILL base 118 protocol to safely accomplish this. These extensions, called fine 119 grained labeling, are primarily intended for use in large Data 120 Centers, those with >4K users requiring configurable data isolation 121 from each other. 123 This document describes a format for allowing a data label of 24 124 bits, known as a "fine-grained label", or FGL. It also describes 125 coexistence and migration from current RBridges, known as "VL" (for 126 "VLAN labeled") RBridges to TRILL switches that can support FGL 127 ("Fine Grain Labeled") packets. Because various VL implementations 128 might handle FGL packets incorrectly, FGL packets cannot be 129 introduced until either all VL RBridges are upgraded to what we will 130 call "FGL-safe", which means that they will not "do anything bad" 131 with FGL packets, or all FGL RBridges take special precautions on any 132 port by which they are connected to a VL RBridge. FGL-safe 133 requirements are summarized in Section 5.3. 135 It is hoped that many RBridges can become FGL-safe through a software 136 upgrade. VL RBridges and FGL-safe RBridges can coexist without any 137 disruption to service, as long as no FGL packets are introduced. 139 If all RBridges are upgraded to FGL-safe, FGL traffic can be 140 successfully handled by the campus without any topology restrictions. 141 The existence of FGL traffic is known to all FGL RBridges because 142 some RBridge RB3 that might source or sink FGL traffic will advertise 143 interest in one or more fine-grained labels in its LSP. If any VL 144 RBridges remain at the point when any RBridge announces that it might 145 source or sink FGL traffic, the adjacent FGL-safe RBridges MUST 146 ensure that no FGL packets are forwarded to their VL RBridge 147 neighbor(s). The details are specified in Section 5.1 below. 149 1.1 Terminology 151 The terminology and acronyms of [RFC6325] are used in this document 152 with the additions listed below. 154 DEI - Drop Eligibility Indicator [802.1Q]. 156 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine- 157 Grained Label. 159 FGL-edge - An FGL TRILL switch advertising interest in an FGL 160 label. 162 FGL link - A link where all of the attached TRILL switches are 163 FGL. 165 FGL-safe - A TRILL switch that can safely be given an FGL data 166 packet as summarized in Section 5.3. 168 RBridge - Alternative name for a TRILL switch. 170 TRILL switch - Alternative name for an RBridge. 172 VL - VLAN Labeling or VLAN Labeled or VLAN Label. 174 VL link - A link where any of the attached RBridges is VL. 176 VL RBridge - A TRILL switch that supports VL but is not FGL-safe. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 1.2 Contributors 184 Thanks for the contributions of the following: 186 Tissa Senevirathne, Jon Hudson 188 2. Fine-Grained Labeling 190 The essence of Fine-Grained Labeling (FGL) is that (a) when frames 191 are ingressed or created they may incorporate a data label from a set 192 consisting of significantly more than 4K labels, (b) TRILL switch 193 ports can be labeled with a set of such fine-grained data labels, and 194 (c) an FGL TRILL Data frame cannot be egressed through a TRILL switch 195 port unless its fine-grained label (FGL) matches one of the data 196 labels of the port. 198 Section 2.1 lists FGL goals. Section 2.2 briefly outlines the more 199 coarse TRILL base protocol standard [RFC6325] data labeling. Section 200 2.3 outlines FGL for TRILL Data frames. And Section 2.4 discusses VL 201 and FGL co-existence. 203 2.1 Goals 205 There are several goals that would be desirable for FGL TRILL. They 206 are briefly described in the list below in approximate order by 207 priority with the most important first. 209 1. Fine-Grained 211 Some networks have a large number of entities that need 212 configurable isolation, whether those entities are independent 213 customers, applications, or branches of a single endeavor or some 214 combination of these or other entities. The labeling supported by 215 [RFC6325] provides for only ( 2**12 - 2 ) valid identifiers or 216 labels. A substantially larger number is required. 218 2. Silicon 220 Fine-grained labeling (FGL) should, to the extent practical, use 221 existing features, processing, and fields that are already 222 supported in many fast path silicon implementations that support 223 the TRILL base protocol. 225 3. Base RBridge Interoperation 227 To support some incremental conversion scenarios, it is desirable 228 that not all RBridges in a campus using FGL be required to be FGL 229 aware. That is, it is desirable if RBridges not implementing the 230 FGL features can exchange VL TRILL Data packets with FGL TRILL 231 switches. 233 4. Alternate Priority 235 It would be desirable for an ingress TRILL Switch to be able to 236 assign a different priority to an FGL TRILL Data packet for its 237 ingress-to-egress propagation from the priority of the original 238 native frame. The original priority should be restored on egress. 239 This enables traffic from attached non-TRILL networks to be 240 handled with different priority while transiting a TRILL network, 241 if desired. 243 2.2 Base Protocol TRILL Data Labeling 245 This section provides a brief review of the [RFC6325] TRILL Data 246 packet VL Labeling and changes the description of the TRILL Header by 247 moving its end point. This change in description does not involve any 248 change in the bits on the wire or in the behavior of VL TRILL 249 switches. 251 VL TRILL Data packets have the structure shown below: 253 +-------------------------------------------+ 254 | Link Header (depends on link technology) | 255 | (if link is an Ethernet link the link | 256 | header may include an Outer.VLAN tag) | 257 +-------------------------------------------+ 258 | TRILL Header | 259 | +---------------------------------------+ | 260 | | Initial Fields and Options | | 261 | +---------------------------------------+ | 262 | | Inner.MacDA | (6 bytes) | 263 | +-----------------------------+ | 264 | | Inner.MacSA | (6 bytes) | 265 | +-----------------------+-----+ | 266 | | Ethertype 0x8100 | (2 bytes) | 267 | +-----------------------+ | 268 | | Inner.VLAN Label | (2 bytes) | 269 | +-----------------------+ | 270 +-------------------------------------------+ 271 | Native Payload | 272 +-------------------------------------------+ 273 | Link Trailer (depends on link technology) | 274 +-------------------------------------------+ 276 Figure 1. TRILL Data with VL 278 In the base protocol as specified in [RFC6325] the 0x8100 value is 279 always present and is followed by the Inner.VLAN field which includes 280 the 12-bit VL. 282 2.3 Fine-Grained Labeling (FGL) 284 FGL expands the variety of data labels available under the TRILL 285 protocol to include a fine-grained label (FGL) with a 12-bit high 286 order part and a 12-bit low order part. In this document, FGLs are 287 denoted as "(X.Y)" where X is the high order part and Y is the low 288 order part of the FGL. 290 FGL TRILL Data packets have the structure shown below. 292 +-------------------------------------------+ 293 | Link Header (depends on link technology) | 294 | (if link is an Ethernet link the link | 295 | header may include an Outer.VLAN tag) | 296 +-------------------------------------------+ 297 | TRILL Header | 298 | +---------------------------------------+ | 299 | | Initial Fields and Options | | 300 | +---------------------------------------+ | 301 | | Inner.MacDA | (6 bytes) | 302 | +-----------------------------+ | 303 | | Inner.MacSA | (6 bytes) | 304 | +-----------------------+-----+ | 305 | | Ethertype 0x893B | (2 bytes) | 306 | +-----------------------+ | 307 | | Inner.Label High Part | (2 bytes) | 308 | +-----------------------+ | 309 | | Ethertype 0x893B | (2 bytes) | 310 | +-----------------------+ | 311 | | Inner.Label Low Part | (2 bytes) | 312 | +-----------------------+ | 313 +-------------------------------------------+ 314 | Native Payload | 315 +-------------------------------------------+ 316 | Link Trailer (depends on link technology) | 317 +-------------------------------------------+ 319 Figure 2. TRILL Data with FGL 321 For FGL packets, the inner MAC address fields are followed by the FGL 322 information using 0x893B. There MUST be two occurrences of 0x893B as 323 shown. Should a TRILL switch processing a FGL TRILL Data packet 324 notice that the second occurrence is actually some other value, it 325 MUST discard the packet. (A TRILL switch transiting a TRILL Data 326 packet is not required to examine any fields past the initial fixed 327 fields and options although it may do so to support ECMP or 328 distribution tree pruning.) 330 The two bytes following each 0x893B have, in their low order 12 bits, 331 fine-grained label information. The upper 4 bits of those two bytes 332 are used for a 3-bit priority field and one Drop Eligibility 333 Indicator (DEI) bit as shown below. 335 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 336 +--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+ 337 |priority|DEI| label information | 338 +--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+ 340 Figure 3. FGL Part Data Structure 342 The priority field of the Inner.Label High Part is the priority used 343 for frame transport across the TRILL campus from ingress to egress. 344 The label bits in the Inner.Label High Part are the high order part 345 of the FGL and those bits in the Inner.Label Low Part are the low 346 order part of the FGL. The priority field of the Inner.Label Low Part 347 is remembered from the data frame as ingressed and is restored on 348 egress. 350 The appropriate FGL value for an ingressed or locally originated 351 native frame is determined by the ingress TRILL switch port as 352 specified in Section 4.1. 354 2.4 Reasons for VL and FGL Co-existence 356 For several reasons, as listed below, it is desirable for FGL TRILL 357 switches to be able to handle both FGL and VL TRILL Data packets. 359 o Continued support of VL packets means that, by taking 360 precautions specified herein, in many cases arrangements are 361 possible such as VL TRILL switches easily exchanging VL packets 362 through a core of FGL TRILL switches. 364 o Due to the way TRILL works, it may be desirable to have a 365 maintenance VLAN or FGL [OAMframework] in which all TRILL 366 switches in the campus indicate interest. It will be simpler to 367 use the same type of label for all TRILL switches for this 368 purpose. That implies using VL if there might be any VL TRILL 369 switches in the campus. 371 o If a campus is being upgraded from VL to to FGL, continued 372 support of VL allows long-term support of edges labeled as VL. 374 3. VL versus FGL Label Differences 376 There are differences between the semantics across a TRILL campus for 377 TRILL Data packets that are data labeled with VL and FGL. 379 With VL, data label IDs have the same meaning throughout the campus 380 and are from the same label space as the C-VLAN IDs used on Ethernet 381 links to end stations. 383 The larger FGL data label space is a different space from the VL data 384 label space. For ports configured for FGL, the C-VLAN on an ingressed 385 native frame is stripped and mapped to the FGL data label space with 386 a potentially different mapping for each port. A similar FGL to C- 387 VLAN mapping occurs per port on egress. Thus, for ports configured 388 for FGL, the native frame C-VLAN on one link corresponding to an FGL 389 can be different from the native frame C-VLAN corresponding to that 390 same FGL on a different link elsewhere in the campus or even a 391 different link attached to the same TRILL switch. The FGL label space 392 is flat and does not hierarchically encode any particular number of 393 native frame C-VLAN bits or the like. FGLs appear only inside TRILL 394 Data frames after the inner MAC addresses. 396 It is the responsibility of the network manager to properly configure 397 the TRILL switches in the campus to obtain the desired mappings. Such 398 configuration is expected to be automatic in many cases, based on 399 configuration databases and orchestration systems. 401 With FGL TRILL switches, many things remain the same because an FGL 402 can appear only as the Inner.Label inside a TRILL Data packet. As 403 such, only TRILL-aware devices will see a fine-grained label. The 404 Outer.VLAN that may appear on native frames and that may appear on 405 TRILL Data packets if they are on an Ethernet link, can only be a C- 406 VLAN tag. Thus ports of FGL TRILL switches, up through the usual VLAN 407 and priority processing, act as they do for VL TRILL switches: TRILL 408 switch ports provide a C-VLAN ID for an incoming frame and accept a 409 C-VLAN ID for a frame being queued for output. Appointed Forwarders 410 [RFC6439] on a link are still appointed for a C-VLAN. The Designated 411 VLAN for an Ethernet link is still a C-VLAN. 413 FGL TRILL switches have capabilities that are a superset of those for 414 VL TRILL switches. FGL TRILL switch ports can be configured for FGL 415 or VL with VL being the default. As with a base protocol [RFC6325] 416 TRILL switch, an unconfigured FGL TRILL switch port reports an 417 untagged frame it receives as being in VLAN 1. 419 4. FGL Processing 421 This section specifies ingress, transit, egress, and other processing 422 details for FGL TRILL switches. A transit or egress FGL TRILL switch 423 determines that a TRILL Data packet is FGL by detecting that the 424 Inner.MacSA is followed by 0x893B. 426 4.1 Ingress Processing 428 FGL-edge TRILL switch ports are configurable to ingress native frames 429 as FGL. Any port not so configured performs the previously specified 430 [RFC6325] VL ingress processing on native frames resulting in a VL 431 TRILL Data packet. (There is no change in Appointed Forwarder logic 432 (see Section 4.4).) An FGL-safe TRILL switch may have only VL ports, 433 in which case it is not required to support the capabilities for FGL 434 ingress described in this section. 436 FGL-edge TRILL switches support configurable per port mapping from 437 the C-VLAN of a native frame, as reported by the ingress port, to an 438 FGL. FGL TRILL switches MAY support other methods to determine the 439 FGL of an incoming native frame, such as based on the protocol of the 440 native frame or local knowledge. 442 The FGL ingress process MUST copy the priority and DEI (drop 443 eligibility indicator) associated with an ingressed native frame to 444 the upper 4 bits of the Inner.Label Low Order part. It SHOULD also 445 associate a possibly different mapped priority and DEI with an 446 ingressed frame but a TRILL switch might not be able to do so because 447 of implementation limitations. The mapped priority is placed in the 448 Inner.Label High Part. If such mapping is not supported then the 449 original priority and DEI MUST be placed in the Inner.Label High 450 Part. 452 4.1.1 Multi-Destination FGL Ingress 454 If a native frame that has a broadcast, multicast, or unknown MAC 455 destination address is FGL ingressed, it MUST be handled in one of 456 the following two ways. The choice of which method to use can vary 457 from frame to frame at the choice of the ingress TRILL switch. 459 (1) Ingress as a TRILL multi-destination data packet (TRILL Header 460 M bit = 1) on a distribution tree rooted at a nickname held by 461 an FGL RBridge or by the pseudonode of an FGL link. FGL TRILL 462 Data packets MUST NOT be sent on a tree rooted at a nickname 463 held by a VL TRILL switch or by the pseudonode of a VL link. 465 (2) Serially TRILL unicast the ingressed frame to the relevant 466 egress TRILL switches by using a known unicast TRILL Header (M 467 bit = 0). An FGL ingress TRILL switch SHOULD unicast a multi- 468 destination TRILL Data frame if there is only one relevant 469 egress FGL TRILL switch. The relevant egress TRILL switches 470 are determined by starting with those announcing interest in 471 the frame's (X.Y) label. That set SHOULD be further filtered 472 based on multicast listener and multicast router attachment 473 LSP announcements if the native frame was a multicast frame. 475 Using a TRILL unicast header for a multi-destination frame when it 476 has only one actual destination RBridge almost always improves 477 traffic spreading and decreases latency as discussed in Appendix A. 478 How to decide whether to use a distribution tree or serial unicast 479 for a multi-destination TRILL Data frame that has more than one 480 destination TRILL switch is beyond the scope of this document. 482 4.2 Transit Processing 484 Any FGL TRILL switch MUST be capable of TRILL Data frame transit 485 processing. Such processing is fairly straightforward as described in 486 Section 4.2.1 for known unicast TRILL Data packets and in Section 487 4.2.2 for multi-destination TRILL Data packets. 489 4.2.1 Unicast Transit Processing 491 There is very little change in TRILL Data frame unicast transit 492 processing. A transit TRILL switch forwards any unicast TRILL Data 493 packet to the next hop towards the egress TRILL switch as specified 494 in the TRILL Header. All transit TRILL switches MUST take the 495 priority and DEI used to forward a packet from the Inner.VLAN label 496 or the FGL Inner.Label High Part. These bits are in the same place in 497 the packet. 499 An FGL TRILL switch MUST properly distinguish flows if it provides 500 ECMP for unicast FGL TRILL Data packets. 502 4.2.2 Multi-Destination Transit Processing 504 Multi-destination TRILL Data packets are forwarded on a distribution 505 tree selected by the ingress TRILL switch except that an FGL ingress 506 TRILL switch MAY TRILL unicast such a frame to all relevant egress 507 TRILL switches, all as described in Section 4.1. The distribution 508 trees do not distinguish between FGL and VL multi-destination packets 509 except in pruning behavior if they provide pruning. There is no 510 change in the Reverse Path Forwarding Check. 512 An FGL TRILL switch, say RB1, having an FGL multi-destination frame 513 for label (X.Y) to forward on a distribution tree, SHOULD prune that 514 tree based on whether there are any TRILL switches on a tree branch 515 that are advertising connectivity to label (X.Y). In addition, RB1 516 SHOULD prune multicast frames based on reported multicast listener 517 and multicast router attachment in (X.Y). 519 Pruning is an optimization. If a transit TRILL switch does less 520 pruning than it could, there may be greater link utilization than 521 strictly necessary but the campus will still operate correctly. A 522 transit TRILL switch MAY prune based on an arbitrary subset of the 523 bits in the FGL label, for example only the High Part or only the Low 524 Part of the label. 526 4.3 Egress Processing 528 Egress processing is generally the reverse of ingress progressing 529 described in Section 4.1. An FGL-safe TRILL switch may have only VL 530 ports, in which case it is not required to support the capabilities 531 for FGL egress described in this section. 533 An FGL-edge TRILL switch MUST be able to covert in a configurable 534 fashion from the FGL in an FGL TRILL Data frame it is egressing to 535 the C-VLAN ID for the resulting native frame with different mappings 536 on a per port basis. The priority and DEI of the egressed native 537 frame are taken from the Inner.Label Low Order Part. A port MAY be 538 configured to strip output VLAN tagging. 540 It is the responsibility of the network manager to properly configure 541 the TRILL switches in the campus to obtain the desired mappings. 543 FGL egress is similar to VL egress, as follows: 545 1. If the Inner.MacDA is All-Egress-RBridges, special processing 546 applies based on the payload Ethertype (for example ESADI 547 [RFC6325] or RBridge Channel [RFCchannel]) and, if the payload 548 Ethertype is unknown, the packet is discarded. If the 549 Inner.MacDA is not All-Egress-RBridges, then 2 or 3 below apply 550 as appropriate. 552 2. A known unicast FGL TRILL Data packet (TRILL Header M bit = 0) 553 with a unicast Inner.MacDA is egressed to the FGL port or ports 554 matching its FGL and Inner.MacDA. If there are no such ports, 555 it is flooded out all FGL ports that have its FGL except any 556 ports for which the TRILL switch has knowledge that the frame's 557 Inner.MacDA cannot be present on the link out that port. 559 3. A multi-destination FGL TRILL Data packet is decapsulated and 560 flooded out all ports that have its FGL, subject to multicast 561 pruning. The same processing applies to a unicast FGL TRILL 562 Data packet with a broadcast or multicast Inner.MacDA that 563 might be received due to serial unicast. 565 An FGL TRILL switch MUST NOT egress an FGL packet with label (X.Y) to 566 any port not configured with that FGL even if the port is configured 567 to egress VL packets in VLAN X. 569 FGL TRILL switches MUST accept multi-destination TRILL Data packets 570 that are sent to them as TRILL unicast packets (packets with the 571 TRILL Header M bit set to 0). They locally egress such packets, if 572 appropriate, but MUST NOT forward them (other than egressing them as 573 native frames on their local links). 575 4.4 Appointed Forwarders and the DRB 577 There is no change in Adjacency [RFC6327], DRB election or Appointed 578 Forwarder logic [RFC6439] on a link, regardless of whether some or 579 all the ports on the link are for FGL TRILL switches, with one 580 exception: implementations SHOULD provide that their default priority 581 for a VL RBridge port to be DRB (Designated RBridge) is less than 582 their default priority for an FGL RBridge to be DRB. This will assure 583 that, in the unconfigured case, an FGL RBridge will be elected DRB 584 when using that implementation. 586 4.5 Distribution Tree Construction 588 All distribution trees are calculated as provided for in the TRILL 589 base protocol standard [RFC6325] as updated by [ClearCorrect] with 590 the exception that the default tree root priority for a nickname held 591 by an FGL TRILL switch or an FGL link pseudonode is 0x9000. As a 592 result they will be chosen in preference to VL nicknames in the 593 absence of configuration. If distribution tree roots are configured, 594 there MUST be at least one tree rooted at a nickname held by an FGL 595 TRILL switch or by an FGL link pseudonode. If distribution tree roots 596 are misconfigured so there would not be such a tree, then the highest 597 priority FGL nickname to be a tree root is used to construct an 598 additional tree regardless of configuration. (VL TRILL switches will 599 not know about this additional distribution tree but, through the use 600 of Step (A) or (B) in Section 5.1, no VL TRILL switch should ever 601 receive a multi-destination TRILL Data packet using this additional 602 tree.) 604 4.6 Address Learning 606 An FGL TRILL switch learns addresses from the data plane on ports 607 configured for FGL based on the fine-grained label rather than the 608 native frame's VLAN. Addresses learned from ingressed native frames 609 on FGL ports are logically represented by { MAC address, FGL, port, 610 confidence, timer } while remote addresses learned from egressing FGL 611 packets are logically represented by { MAC address, FGL, remote TRILL 612 switch nickname, confidence, timer }. 614 4.7 ESADI Extension 616 The TRILL ESADI (End Station Address Distribution Information) 617 protocol is specified in [RFC6325] as optionally transmitting MAC 618 address connection information through TRILL Data packets between 619 participating TRILL switches over the virtual link provided by the 620 TRILL multi-destination packet distribution mechanism. In [RFC6325], 621 the VL to which an ESADI packet applies is indicated only by the 622 Inner.VLAN label and no indication of that VL is allowed within the 623 ESADI payload. 625 ESADI is extended to support FGL by providing for the indication of 626 the FGL to which an ESADI packet applies only in the Inner.Label of 627 that packet and no indication of that FGL is allowed within the ESADI 628 payload. 630 5. FGL TRILL Interaction with VL TRILL 632 This section discusses mixing FGL-safe and VL TRILL switches in a 633 campus. It does not apply if the campus is entirely FGL-safe or if 634 there are no FGL-edges. Section 5.1 specifies what behaviors are 635 needed to render such mixed campuses safe. See also Appendix B for a 636 discussion of campus characteristics when these behaviors are in use. 637 Section 5.2 gives details of link local mixed behavior. 639 It is best, if possible, for VL TRILL switches to be upgraded to FGL- 640 safe before introducing FGL-edges (and therefore FGL data packets). 642 5.1 FGL and VL Mixed Campus 644 By definition, it is not possible for VL TRILL switches to safely 645 handle FGL traffic even if the VL TRILL switch is only acting in the 646 transit capacity. If a TRILL switch can safely transit FGL TRILL Data 647 packets, then it qualifies as FGL-safe but will still be assumed to 648 be VL until it advertises in its LSP that it is FGL-safe. 650 VL frames are required to have 0x8100 at the beginning of the data 651 label where FGL frames have 0x893B. VL TRILL switches conformant to 652 [RFC6325] should discard frames with this new value after the inner 653 MAC addresses. However, if they do not discard such frames, they 654 could be confused and egress them into the wrong VLAN (see Section 9 655 below) or persistently re-order them due to miscomputing flows for 656 ECMP or they could improperly prune their distribution if they are 657 multi-destination so that they would fail to reach some intended 658 destinations. Such difficulties are avoided by taking all practical 659 steps to minimize the chance of a VL TRILL switch handling an FGL 660 TRILL Data packet. These steps are specified below. 662 FGL-safe switches will report their FGL capability in LSPs. Thus FGL- 663 safe TRILL switches (and any management system with access to the 664 link state database) will be able to detect the existence of TRILL 665 switches in the campus that do not support FGL. 667 Once a TRILL switch advertises an FGL-edge, any FGL-safe TRILL switch 668 RB1 that observes, on one of its ports, a VL RBridge on the link out 669 that port, MUST take Step (A) or (B) below for that port and also 670 take Step (C) further below. ("Observes" means that it has an 671 adjacency to the VL TRILL switch that is in any state other than Down 672 [RFC6327] and holds an LSP fragment zero for it showing it is not 673 FGL-safe.) Finally, for there to be full FGL connectivity, the 674 campus topology must be such that all FGL TRILL switches are 675 reachable from all other FGL TRILL switches without going through a 676 VL TRILL switch. 678 (A) If RB1 can discard any FGL TRILL Data packet that would be 679 output through a port where is observes a VL RBridge, while 680 allowing output of VL TRILL Data packets through that port, 681 then 683 A1. RB1 MUST so discard all FGL TRILL Data output packets that 684 would otherwise be output through the port and 686 A2. For all adjacencies out that port (even adjacencies to 687 other FGL RBridges or a pseudonode) in the Report state 688 [RFC6327], RB1 MUST report that adjacency cost as 2**23 689 greater than it would have otherwise reported, but not 690 more than 2**24 - 2 (the highest link cost still usable in 691 least cost path calculations and distribution tree 692 construction). This assures that if any path through FGL- 693 safe TRILL switches exists, such a path will be computed. 695 (B) If RB1 cannot discard any FGL TRILL Data packet that would be 696 output through a port where it observes a VL RBridge while 697 allowing VL TRILL data packets, then RB1 MUST, for all 698 adjacencies out that port (even adjacencies to other FGL-safe 699 RBridges or a pseudonode) in the Report state [RFC6327], 700 report the adjacency cost as 2**24 - 1. As specified in IS-IS 701 [RFC5305], that cost will stop the adjacency from being used 702 in least cost path calculations, including distribution tree 703 construction (see Section 2.1 of [ClearCorrect]), but will 704 still leave it visible in the topology and usable, for 705 example, by any traffic engineered path mechanism. 707 (C) The roots for all distribution trees used for FGL TRILL Data 708 packets must be nicknames held by an FGL-safe TRILL switch or 709 by a pseudonode representing an FGL link. As provided in 710 Section 4.5, there will always be such a distribution tree. 712 Using the increased adjacency cost specified in part A2 of Step (A) 713 above, VL links will be avoided unless no other path is available for 714 typical data center link speeds using the default link cost 715 determination method specified in Item 1 of Section 4.2.4.4 of 716 [RFC6325]. However, if links have low speed (such as about 100 717 megabits/second or less) or some non-default method is used for 718 determining link costs, then link costs MUST be adjusted such that no 719 adjacency between FGL-safe TRILL switches has a cost greater than 720 200,000. 722 To summarize, for a mixed TRILL campus to be safe once FGL-edges are 723 introduced, it is essential that the steps above be followed by FGL- 724 safe RBridges, to ensure that paths between such RBridges do not 725 include VL RBridges, and to ensure that FGL packets are never 726 forwarded to VL RBridges. That is, all FGL-safe switches MUST do Step 727 (A) or (B) for any port out which they observe a VL RBridge neighbor. 729 And for full FGL connectivity, all FGL-safe TRILL switches MUST do 730 Step (C) and be connected in a single FGL contiguous area. 732 5.2 FGL and VL Mixed Links 734 The usual DRB election operates on a link with mixed FGL and VL 735 ports. If an FGL TRILL switch port is DRB, it can handle all native 736 traffic. It MUST appoint only other FGL TRILL switch ports as 737 Appointed Forwarder for any VLANs that are to be mapped to FGL. 739 For VLANs that are not being mapped to FGL, if Step (A) is being 740 followed (see Section 5.1), it can appoint either a VL or FGL TRILL 741 switch for a VLAN on the link to be handled by VL. If Step (B) is 742 being followed, an FGL DRB MUST only appoint FGL Appointed 743 Forwarders, so that all end stations will get service to the FGL 744 campus. If a VL RBridge is DRB, it will not understand that FGL TRILL 745 switch ports are different. To the extent that Step (B) is in effect 746 and a VL DRB handles native frames or appoints other VL TRILL switch 747 ports on a link to handle native frames for one or more VLANs, the 748 end stations sending and receiving those native frames may be 749 isolated from the FGL campus. When a VL DRB happens to appoint an FGL 750 port as Appointed Forwarder for one or more VLANs, the end stations 751 sending and receiving native frames in those VLANs will get service 752 to the FGL campus. 754 5.3 Summary of FGL-safe Requirements 756 The list below summarizes the requirements for a TRILL switch to be 757 FGL-safe. 759 (a) For both unicast and multi-destination data, RB1 MUST NOT forward 760 an FGL packet to a VL neighbor RB2. This is accomplished as 761 specified in Section 5.1. 763 (b) For both unicast and multi-destination data, RB1 MUST NOT egress 764 a packet onto a link that does not belong in that FGL. 766 (c) For unicast, RB1 must forward the FGL packet properly to the 767 egress nickname in the TRILL header. This means that it MUST NOT 768 delete the packet because of not having the expected VLAN tag, it 769 MUST NOT insert a VLAN tag, and it MUST NOT misclassify a flow so 770 as to persistently misorder packets, because the TRILL fields are 771 now 4 bytes longer than in VL TRILL packets. 773 (d) For multi-destination, RB1 must forward the packet properly along 774 the specified tree. This means that RB1 MUST NOT falsely prune 775 the packet. RB1 is allowed not to prune at all, but it MUST NOT 776 prevent an FGL packet from reaching all the links with that FGL 777 by incorrectly refusing to forward the FGL packet along a branch 778 in the tree. 780 (e) RB1 must advertise, in its LSP, that it is FGL-safe. 782 Point (c) above, for a TRILL switch to correctly support ECMP, and 783 point (d), for a TRILL switch to correctly prune distribution trees, 784 require that the TRILL switch properly recognize and distinguish 785 between the two Ethertypes that can occur immediately after the 786 Inner.MacSA in a TRILL Data packet. 788 6. IS-IS Extensions 790 Extensions to the TRILL use of IS-IS are required to support FGL 791 include the following: 793 1. A method for a TRILL switch to announce itself in its LSP as 794 FGL-safe (see Section 8.2). 796 2. A sub-TLV analogous to Interested VLANs and Spanning Tree Roots 797 sub-TLV of the Router Capabilities TLV but indicating FGLs 798 rather than VLs. This is called the Interested Labels and 799 Spanning Tree Roots sub-TLV in [rfc6326bis]. 801 3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group 802 Address TLV that specifies an FGL rather than a VL. These are 803 called the GLMAC-ADDR, GLIP-ADDR, and GLIP6 ADDR sub-TLVs in 804 [rfc6326bis]. 806 7. Comparison to Goals 808 Comparing TRILL FGL, as specified in this document, with the goals 809 given in Section 2.1, we find as follows: 811 1. Fine-Grained: FGL provides 2**24 labels, vastly more than the 4K 812 VL labels provided in [RFC6325]. 814 2. Silicon: Existing TRILL fast path silicon chips can perform base 815 TRILL Header insertion and removal to support ingress and egress. 816 In addition, it is believed that most such silicon can also 817 perform the native frame to FGL mapping and the encoding of the 818 FGL as specified herein, as well as the inverse decoding and 819 mapping. Some existing silicon can perform only one of these 820 operations on a frame in one pass through the fast path; however, 821 other existing chips are believed to be able to perform both 822 operations on the same frame in one pass through their fast path. 823 It is also believed that most FGL TRILL switches will be capable 824 of having their ports configured to discard FGL packets making 825 interoperation with VL TRILL switches using of Step (A) (see 826 Section 5.1) practical. 828 3. Base RBridge Interoperation: As described in Section 3, FGL is not 829 generally compatible with TRILL switches conformant to the base 830 specification [RFC6325]. In particular, a VL TRILL switch cannot 831 be an FGL TRILL switch because there is a risk that it would 832 mishandle FGL packets. However, a contiguous set of VL TRILL 833 switches can exchange VL frames regardless of the presence of FGL 834 TRILL switches in the campus and the provisions of Section 5 835 support reasonable interoperation and migration scenarios. 837 4. Alternate Priority: The encoding specified in Section 2.3 and the 838 ingress/egress processing specified in Section 4 provide for a new 839 priority and DEI in the Inner.Label High Part and a place to 840 preserve the original user priority and DEI in the Low Part, so it 841 can be restored on egress. 843 8. Allocation Considerations 845 Allocations by the IEEE Registration Authority and IANA are listed 846 below. 848 8.1 IEEE Allocation Considerations 850 The IEEE Registration Authority has assigned Ethertype 0x893B for use 851 as the TRILL FGL Ethertype. 853 8.2 IANA Considerations 855 IANA is requested to allocate capability bit TBD in the TRILL-VER 856 sub-TLV capability bits [RFC6326bis] to indicate a TRILL switch is 857 FGL-safe. 859 9. Security Considerations 861 See [RFC6325] for general TRILL Security Considerations. 863 As with any communications system, end-to-end encryption and 864 authentication should be considered for sensitive data. In this case 865 that would be encryption and authentication extending from a source 866 end station and carried through the TRILL campus to a destination end 867 station. 869 Confusion between a packet with VL X and FGL (X.Y) or confusion due 870 to a malformed frame is a potential problem if an FGL TRILL switch 871 did not properly check for the occurrence of 0x8100 or 0x893B 872 immediately after the Inner.MacSA (see Sections 2.2 and 2.3) and 873 handled the frame appropriately. 875 [RFC6325] requires that the Ethertype immediately after the 876 Inner.MacSA be 0x8100. A VL TRILL switch that did not discard a 877 packet with some other value there could cause problems. If it 878 received a TRILL Data frame with FGL (X.Y) or with junk after the 879 Inner.MacSA that included X where a VLAN ID would appear, then: 881 1. It could egress the packet to an end station in VLAN-X. If the 882 packet was a well formed FGL frame, the payload of such an 883 egressed native frame would appear to begin with Ethertype 884 0x893B that would likely be discarded by an end station. In any 885 case, such an egress would almost certainly be a violation of 886 security policy requiring the configurable separation of 887 differently labeled data. 889 2. If the packet was multi-destination and the TRILL switch pruned 890 the distribution tree, it would incorrectly prune it on the 891 basis of VLAN-X. For an FGL packet, this would probably lead to 892 the multi-destination data packet not being delivered to all of 893 its intended recipients. 895 Possible problems with an FGL TRILL switch that received a TRILL Data 896 packet with junk after the Inner.MacSA that included X where a VLAN 897 ID would appear and did not check the Ethertype immediately after the 898 Inner.MacSA would be that it could improperly egress the packet in 899 VLAN-X, violating security policy. If the packet was multi- 900 destination and was improperly forwarded, it should be discarded by 901 properly implemented TRILL switches downstream in the distribution 902 tree and never egressed but the propagation of the packet would still 903 waste bandwidth. 905 To avoid these problems all TRILL switches MUST check the Ethertype 906 immediately after the Inner.MacSA and, if it is a value they do not 907 know how to handle, either discard the frame or make no decisions 908 based on any data after that Ethertype. In addition, care must be 909 taken to avoid FGL packets being sent to or through VL TRILL switches 910 that will discard them if the VL TRILL switch is properly implemented 911 or mishandle them if it is not properly implemented. This is 912 accomplished as specified in Section 5.1. 914 Acknowledgements 916 The comments and suggestions of the following, listed in alphabetic 917 order, are gratefully acknowledged: 919 Stewart Bryant, Spencer Dawkins, Adrian Farrel, Anoop Ghanwani, 920 Sujay Gupta, Weiguo Hao, Phanidhar Koganti, Yizhou Li, Vishwas 921 Manral, Rajeev Manur, Thomas Narten, Gayle Nobel, Erik Nordmark, 922 Pete Resnick, Olen Stokes, Sean Turner, Ilya Varlashkin, and 923 Xuxiaohu. 925 The document was prepared in raw nroff. All macros used were defined 926 within the source file. 928 Normative References 930 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 931 Intermediate System Intra-Domain Routeing Exchange Protocol for 932 use in Conjunction with the Protocol for Providing the 933 Connectionless-mode Network Service (ISO 8473)", 2002. 935 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 936 networks - Virtual Bridged Local Area Networks", IEEE Std 937 802.1Q-2011, May 2011. 939 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, March 1997. 942 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 943 Engineering", RFC 5305, October 2008. 945 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 946 Ghanwani, "Routing Bridges (RBridges): Base Protocol 947 Specification", RFC 6325, July 2011. 949 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 950 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 951 6327, July 2011 953 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 954 A. Ghanwani, "Transparent Interconnection of Lots of Links 955 (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, Work in 956 Progress. 958 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 959 Manral, draft-ietf-trill-clear-correct-06.txt, in RFC Editor's 960 queue. 962 Informative References 964 [OAMframework] - draft-ietf-trill-oam-framework, Work in Progress. 966 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 967 Layer-2 Systems", RFC 6165, April 2011. 969 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 970 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 971 6439, November 2011. 973 [RFCchannel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, 974 "TRILL: RBridge Channel Support", 13 July 2012, in RFC Editor's 975 queue. 977 Appendix A: Serial Unicast 979 This informational appendix discusses advantages and disadvantages of 980 using serial unicast instead of a distribution tree for multi- 981 destination TRILL Data packets. See Sections 4.1 and 4.3. FGL TRILL 982 switches are required by this document to accept serial unicast but 983 there is no requirement that they be able to send serial unicast. 985 Consider a large TRILL campus with hundreds of TRILL switches in 986 which, say, 300 end stations are in some particular FGL data label. 988 At one extreme, if all 300 end stations were on links attached to a 989 single TRILL switch, then no other TRILL switch would be advertising 990 interest in that FGL and likely a multi-destination (say broadcast) 991 frame from one such end station would, even if put on a distribution 992 tree, because of pruning, not be sent to any another TRILL switch. 994 At the other extreme, assume the 300 end stations are attached, one 995 each, to 300 different TRILL switches; in that case you are almost 996 certainly better off using a distribution tree because if you tried 997 to serially unicast you would have to output 300 copies, probably 998 including multiple copies through the same port, and would cause much 999 higher link utilization. 1001 Now assume these 300 end stations are connected to exactly two TRILL 1002 switches, say 200 to one and 100 to the other. Using unicast TRILL 1003 Data frames between these two TRILL switches is best because the 1004 frames will follow least cost paths, possibly with such traffic 1005 spread over a number of equal cost least cost paths. On the other 1006 hand, if a distribution trees were used, each frame would be 1007 constrained to the tree used for that frame and would likely follow a 1008 higher cost route and only a single path would be available per tree. 1009 Thus this document says that unicast "SHOULD" be used if there are 1010 exactly two TRILL switches involved. 1012 It is a more complex decision whether to use a distribution tree or 1013 serial unicast if the end stations are connected to a number of TRILL 1014 switches greater than two. Which would be better would depend on many 1015 factors including network topology and application data patterns. How 1016 to make this decision in such more complex cases is beyond the scope 1017 of this document. 1019 Appendix B: Mixed Campus Characteristics 1021 This informational appendix describes the characteristics of a TRILL 1022 campus with mixed FGL-safe and VL TRILL switches for two cases: 1023 Section B.1 discusses the case where all FGL adjacencies with VL are 1024 handled by Step (A) and Section B.2 discusses the case where all FGL 1025 adjacencies with VL are handled by Step (B) (see Seciton 5.1). 1027 B.1 Mixed Campus with High Cost Adjacencies 1029 If the FGL TRILL switches use Step (A) in Section 5.1, then VL and 1030 FGL TRILL switches will be able to interoperate for VL traffic. 1031 Least cost paths will avoid any FGL -> VL TRILL switch hops unless no 1032 other reasonable path is available. In conjunction with Section 4.5, 1033 there will be at least one distribution tree rooted at a nickname 1034 held by an FGL TRILL switch or the pseudonode for an FGL link. 1035 Furthermore, if the FGL TRILL switches in the campus form a single 1036 contiguous island, this distribution tree will have a fully connected 1037 sub-tree covering that island. Thus any FGL TRILL Data packets sent 1038 on this tree will be able to reach any other FGL TRILL switch without 1039 attempting to go through any VL TRILL switches. (Such an attempt 1040 would cause the FGL packet to be discarded as specified in part A1 of 1041 Step (A).) 1043 If supported, Step (A) is particularly effective in a campus with an 1044 FGL TRILL switch core and VL TRILL switches in on one or more islands 1045 around that core. For example, consider the campus below. This campus 1046 has an FGL core consisting of FGL01 to FGL14 and three VL islands 1047 consisting of VL01 to VL04, VL05, and VL06 to VL14. 1049 *VL01--*VL02 1050 | | 1051 *VL03--*VL04 *VL05 1052 | | | 1053 FGL01--FGL02--FGL03--FGL04--FGL05 1054 | | | | | 1055 FGL06--FGL07--FGL08--FGL09--FGL10 1056 | | | | | 1057 FGL11--FGL12--*VL06--*VL07---FGL13 1058 | | | | 1059 *VL08--*VL09--*VL10---FGL14 1060 | | | | 1061 *VL11--*VL12--*VL13--*VL14 1063 Assuming that the FGL TRILL switches in this campus all implement 1064 Step (A), then end stations connected through a VL port can be 1065 connected anywhere in the campus to VL or FGL TRILL switches and, if 1066 in the same VLAN, will communicate. End stations connected through an 1067 FGL port on FGL TRILL switches will communicate if their local VLANs 1068 are mapped to the same FGL. 1070 Due to the high cost of FGL to VL adjacencies used in path 1071 computations, VL TRILL switches are avoided on paths between FGL 1072 TRILL switches. For example, even if the speed and default adjacency 1073 cost of all the connections show above were the same, traffic from 1074 FGL12 to FGL13 would follow the 5 hop path FGL12 - FGL07 - FGL08 - 1075 FGL09 - FGL10 - FGL13 rather than the 3 hop path FGL12 - VL09 - VL10 1076 - FGL14. 1078 B.2 Mixed Campus with Data Blocked Adjacencies 1080 If the FGL TRILL switches use Step (B) in Section 5.1, then least 1081 cost and distribution tree TRILL Data communication between VL and 1082 FGL TRILL switches is blocked, although TRILL IS-IS communication is 1083 normal. This data blocking, although implemented only by FGL TRILL 1084 switches, has relatively symmetric effects. The following paragraphs 1085 assume such data blocking between VL and FGL is in effect throughout 1086 the campus. 1088 A campus of mostly FGL TRILL switches implementing Step (B) with a 1089 few isolated VL TRILL switches scattered throughout will work well in 1090 terms of connectivity for end stations attached to those FGL switches 1091 except that they will be unable to communicate with any end stations 1092 for which a VL switch is appointed forwarder. The VL TRILL switches 1093 will be isolated and will only be able to route TRILL Data to the 1094 extent they happen to be contiguously connected to other VL TRILL 1095 switches. Distribution trees computed by the FGL switches will not 1096 include any VL switches (see Section 2.1 of [ClearCorrect]). 1098 A campus of mostly VL TRILL switches with a few isolated FGL TRILL 1099 switches scattered throughout will also work reasonably well as 1100 described immediately above with all occurrences of "FGL" and "VL" 1101 swapped. 1103 However, a campus so badly misconfigured that it consists of a 1104 randomly intermingled mixture of VL and FGL TRILL switches using Step 1105 (B) is likely to offer very poor data service due to many links being 1106 blocked for data. 1108 Appendix Z: Change History 1110 RFC Editor Note: Please delete this appendix before publication. 1112 From -00 to -01: 1114 Update author info and make editorial changes. 1116 From -01 to -02 1118 1. Change the value after the inner MAC addresses for FGL frames 1119 from 0x8100 to 0x893B 1121 2. As a consequence of item 1 above, for safety prohibit use for 1122 TRILL Data of links between FGL and VL RBridges, isolating any 1123 VL RBridges. Make appropriate changes throughout document, 1124 including Security Considerations section, based on this 1125 change. 1127 3. Reference and contributor updates. 1129 4. Minor editorial changes. 1131 From -02 to -03 1133 1. Addition of the terms "Limited FGL" and "Full FGL". 1135 2. Addition of Appendix A. 1137 3. Clarifications: 1138 3.a That FGL TRILL switches also support VL ports and frames 1139 (Add Section 2.4, etc.). 1140 3.b That the FGL extensions to TRILL are optional. A VL TRILL 1141 switch is still a conformant implementation. 1142 3.c The utility of the alternate priority goal. 1144 4. Expand Security Considerations discussion of misparsed frames. 1146 5. Substantial editorial changes. 1148 From -03 to -04 1150 1. Typo and grammar fixes. 1152 2. Update acknowledgements, date, and version as usual. 1154 From -04 to -05 1156 1. Tweak VL/FGL interoperation and migration strategy to provide 1157 for Steps (A) and (B) in Section 5.1 and adjust other parts of 1158 document correspondingly. 1160 2. Drop terms "Limited FGL" and "Full FGL". Add terms "FGL-safe" 1161 and "FGL-edge". 1163 3. Provide that the default configuration of an FGL TRILL switch 1164 to be a tree root and to be the DRB is higher than for a VL 1165 RBridge. 1167 4. Assorted Editorial changes. 1169 From -05 to -06 1171 1. Move summary list of FGL-safe requirements from Introduction to 1172 new Section 5.3. 1174 2. Editorial improvements. 1176 From -06 to -07 1178 Editorial changes resulting from IESG review. 1180 Authors' Addresses 1182 Donald Eastlake 3rd 1183 Huawei Technologies 1184 155 Beaver Street 1185 Milford, MA 01757 USA 1187 Phone: +1-508-333-2270 1188 Email: d3e3e3@gmail.com 1190 Mingui Zhang 1191 Huawei Technologies Co., Ltd 1192 Huawei Building, No.156 Beiqing Rd. 1193 Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, 1194 Beijing 100095 P.R. China 1196 Email: zhangmingui@huawei.com 1198 Puneet Agarwal 1199 Broadcom Corporation 1200 3151 Zanker Road 1201 San Jose, CA 95134 USA 1203 Phone: +1-949-926-5000 1204 Email: pagarwal@broadcom.com 1206 Radia Perlman 1207 Intel Labs 1208 2200 Mission College Blvd. 1209 Santa Clara, CA 95054 USA 1211 Phone: +1-408-765-8080 1212 Email: Radia@alum.mit.edu 1214 Dinesh G. Dutt 1215 Cumulus Networks 1216 1089 West Evelyn Avenue 1217 Sunnyvale, CA 94086 USA 1219 Email: ddutt.ietf@hobbesdutt.com 1221 Copyright, Disclaimer, and Additional IPR Provisions 1223 Copyright (c) 2013 IETF Trust and the persons identified as the 1224 document authors. All rights reserved. 1226 This document is subject to BCP 78 and the IETF Trust's Legal 1227 Provisions Relating to IETF Documents 1228 (http://trustee.ietf.org/license-info) in effect on the date of 1229 publication of this document. Please review these documents 1230 carefully, as they describe your rights and restrictions with respect 1231 to this document. Code Components extracted from this document must 1232 include Simplified BSD License text as described in Section 4.e of 1233 the Trust Legal Provisions and are provided without warranty as 1234 described in the Simplified BSD License. The definitive version of 1235 an IETF Document is that published by, or under the auspices of, the 1236 IETF. Versions of IETF Documents that are published by third parties, 1237 including those that are translated into other languages, should not 1238 be considered to be definitive versions of IETF Documents. The 1239 definitive version of these Legal Provisions is that published by, or 1240 under the auspices of, the IETF. Versions of these Legal Provisions 1241 that are published by third parties, including those that are 1242 translated into other languages, should not be considered to be 1243 definitive versions of these Legal Provisions. For the avoidance of 1244 doubt, each Contributor to the IETF Standards Process licenses each 1245 Contribution that he or she makes as part of the IETF Standards 1246 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1247 language to the contrary, or terms, conditions or rights that differ 1248 from or are inconsistent with the rights and licenses granted under 1249 RFC 5378, shall have any effect and shall be null and void, whether 1250 published or posted by such Contributor, or included with or in such 1251 Contribution.