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