idnits 2.17.1 draft-ietf-trill-fine-labeling-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (December 12, 2012) is 4153 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: 2 errors (**), 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, 6327 Puneet Agarwal 5 Broadcom 6 Radia Perlman 7 Intel Labs 8 Dinesh Dutt 9 Cumulus Networks 10 Expires: June 11, 2013 December 12, 2012 12 TRILL: Fine-Grained Labeling 13 15 Abstract 17 The IETF has standardized TRILL (TRansparent Interconnection of Lots 18 of Links), a protocol for least cost transparent frame routing in 19 multi-hop networks with arbitrary topologies and link technologies, 20 using link-state routing with a hop count. The TRILL base protocol 21 standard supports labeling of TRILL data with up to 4K IDs. However, 22 there are applications that require more fine-grained labeling of 23 data. This document updates RFC 6325 and RFC 6327 by specifying 24 optional extensions to the TRILL base protocol to safely accomplish 25 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............................................3 54 1.2 Contributors...........................................4 56 2. Fine-Grained Labeling...................................5 57 2.1 Goals..................................................5 58 2.2 Base Protocol TRILL Data Labeling......................6 59 2.3 Fine-Grained Labeling (FGL)............................7 60 2.4 VL, Limited FGL, and Full FGL TRILL Switches...........8 62 3. VL versus FGL Label Differences........................10 64 4. FGL TRILL Interaction with VL TRILL....................11 65 4.1 FGL and VL Mixed Campus Topology......................11 66 4.2 FGL and VL Mixed Campus Characteristics...............12 67 4.3 FGL and VL Mixed Links................................12 69 5. FGL Details............................................14 70 5.1 Ingress Processing....................................14 71 5.2 Transit Processing....................................15 72 5.2.1 Unicast Transit Processing..........................15 73 5.2.2 Multi-Destination Transit Processing................15 74 5.3 Egress Processing.....................................16 75 5.4 Appointed Forwarders and the DRB......................16 76 5.5 Address Learning......................................17 77 5.6 ESADI Extensions......................................17 79 6. IS-IS Extensions.......................................18 80 7. Comparison to Goals....................................19 82 8. Allocation Considerations..............................20 83 8.1 IEEE Allocation Considerations........................20 84 8.2 IANA Considerations...................................20 86 9. Security Considerations................................21 87 Acknowledgements..........................................22 88 Normative References......................................23 89 Informative References....................................23 90 Appendix A: Serial Unicast................................24 91 Appendix Z: Change History................................25 93 1. Introduction 95 The IETF has standardized the TRILL (TRansparent Interconnection of 96 Lots of Links) protocol [RFC6325] that provides a solution for least 97 cost transparent routing in multi-hop networks with arbitrary 98 topologies and link technologies, using [IS-IS] [RFC6165] 99 [RFC6326bis] link-state routing with a hop count. TRILL switches are 100 sometimes called RBridges (Routing Bridges). 102 The TRILL base protocol standard supports labeling of TRILL data with 103 up to 4K IDs. However, there are applications that require more fine- 104 grained labeling of data for configurable isolation based on 105 different tenants, service instances, or the like. This document 106 updates [RFC6325] and [RFC6327] by specifying optional extensions to 107 the TRILL base protocol to safely accomplish this. TRILL switches 108 that support fine-grained labeling as specified herein have 109 capabilities that are supersets of those specified in [RFC6325]. 111 Familiarity with [RFC6325] and [RFC6326bis] is assumed in this 112 document. 114 1.1 Terminology 116 The terminology and acronyms of [RFC6325] are used in this document 117 with the additions listed below. 119 DEI - Drop Eligibility Indicator [802.1Q]. 121 Edge TRILL switch - A TRILL switch announcing VLAN or Fien Grained 122 Lab el interest in its LSP. 124 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine- 125 Grained Label. 127 FGL TRILL switch - A TRILL switch that support both FGL and VL. 128 See also "Limited FGL TRILL" and "Full FGL TRILL". 130 Full FGL TRILL - Capabilities that support FGL and VL ingress, 131 transit, and egress. 133 Limited FGL TRILL - Capabilities that support VL ingress, transit, 134 and egress but only FGL transit, not FGL ingress and egress. 136 TRILL Switch - Alternative name for an RBridge. 138 VL - VLAN Labeling or VLAN Labeled or VLAN Label. 140 VL TRILL switch - A TRILL switch that supports VL but does not 141 support any FGL capabilities. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 1.2 Contributors 149 Thanks for the contributions of the following: 151 Tissa Senevirathne 153 2. Fine-Grained Labeling 155 The essence of Fine-Grained Labeling (FGL) is that (a) when TRILL 156 Data frames are ingressed or created they may incorporate a data 157 label from a set consisting of significantly more than 4K labels, (b) 158 TRILL switch (RBridge) ports can be labeled with a set of such data 159 labels, and (c) an FGL TRILL Data frame cannot be egressed through a 160 TRILL switch port unless its fine-grained label (FGL) matches one of 161 the data labels of the port. 163 Section 2.1 lists FGL goals. Section 2.2 briefly outlines the more 164 coarse TRILL base protocol standard [RFC6325] data labeling. Section 165 2.3 outlines FGL for TRILL Data frames. And Section 2.4 compares VL, 166 Limited FGL, and Full FGL TRILL switches. 168 2.1 Goals 170 There are several goals that would be desirable for FGL TRILL. They 171 are briefly described in the list below in approximate order by 172 priority with the most important first. 174 1. Fine-Grained 176 Some networks have a large number of entities that need 177 configurable isolation, whether those entities are independent 178 customers, applications, or branches of a single endeavor or some 179 combination of these or other entities. The labeling supported by 180 [RFC6325] provides for only ( 2**12 - 2 ) valid identifiers or 181 labels. A substantially larger number is required. 183 2. Silicon 185 Fine-grained labeling (FGL) should, to the extent practical, use 186 existing features, processing, and fields that are already 187 supported in many fast path silicon implementations that support 188 the TRILL base protocol. To the extent that such silicon does not 189 support Full FGL TRILL, it would be desirable to support Limited 190 FGL TRILL (see Section 2.4). 192 3. Base RBridge Compatibility 194 To support some incremental conversion scenarios, it is desirable 195 that not all RBridges in a campus using FGL be required to be FGL 196 aware. That is, it is desirable if RBridges not implementing the 197 FGL features and performing at least the transit forwarding 198 function can usefully process TRILL Data frames that incorporate 199 FGL. 201 4. Alternate Priority 203 It would be desirable for an ingress TRILL Switch to be able to 204 assign a different priority to an FGL TRILL Data frame for its 205 ingress-to-egress propagation from the priority of the original 206 native frame. The original priority should be restored on egress. 207 This enables traffic from attached non-TRILL networks to be 208 handled with different priority while transiting a TRILL network 209 if desired. 211 2.2 Base Protocol TRILL Data Labeling 213 This section provides a brief review of the [RFC6325] TRILL Data 214 frame internal VL Labeling and changes the description of the TRILL 215 Header by moving its end point. This descriptive change does not 216 involve any change in the bits on the wire or in the behavior of 217 existing [RFC6325] VL RBridges. 219 VL TRILL Data frames have the structure shown below: 221 +-------------------------------------------+ 222 | Link Header (depends on link technology) | 223 | (if link is an Ethernet link the link | 224 | header may include an Outer.VLAN tag) | 225 +-------------------------------------------+ 226 | TRILL Header | 227 | +---------------------------------------+ | 228 | | Initial Fields and Options | | 229 | +---------------------------------------+ | 230 | | Inner.MacDA | (6 bytes) | 231 | +-----------------------------+ | 232 | | Inner.MacSA | (6 bytes) | 233 | +-----------------------+-----+ | 234 | | Ethertype 0x8100 | (2 bytes) | 235 | +-----------------------+ | 236 | | Inner.VLAN Label | (2 bytes) | 237 | +-----------------------+ | 238 +-------------------------------------------+ 239 | Native Payload | 240 +-------------------------------------------+ 241 | Link Trailer (depends on link technology) | 242 +-------------------------------------------+ 244 Figure 1. TRILL Data with VL 246 In the base protocol as specified in [RFC6325] the 0x8100 value is 247 always present and is followed by the Inner.VLAN field which includes 248 the 12-bit VL. 250 2.3 Fine-Grained Labeling (FGL) 252 FGL expands the variety of data labels available under the TRILL 253 protocol to include a fine-grained label (FGL) with a 12-bit high 254 order part and a 12-bit low order part. In this document, FGLs are 255 usually denoted as "(X.Y)" where X is the high order part and Y is 256 the low order part of the FGL. 258 FGL TRILL Data frames have the structure shown below. 260 +-------------------------------------------+ 261 | Link Header (depends on link technology) | 262 | (if link is an Ethernet link the link | 263 | header may include an Outer.VLAN tag) | 264 +-------------------------------------------+ 265 | TRILL Header | 266 | +---------------------------------------+ | 267 | | Initial Fields and Options | | 268 | +---------------------------------------+ | 269 | | Inner.MacDA | (6 bytes) | 270 | +-----------------------------+ | 271 | | Inner.MacSA | (6 bytes) | 272 | +-----------------------+-----+ | 273 | | Ethertype 0x893B | (2 bytes) | 274 | +-----------------------+ | 275 | | Inner.Label High Part | (2 bytes) | 276 | +-----------------------+ | 277 | | Ethertype 0x893B | (2 bytes) | 278 | +-----------------------+ | 279 | | Inner.Label Low Part | (2 bytes) | 280 | +-----------------------+ | 281 +-------------------------------------------+ 282 | Native Payload | 283 +-------------------------------------------+ 284 | Link Trailer (depends on link technology) | 285 +-------------------------------------------+ 287 Figure 2. TRILL Data with FGL 289 For FGL frames, the inner MAC address fields are followed by the FGL 290 information using 0x893B. 292 The two bytes following each 0x893B have, in their low order 12 bits, 293 fine-grained label information. The upper 4 bits of those two bytes 294 are used for a 3-bit priority field and one drop eligibility 295 indicator (DEI) bit. 297 The priority field of the Inner.Label High Part is the priority used 298 for frame transport across the TRILL campus from ingress to egress. 299 The label bits in the Inner.Label High Part are the high order part 300 of the FGL and those bits in the Inner.Label Low Part are the low 301 order part of the FGL. 303 The appropriate FGL value for an ingressed or locally originated 304 native frame is determined by the ingress TRILL switch port as 305 specified in Section 5.1. 307 2.4 VL, Limited FGL, and Full FGL TRILL Switches 309 For a number of reasons, as listed below, it is desirable for FGL 310 TRILL switches to be able to handle both VL and FGL TRILL Data 311 frames. 313 o Continued support of VL frames makes interoperation between VL 314 and FGL RBridges easier as discussed in Sections 4.1 and 4.2. 316 o Due to the way TRILL works, it may be desirable to have a 317 maintenance VLAN or FGL [OAMframework] in which all TRILL 318 switches in the campus indicate interest. It will be simpler to 319 use the same type of label for all TRILL switche for this 320 purpose. That implies using VL if there might be any VL TRILL 321 switches in the campus. 323 o If a campus is being upgraded from VL FGL TRILL switches, it 324 avoids a requirement to immediately reconfigure all ports with 325 FGL configuration. 327 The table below summarizes the differences in the capabilities of VL 328 TRILL switches, Limited FGL TRILL switches, and Full FGL TRILL 329 switches. As discussed in Section 4, VL TRILL switches conformant to 330 [RFC6325] should discard an FGL TRILL Data frame as malformed. FGL 331 features are optional and VL TRILL switches are still a conformant 332 implementation of the TRILL protocol. 334 TRILL Data || VL TRILL Switch | FGL TRILL Switch | 335 Frame Type || | Limited | Full | 336 --------------++------------------+-----------+-----------+ 337 || ingress | ingress | ingress | 338 VL || transit | transit | transit | 339 || egress | egress | egress | 340 --------------++------------------+-----------+-----------+ 341 || | | ingress | 342 FGL || discard | transit | transit | 343 || | | egress | 344 --------------++------------------+-----------+-----------+ 346 Figure 3. TRILL Switch Capabilities Comparison 348 The primary reason to specify and permit Limited FGL TRILL switches 349 in a campus is that they might be upgraded VL TRILL switches not 350 capable of efficiently performing FGL ingress or egress but capable 351 of safely transiting FGL frames. 353 3. VL versus FGL Label Differences 355 There are differences between the semantics across a TRILL campus for 356 TRILL Data frames that are VL data labeled and those that are FGL 357 data labeled. 359 With VL, data label IDs have the same meaning throughout the campus 360 and are from the same label space as the C-VLAN IDs used on Ethernet 361 links to end stations. 363 With FGL TRILL switches, many things remain the same because an FGL 364 can appear only as the Inner.Label inside a TRILL Data frame. As 365 such, only a TRILL-aware device will see a fine-grained label. The 366 Outer.VLAN that may appear on native frames and that may appear on 367 TRILL Data frames if those TRILL Data frames are on an Ethernet link 368 can only be a C-VLAN tag. Thus ports of FGL TRILL switches, up 369 through the usual VLAN and priority processing, act as they do for VL 370 TRILL switches: TRILL switch ports provide a C-VLAN ID for an 371 incoming frame and accept a C-VLAN ID for a frame being queued for 372 output. Appointed Forwarders [RFC6439] on a link are still appointed 373 for a C-VLAN. The Designated VLAN for an Ethernet link is still a C- 374 VLAN. 376 The larger FGL data label space is a different space from the VL data 377 label space. For ports configured for FGL, the C-VLAN on an ingressed 378 native frame is mapped to the FGL data label space with a potentially 379 different mapping for each port. A similar FGL to C-VLAN mapping 380 occurs per port on egress. Thus, for ports configured for FGL, the 381 native frame C-VLAN on one link corresponding to an FGL can be 382 different from the native frame C-VLAN corresponding to that same FGL 383 on a different link elsewhere in the campus or even a different link 384 attached to the same TRILL switch. The FGL label space is flat and 385 does not hierarchically encode any particular number of native frame 386 C-VLAN bits or the like. FGLs appear only inside TRILL Data frames 387 after the inner MAC addresses. 389 As shown in Section 2.4, FGL TRILL switches have capabilities that 390 are a superset of those for VL TRILL switches. FGL TRILL switch ports 391 can be configured for FGL or VL with VL being the default. As with a 392 base protocol [RFC6325] TRILL switch, an unconfigured FGL TRILL 393 switch port reports an untagged frame it receives as being in VLAN 1. 395 4. FGL TRILL Interaction with VL TRILL 397 This section discusses various ramifications of attempting to mix FGL 398 and VL TRILL switches in a campus. Section 4.1 discusses what 399 behaviors are needed to render such mixed campuses safe while Section 400 4.2 discusses some resulting network characteristics. Section 4.3 401 gives further details of link local mixed campus behavior. 403 4.1 FGL and VL Mixed Campus Topology 405 It is not possible for VL TRILL switches to safely handle FGL frames 406 even if the VL TRILL switch is only acting in the transit capacity. 407 This is because VL frames are required to have 0x8100 at the 408 beginning of the data label where FGL frames have 0x893B. VL-only 409 TRILL switches conformant to [RFC6325] should discard frames with 410 this new value after the inner MAC addresses. If they do not discard 411 such frames, they will be confused and could egress them into the 412 wrong VLAN (see Section 9 below) or re-order them due to miscomputing 413 flows for ECMP. Such difficulties are avoided by stopping TRILL data 414 communication between VL and FGL TRILL switches as specified below. 416 FGL TRILL switches will report their FGL capability in LSPs. TRILL 417 IS-IS communication is not affected by the blocking of TRILL data 418 connectivity between VL and RFL Trill switches. So the link state 419 data base will include the entire TRILL campus regardless of the 420 presence of a mixture of VL and FGL TRILL switches. Thus FGL TRILL 421 switches (and any management system with access to the link state 422 database) will be able to detect the existence of TRILL switches in 423 the campus that do not support FGL. 425 If both VL and FGL TRILL switches are present on a link then, 426 although all other aspects of the adjacency machinery work as normal 427 [RFC6327], any FGL TRILL switches on the link will not create a 428 pseudo node for the link if they are DRB and will excommunicate the 429 link by not announcing any adjacencies on the link. As a result, 430 although adjacencies between two or more VL TRILL switch ports on 431 such a link could become part of the campus topology and pass VL 432 TRILL Data frames, no adjacency from an FGL TRILL switch port to a VL 433 TRILL switch port or to a pseudo node will be reported on such a 434 mixed FGL/VL link. Since an adjacency must be reported up by both 435 ends before it becomes part of the campus topology, even though a VL 436 TRILL switch might report an adjacency to an FGL TRILL switch, no 437 TRILL Data can flow between an FGL and a VL TRILL switch port. 439 4.2 FGL and VL Mixed Campus Characteristics 441 The provisions described in Section 4.1 to block TRILL data 442 communication between VL and FGL TRILL switches, although implemented 443 only by FGL TRILL switches, have relatively symmetric effects. 445 A campus of mostly FGL TRILL switches with a few isolated VL TRILL 446 switches scattered throughout will work well in terms of connectivity 447 for end stations attached to those FGL switches except that they will 448 be unable to communicate with any end stations for which a VL switch 449 is appointed forwarder. The VL TRILL switches will be isolated and 450 will only be able to route TRILL Data to the extent they happen to be 451 contiguously connected to other VL TRILL switches. Distribution trees 452 computed by the FGL switches will not include any VL switches (see 453 Section 2.1 of [ClearCorrect]). A campus of mostly VL TRILL switches 454 with a few isolated FGL TRILL switches scattered throughout will also 455 work reasonably well as described immediately above with all 456 occurrences of "FGL" and "VL" swapped. However, a campus so badly 457 misconfigured that it consists of an intermingled general mixture of 458 VL and FGL TRILL switches is likely to offer abysmal data service. 460 The are possible future extensions to TRILL that would eliminate the 461 requirement to block TRILL Data traffic between FGL and VL TRILL 462 switches improving backwards compatibility. For example, with 463 support for multiple topologies [MultiTopo], it would be possible to 464 put all TRILL switches into one topology on which VL frames were sent 465 and all FGL TRILL switches into a second topology on which FGL frames 466 were sent. Assuming that the FGL TRILL switches are fully connected, 467 everything would work fine including data traffic between VL ports in 468 the same VLAN regardless of whether those VL ports were on VL or FGL 469 TRILL switches 471 4.3 FGL and VL Mixed Links 473 The usual DRB election operates on a link with mixed FGL and VL 474 ports. If an FGL TRILL switch port is DRB, it MUST handle all native 475 traffic or appoint only other FGL TRILL switch ports as Appointed 476 Forwarder for one or more VLANs, so that all end stations will get 477 service to the FGL campus. If a VL TRILL switch port is DRB, it will 478 not understand that FGL TRILL switch ports are different. To the 479 extent that a VL DRB handles native frames or appoints other VL TRILL 480 switch ports on a link to handle native frames for one or more VLANs, 481 the end stations sending and receiving those native frames will be 482 isolated from the FGL campus and will receive only service from the 483 VL campus to the extent the VL campus has connectivity. When a VL DRB 484 happens to appoint an FGL port as Appointed Forwarder for one or more 485 VLANs, the end stations sending and receiving native frames in those 486 VLANs will get service to the FGL campus. This corner case behavior 487 is considered acceptable because it is assumed that the campus is 488 intended to be VL or FGL and TRILL switches of the other type are 489 infrequent misconfigurations. 491 For links configured as point-to-point, if the TRILL switches at each 492 end are both VL or both FGL, a bi-directional adjacency can be formed 493 and reported as usual. If one is VL and one is FGL but the point-to- 494 point link is otherwise correctly configured, the VL TRILL switch 495 will report an adjacency but the FGL one will not. As a result, the 496 link will not become part of the topology and TRILL Data cannot flow 497 over the link, excommunicating the switches from each other for data. 499 5. FGL Details 501 This section specifies ingress, transit, egress, and other processing 502 details with regard to FGL TRILL switches. A transit or egress FGL 503 TRILL switch determines that a TRILL Data frame is FGL by detecting 504 that the Inner.MacSA is followed by 0x893B. 506 5.1 Ingress Processing 508 It MUST be possible to configure the ports of a Full FGL TRILL switch 509 to ingress native frames as FGL. Any ports not so configured performs 510 the previously specified [RFC6325] VL ingress processing on native 511 frames resulting in a VL TRILL Data frame. (There is no change in 512 Appointed Forwarder logic (see Section 5.4).) 514 Thus Full FGL TRILL switches MUST support configurable per port 515 mapping from the C-VLAN of a native frame, as reported by the ingress 516 port, to an FGL. FGL TRILL switches MAY support other methods to 517 determine the FGL of an incoming native frame, such as based on the 518 protocol of the native frame or local knowledge. 520 The FGL ingress process MUST copy the priority and DEI associated 521 with an ingressed native frame to the upper 4 bits of the Inner.Label 522 Low Order part. It SHOULD also associate a possibly different mapped 523 priority and DEI with an ingressed frame but a TRILL switch might not 524 be able to do so because of implementation limitations. The mapped 525 priority is placed in the Inner.Label High Part. If such mapping is 526 not supported then the original priority and DEI MUST be placed in 527 the Inner.Label High Part. 529 An FGL ingress TRILL switch MAY serially TRILL unicast a multi- 530 destination TRILL Data frame to the relevant egress TRILL switches by 531 using a known unicast TRILL Header (M=0) and SHOULD unicast such a 532 multi-destination TRILL Data frame if there is only one relevant 533 egress FGL TRILL switch. For FGL TRILL switches, this permits serial 534 unicast of multi-destination frames by the ingress as an alternative 535 to the use of a distribution tree. The relevant egress TRILL switches 536 are determined by starting with those announcing interest in the 537 frame's (X.Y) label. That set SHOULD be further filtered based on 538 multicast listener and multicast router LSP announcements if the 539 native frame was a multicast frame. 541 Using a TRILL unicast header for a multi-destination frame when it 542 has only one actual destination RBridge can improve traffic spreading 543 and decrease latency as discussed in Appendix A. How to decide 544 whether to use a distribution tree or serial unicast for a multi- 545 destination TRILL Data frame that has more than one destination TRILL 546 switch is beyond the scope of this document. 548 5.2 Transit Processing 550 Any FGL TRILL switch, Limited or Full, MUST be capable of TRILL Data 551 frame transit processing. Such processing is fairly straightforward 552 as described in Section 5.2.1 for known unicast TRILL Data frames and 553 in Section 5.2.2 for multi-destination TRILL Data frames. 555 5.2.1 Unicast Transit Processing 557 There is very little change in TRILL Data frame unicast transit 558 processing. A transit TRILL switch forwards any unicast TRILL Data 559 frame to the next hop towards the egress TRILL switch as specified in 560 the TRILL Header. All transit TRILL switches, whether VL or FGL, MUST 561 take the priority and DEI used to forward a frame from the Inner.VLAN 562 label or the FGL Inner.Label High Part. These bits are in the same 563 place in the frame. 565 An FGL TRILL switch, including a Limited FGL TRILL switch that might 566 have limited knowledge of FGL formats, MUST properly distinguish 567 flows if it provides ECMP for FGL frame. 569 5.2.2 Multi-Destination Transit Processing 571 Multi-destination TRILL Data frames are forwarded on a distribution 572 tree selected by the ingress TRILL switch except that an FGL ingress 573 TRILL switch may TRILL unicast such a frame to all relevant egress 574 TRILL switches as described in Section 5.1. The distribution trees 575 do not distinguish between FGL and VL multi-destination frames 576 except, possibly, in pruning behavior. All distribution trees are 577 calculated as provided for in the TRILL base protocol standard 578 [RFC6325] as updated by [ClearCorrect]. There is no change in the 579 Reverse Path Forwarding Check. 581 An FGL TRILL switch, say RB1, having an FGL multi-destination frame 582 for label (X.Y) to forward on a distribution tree, SHOULD prune that 583 tree based on whether there are any edge TRILL switches on a tree 584 branch that are advertising connectivity to label (X.Y). In addition, 585 RB1 SHOULD prune multicast frames based on reported multicast 586 listener and multicast router attachment in (X.Y). 588 Pruning is an optimization. If a transit TRILL switch does less 589 pruning than it could, there may be greater link utilization than 590 strictly necessary but the campus will still operate correctly. A 591 transit TRILL switch MAY prune based on an arbitrary subset of the 592 bits in the FGL label, for example only the High Part or only the Low 593 Part of the label. 595 5.3 Egress Processing 597 Egress processing is generally the reverse of ingress progressing 598 described in Section 5.1. 600 A Full FGL TRILL switch MUST be able to configurably convert the FGL 601 in an FGL TRILL Data frame it is egressing to a C-VLAN ID for the 602 resulting native frame on a per port basis. The priority and DEI of 603 the egressed native frame are taken from the Inner.Label Low Order 604 Part. A port MAY be configured to strip output VLAN tagging. 606 It is the responsibility of the network manager to properly configure 607 the TRILL switches in the campus to obtain the desired mappings. 609 An FGL TRILL switch egresses FGL frames similarly to the egressing of 610 VL frames, as follows: 612 1. A known unicast FGL TRILL Data frame is egressed to the FGL 613 port or ports matching its FGL and Inner.MacDA. If there are no 614 such ports, it is flooded out all FGL ports that have its FGL 615 except any ports that for which the TRILL switch has knowledge 616 that the frame's Inner.MacDA cannot be out that port. 618 2. A multi-destination FGL frame is decapsulated and flooded out 619 all ports with its FGL, subject to multicast pruning. 621 An FGL TRILL switch, including a Limited FGL TRILL switch that might 622 have limited knowledge of FGL formats, MUST NOT egress an FGL frame 623 with label (X.Y) to any port not configured with that label even if 624 the port is configured to egress VL frames in VLAN X. 626 FGL TRILL switches MUST accept multi-destination TRILL Data frames 627 that are sent to them as TRILL unicast frames, that is, frames that 628 may have a multicast or broadcast Inner.MacDA (or are being sent to 629 an unknown unicast Inner.MacDA) and the TRILL Header M bit set to 0. 630 They locally egress such frames, if appropriate, but MUST NOT forward 631 them (other than egressing them as native frames on their local 632 links). 634 5.4 Appointed Forwarders and the DRB 636 There is no change in Adjacency [RFC6327] or Appointed Forwarder 637 logic [RFC6439] on a link regardless of whether some or all the ports 638 on the link are for FGL TRILL switches except for the refusal of FGL 639 TRILL switches to report adjacencies on links with mixed VL and FGL 640 TRILL switches, as described in Section 4 above. 642 5.5 Address Learning 644 An FGL TRILL switch learns addresses on ports configured for FGL 645 based on the fine-grained label rather than the native frame's VLAN. 646 Addresses learned from ingressed native frames on FGL ports are 647 logically represented by { MAC address, FGL, port, confidence, timer 648 } while remote addresses learned from egressing FGL frames are 649 logically represented by { MAC address, FGL, remote TRILL switch 650 nickname, confidence, timer }. 652 5.6 ESADI Extensions 654 The TRILL ESADI (End Station Address Distribution Information) 655 protocol is specified in [RFC6325] as optionally transmitting MAC 656 address connection information through TRILL Data frames between 657 participating TRILL switches over the virtual link provided by the 658 TRILL multicast frame distribution mechanism. In [RFC6325], the VL to 659 which an ESADI frame applies is indicated only by the Inner.VLAN 660 label and no indication of that VL is allowed within the ESADI 661 payload. 663 ESADI is extended to support FGL by providing for the indication of 664 the FGL to which an ESADI frame applies only in the Inner.Label of 665 that frame and no indication of that FGL is allowed within the ESADI 666 payload. 668 6. IS-IS Extensions 670 Extensions to the TRILL use of IS-IS are required to support FGL 671 include the following: 673 1. An method for a TRILL switch to announce itself in its LSP as 674 supporting FGL (see Section 8.2). 676 2. A sub-TLV analogous to Interested VLANs and Spanning Tree Roots 677 sub-TLV of the Router Capabilities TLV but indicating FGLs 678 rather than VLs. This is called the Interested Labels and 679 Spanning Tree Roots sub-TLV in [rfc6326bis]. 681 3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group 682 Address TLV that specifies an FGL rather than a VL. These are 683 called the GLMAC-ADDR, GLIP-ADDR, and GLIP6 ADDR sub-TLVs in 684 [rfc6326bis]. 686 7. Comparison to Goals 688 Comparing TRILL FGL, as specified in this document, with the goals 689 given in Section 2.1, we find as follows: 691 1. Fine-Grained: FGL provides 2**24 labels, vastly more than the 4K 692 VL labels provided in [RFC6325]. 694 2. Silicon: Existing TRILL fast path silicon chips can perform base 695 TRILL Header insertion and removal to support ingress and egress. 696 In addition, it is believed that most such silicon can also 697 perform the native frame to FGL mapping and the encoding of the 698 FGL as specified herein, as well as the inverse decoding and 699 mapping. Some existing silicon can perform only one of these 700 operations on a frame in one pass through the fast path and so is 701 likely to be suitable as a full speed Limited FGL TRILL switch or 702 a reduced rate Full FGL TRILL switch requiring two passes for 703 ingress/egress; however, other existing chips are believed to be 704 able to perform both operations on the same frame in one pass 705 through their fast path and are thus suitable for full rate Full 706 FGL TRILL processing. 708 3. Base RBridge Compatibility: As described in Section 3, FGL is not 709 generally compatible with TRILL switches conformant to the base 710 specification [RFC6325] although, as described in Section 4.3, 711 there are possible future TRILL extensions that would enable data 712 intercommunication in some topologies. In particular, an FGL- 713 ignorant TRILL switch cannot be even a Limited FGL TRILL switch in 714 a restricted topology because there is a risk that it would 715 receive multi-destination FGL frames and egress them to the wrong 716 VLAN. However, a contiguous set of VL TRILL switches can exchange 717 VL frames regardless of the presence of FGL TRILL switches in the 718 campus. 720 4. Alternate Priority: The encoding specified in Section 2.3 and the 721 ingress/egress processing specified in Section 5 provide for a new 722 priority and DEI in the Inner.Label High Part and a place to 723 preserve the original user priority and DEI in the Low Part, so it 724 can be restored on egress. 726 8. Allocation Considerations 728 Allocations by the IEEE Registration Authority and IANA are listed 729 below. 731 8.1 IEEE Allocation Considerations 733 The IEEE Registration Authority has assigned Ethertype 0x893B for use 734 as the TRILL FGL Ethertype. 736 8.2 IANA Considerations 738 IANA is requested to allocate capability bit TBD in the TRILL-VER 739 sub-TLV capability bits [RFC6326bis] to indicate a TRILL switch is 740 FGL-capable (either Limited FGL or Full FGL). 742 9. Security Considerations 744 See [RFC6325] for general TRILL Security Considerations. 746 As with any communications system, end-to-end encryption and 747 authentication should be considered for sensitive data. In this case 748 that would be encryption and authentication extending from a source 749 end station to a destination end station. 751 Confusion between a frame with VL X and FGL (X.Y) or confusion due to 752 a malformed frame is a potential problem if an FGL TRILL switch did 753 not properly check for the occurrence of 0x8100 or 0x893B immediately 754 after the Inner.MacSA (see Sections 2.2 and 2.3) and handled the frame 755 appropriately. 757 [RFC6325] requires that the Ethertype immediately after the 758 Inner.MacSA be 0x8100. A VL TRILL switch that did not discard a frame 759 with some other value there could cause problems. If it received a 760 TRILL Data frame with FGL (X.Y) or with junk after the Inner.MacSA 761 that included X where a VLAN ID would appear, then: 763 1. It could egress the frame to an end station in VLAN-X. If the 764 frame was a well formed FGL frame, the payload of such an 765 egressed native frame would appear to begin with Ethertype 766 0x893B that would likely be discarded by an end station. In any 767 case, such an egress would almost certainly be a violation of 768 security policy requiring the configurable separation of 769 differently labeled data. 771 2. If the frame was multi-destination and the TRILL switch pruned 772 the distribution tree, it would incorrectly prune it on the 773 basis of VLAN-X. For an FGL frame, this would probably lead to 774 the multi-destination data frame not being delivered to all of 775 its intended recipients. 777 Possible problems with an FGL TRILL switch that received a TRILL Data 778 frame with junk after the Inner.MacSA that included X where a VLAN ID 779 would appear and did not check the Ethertype immediately after the 780 Inner.MacSA would be that it could improperly egress the frame in 781 VLAN-X, violating security policy. If the frame was multi-destination 782 and was improperly forwarded, it should be discarded by properly 783 implemented TRILL switches downstream in the distribution tree and 784 never egressed but the propagation of the frame would still waste 785 bandwidth. 787 To avoid these problems all TRILL switches MUST check the Ethertype 788 immediately after the Inner.MacSA and, if it is a value they do not 789 know how to handle, either discard the frame or make no decisions 790 based on any data after that Ethertype. In addition, care must be 791 taken to avoid FGL frames being sent to or through VL TRILL switches 792 that will discard them if the VL TRILL switch is properly implemented 793 or mishandle them if it is not properly implemented. This is 794 accomplished, as described in Section 4, by FGL TRILL switches not 795 announcing adjacency to VL TRILL switches. As a result, no TRILL data 796 frames can be exchanged between VL and FGL TRILL switches and they 797 will be isolated form each other for data purposes. 799 Acknowledgements 801 The comments and suggestions of the following are gratefully 802 acknowledged: 804 Anoop Ghanwani, Sujay Gupta, Weiguo Hao, Jon Hudson, Phanidhar 805 Koganti, Yizhou Li, Vishwas Manral, Rajeev Manur, Thomas Narten, 806 Erik Nordmark, Olen Stokes, Ilya Varlashkin, and Xuxiaohu. 808 The document was prepared in raw nroff. All macros used were defined 809 within the source file. 811 Normative References 813 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 814 Intermediate System Intra-Domain Routeing Exchange Protocol for 815 use in Conjunction with the Protocol for Providing the 816 Connectionless-mode Network Service (ISO 8473)", 2002. 818 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 819 networks - Virtual Bridged Local Area Networks", IEEE Std 820 802.1Q-2011, May 2011. 822 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997. 825 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 826 Ghanwani, "Routing Bridges (RBridges): Base Protocol 827 Specification", RFC 6325, July 2011. 829 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 830 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 831 6327, July 2011 833 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 834 A. Ghanwani, "Transparent Interconnection of Lots of Links 835 (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, Work in 836 Progress. 838 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 839 Manral, draft-ietf-trill-clear-correct-06.txt, in RFC Editor's 840 queue. 842 Informative References 844 [MultiTopo] 845 - draft-tissa-trill-mt-encode, Work in Progress. 846 - draft-eastlake-trill-rbridge-multi-topo, Work in Progress. 848 [OAMframework] - draft-ietf-trill-oam-framework, Work in Progress. 850 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 851 Layer-2 Systems", RFC 6165, April 2011. 853 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 854 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 855 6439, November 2011. 857 Appendix A: Serial Unicast 859 This appendix discusses advantages and disadvantages of using serial 860 unicast instead of a distribution tree for multi-destination TRILL 861 Data frames. See Sections 5.1 and 5.3. 863 Consider a large TRILL campus with hundreds of TRILL switches in 864 which, say, 300 end stations are in some particular FGL data label. 866 At one extreme, if all 300 end stations were on links attached to a 867 single TRILL switch, then no other TRILL switch would be advertising 868 interest in that FGL and likely a multi-destination (say broadcast) 869 frame from one such end station would, even if put on a distribution 870 tree, because of pruning, not get sent to any another TRILL switch. 872 At the other extreme, assume the 300 end stations are attached, one 873 each, to 300 different TRILL switches; in that case you are almost 874 certainly better off using a distribution tree because if you tried 875 to serially unicast you would probably have to output multiple copies 876 through the same port port and would cause much higher link 877 utilization. 879 Now assume these 300 end stations are connected to exactly two TRILL 880 switches, say 200 to one and 100 to the other. Using unicast TRILL 881 Data frames between these two TRILL switches is best because the 882 frames will follow least cost paths, possibly with such traffic 883 spread over a number of equal cost least cost paths. On the other 884 hand, if a distribution trees were used, each frame would be 885 constrained to the tree used for that frame and would likely follow a 886 more circuitous route, depending on where the tree's root ia, and 887 only a single path would be available per tree. Thus this document 888 says that unicast "SHOULD" be used if there are exactly two TRILL 889 switches involved. 891 It is a more complex decision whether to use a distribution tree or 892 serial unicast if the end stations are connected to a number of TRILL 893 switches greater than two. Which would be better would depend on many 894 factors including network topology and application data patterns. How 895 to make this decision in such more complex cases is beyond the scope 896 of this document. 898 Appendix Z: Change History 900 RFC Editor Note: Please delete this appendix before publication. 902 From -00 to -01: 904 Update author info and make editorial changes. 906 From -01 to -02 908 1. Change the value after the inner MAC addresses for FGL frames 909 from 0x8100 to 0x893B 911 2. As a consequence of item 1 above, for safety prohibit use for 912 TRILL Data of links between FGL and VL RBridges, isolating any 913 VL RBridges. Make appropriate changes throughout document, 914 including Security Considerations section, based on this 915 change. 917 3. Reference and contributor updates. 919 4. Minor editorial changes. 921 From -02 to -03 923 1. Addition of the terms "Limited FGL" and "Full FGL". 925 2. Addition of Appendix A. 927 3. Clarifications: 928 3.a That FGL TRILL switches also support VL ports and frames 929 (Add Section 2.4, etc.). 930 3.b That the FGL extensions to TRILL are optional. A VL TRILL 931 switch is still a conformant implementation. 932 3.c The utility of the alternate priority goal. 934 4. Expand Security Considerations discussion of misparsed frames. 936 5. Substantial editorial changes. 938 Authors' Addresses 940 Donald Eastlake 3rd 941 Huawei Technologies 942 155 Beaver Street 943 Milford, MA 01757 USA 945 Phone: +1-508-333-2270 946 Email: d3e3e3@gmail.com 948 Mingui Zhang 949 Huawei Technologies Co., Ltd 950 Huawei Building, No.156 Beiqing Rd. 951 Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, 952 Beijing 100095 P.R. China 954 Email: zhangmingui@huawei.com 956 Puneet Agarwal 957 Broadcom Corporation 958 3151 Zanker Road 959 San Jose, CA 95134 USA 961 Phone: +1-949-926-5000 962 Email: pagarwal@broadcom.com 964 Radia Perlman 965 Intel Labs 966 2200 Mission College Blvd. 967 Santa Clara, CA 95054 USA 969 Phone: +1-408-765-8080 970 Email: Radia@alum.mit.edu 972 Dinesh G. Dutt 973 Cumulus Networks 974 1089 West Evelyn Avenue 975 Sunnyvale, CA 94086 USA 977 Email: ddutt.ietf@hobbesdutt.com 979 Copyright, Disclaimer, and Additional IPR Provisions 981 Copyright (c) 2012 IETF Trust and the persons identified as the 982 document authors. All rights reserved. 984 This document is subject to BCP 78 and the IETF Trust's Legal 985 Provisions Relating to IETF Documents 986 (http://trustee.ietf.org/license-info) in effect on the date of 987 publication of this document. Please review these documents 988 carefully, as they describe your rights and restrictions with respect 989 to this document. Code Components extracted from this document must 990 include Simplified BSD License text as described in Section 4.e of 991 the Trust Legal Provisions and are provided without warranty as 992 described in the Simplified BSD License. The definitive version of 993 an IETF Document is that published by, or under the auspices of, the 994 IETF. Versions of IETF Documents that are published by third parties, 995 including those that are translated into other languages, should not 996 be considered to be definitive versions of IETF Documents. The 997 definitive version of these Legal Provisions is that published by, or 998 under the auspices of, the IETF. Versions of these Legal Provisions 999 that are published by third parties, including those that are 1000 translated into other languages, should not be considered to be 1001 definitive versions of these Legal Provisions. For the avoidance of 1002 doubt, each Contributor to the IETF Standards Process licenses each 1003 Contribution that he or she makes as part of the IETF Standards 1004 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1005 language to the contrary, or terms, conditions or rights that differ 1006 from or are inconsistent with the rights and licenses granted under 1007 RFC 5378, shall have any effect and shall be null and void, whether 1008 published or posted by such Contributor, or included with or in such 1009 Contribution.