idnits 2.17.1 draft-ietf-trill-fine-labeling-02.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 (October 21, 2012) is 4205 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 6327 (Obsoleted by RFC 7177) -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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: April 20, 2012 October 21, 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 and encapsulation with a hop count. 22 The TRILL base protocol standard supports labeling of TRILL data with 23 up to 4K IDs. However, there are applications that require more fine- 24 grained labeling of data. This document updates RFC 6325 and 6327 by 25 specifying extensions to the TRILL base protocol to safely accomplish 26 this. 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the TRILL working group mailing list. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................3 54 1.1 Terminology............................................3 55 1.2 Contributors...........................................4 57 2. Fine-Grained Labeling...................................5 58 2.1 Goals..................................................5 59 2.2 Base Protocol TRILL Data Labeling......................6 60 2.3 Fine-Grained Labeling (FGL)............................7 62 3. Campus Wide VL versus FGL Semantic Differences..........9 63 4. Interaction with VL TRILL Switches.....................10 65 5. Fine-Grained Labeling Details..........................12 66 5.1 Ingress Processing....................................12 67 5.2 Transit Processing....................................12 68 5.2.1 Unicast Transit Processing..........................13 69 5.2.2 Multi-Destination Transit Processing................13 70 5.3 Egress Processing.....................................13 71 5.4 Appointed Forwarders and the DRB......................14 72 5.5 Address Learning......................................14 73 5.6 ESADI Extensions......................................14 75 6. IS-IS Extensions.......................................16 76 7. Comparison to Goals....................................17 78 8. Allocation Considerations..............................18 79 8.1 IEEE Allocation Considerations........................18 80 8.2 IANA Considerations...................................18 82 9. Security Considerations................................19 84 Acknowledgements..........................................19 85 Normative References......................................20 86 Informative References....................................20 87 Change History............................................21 89 1. Introduction 91 The IETF has standardized the TRILL (TRansparent Interconnection of 92 Lots of Links) protocol [RFC6325]. TRILL switches provide a solution 93 for least cost transparent routing in multi-hop networks with 94 arbitrary topologies and link technologies, using [IS-IS] [RFC6165] 95 [RFC6326bis] link-state routing and encapsulation with a hop count. 96 They address the problems outlined in [RFC5556]. TRILL switches are 97 sometimes called RBridges (Routing Bridges). 99 The TRILL base protocol standard supports labeling of TRILL data with 100 up to 4K IDs. However, there are applications that require more fine- 101 grained labeling of data for configurable isolation based on 102 different tenants, service instances, or the like. This document 103 updates [RFC6325] and [RFC6327] by specifying extensions to the TRILL 104 base protocol to safely accomplish this. 106 Familiarity with [RFC6325] and [RFC6326bis] is assumed in this 107 document. 109 1.1 Terminology 111 The terminology and acronyms of [RFC6325] are used in this document 112 with the additions listed below. 114 DEI - Drop Eligibility Indicator [802.1Q] 116 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine- 117 Grained Label 119 FGL RBridge - A TRILL switch that support both FGL and VL 121 Edge RBridge - A TRILL switch announcing VL or FGL connectivity in 122 its LSP 124 TRILL Switch - Alternative name for an RBridge 126 VL - VLAN Labeling or VLAN Labeled or VLAN Label 128 VL RBridge - A TRILL switch that supports VL but does not support 129 FGL 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 1.2 Contributors 137 Thanks for the contributions of the following: 139 Tissa Senevirathne 141 2. Fine-Grained Labeling 143 The essence of Fine-Grained Labeling (FGL) is that (a) when TRILL 144 Data frames are ingressed or created they may incorporate a label 145 from a set consisting of significantly more than 4K labels, (b) TRILL 146 switch (RBridge) ports can be labeled with a set of such labels, and 147 (c) an FGL TRILL Data frame cannot be egressed through an RBridge 148 port unless its fine-grained label (FGL) matches one of the labels of 149 the port. 151 Section 2.1 lists FGL goals. Section 2.2 briefly outlines the more 152 coarse TRILL base protocol standard [RFC6325] data labeling. And 153 Section 2.3 outlines a method of FGL of TRILL Data frames. 155 2.1 Goals 157 There are several goals that should be met by FGL in TRILL. They are 158 briefly described in the list below in approximate order by priority 159 with the most important first. 161 1. Fine-Grained 163 Some networks have a large number of entities that need 164 configurable isolation, whether those entities are independent 165 customers, applications, or branches of a single endeavor or some 166 combination of these or other entities. The labeling supported by 167 [RFC6325] provides for only ( 2**12 - 2 ) valid identifiers or 168 labels. A substantially larger number is required. 170 2. Silicon Considerations 172 Fine-grained labeling (FGL) should, to the extent practical, use 173 existing features, processing, and fields that are already 174 supported in at least some fast path silicon implementations that 175 currently support the TRILL base protocol. 177 3. Base RBridge Compatibility 179 To support some incremental conversion scenarios, it is desirable 180 that not all RBridges in a campus using FGL be required to be FGL 181 aware. That is, it is desirable that RBridges not implementing the 182 FGL feature and performing at least the transit forwarding 183 function can usefully process TRILL Data frames that incorporate 184 FGL. 186 4. Alternate Priority 188 It would be desirable for an ingress TRILL Switch to be able to 189 assign a different priority to an FGL TRILL Data frame for its 190 ingress-to-egress propagation from the priority of the original 191 native frame. The original priority should be restored on egress. 193 2.2 Base Protocol TRILL Data Labeling 195 This section provides a brief review of the [RFC6325] TRILL Data 196 frame internal VL Labeling and changes the description of the TRILL 197 Header by moving its end point. This description change does not 198 involve any change in the bits on the wire or in the behavior of 199 existing [RFC6325] RBridges. 201 Currently TRILL Data frames have the VL structure shown below: 203 +-------------------------------------------+ 204 | Link Header (depends on link technology) | 205 | (if link is an Ethernet link the link | 206 | header may include an Outer.VLAN tag) | 207 +-------------------------------------------+ 208 | TRILL Header | 209 | +---------------------------------------+ | 210 | | Initial Fields and Options | | 211 | +---------------------------------------+ | 212 | | Inner.MacDA | (6 bytes) | 213 | +-----------------------------+ | 214 | | Inner.MacSA | (6 bytes) | 215 | +-----------------------+-----+ | 216 | | Ethertype 0x8100 | (2 bytes) | 217 | +-----------------------+ | 218 | | Inner.VLAN Label | (2 bytes) | 219 | +-----------------------+ | 220 +-------------------------------------------+ 221 | Native Payload | 222 +-------------------------------------------+ 223 | Link Trailer (depends on link technology) | 224 +-------------------------------------------+ 226 Figure 1. TRILL Data with VL 228 In the base protocol as specified in [RFC6325] the 0x8100 value is 229 always present and is followed by the Inner.VLAN field which includes 230 the 12-bit VL. 232 2.3 Fine-Grained Labeling (FGL) 234 FGL expands the data label available under the TRILL base protocol 235 standard to a fine-grained label (FGL) with a 12-bit high order part 236 and a 12-bit low order part. In this document, FGLs are usually 237 denoted as "(X.Y)" where X is the high order part and Y is the low 238 order part of the FGL. The FGL information appears in the TRILL 239 Header as shown below. 241 +-------------------------------------------+ 242 | Link Header (depends on link technology) | 243 | (if link is an Ethernet link the link | 244 | header may include an Outer.VLAN tag) | 245 +-------------------------------------------+ 246 | TRILL Header | 247 | +---------------------------------------+ | 248 | | Initial Fields and Options | | 249 | +---------------------------------------+ | 250 | | Inner.MacDA | (6 bytes) | 251 | +-----------------------------+ | 252 | | Inner.MacSA | (6 bytes) | 253 | +-----------------------+-----+ | 254 | | Ethertype 0x893B | (2 bytes) | 255 | +-----------------------+ | 256 | | Inner.Label High Part | (2 bytes) | 257 | +-----------------------+ | 258 | | Ethertype 0x893B | (2 bytes) | 259 | +-----------------------+ | 260 | | Inner.Label Low Part | (2 bytes) | 261 | +-----------------------+ | 262 +-------------------------------------------+ 263 | Native Payload | 264 +-------------------------------------------+ 265 | Link Trailer (depends on link technology) | 266 +-------------------------------------------+ 268 Figure 2. TRILL Data with FGL 270 For FGL frames, the inner MAC address fields are followed by the FGL 271 information using 0x893B. 273 The two bytes following each 0x893B have, in their low order 12 bits, 274 fine-grained label information. The upper 4 bits of those two bytes 275 are used for a 3-bit priority field and one drop eligibility 276 indicator (DEI) bit. 278 The priority field of the Inner.Label High Part is the priority used 279 for frame transport across the TRILL campus from ingress to egress. 280 The label bits in the Inner.Label High Part are the high order part 281 of the FGL and those bits in the Inner.Label Low Part are the low 282 order part of the FGL. 284 The appropriate FGL value for an ingressed native frame is determined 285 by the ingress RBridge port as specified in Section 5.1. Ports of 286 TRILL switches supporting FGL also have capabilities to transmit 287 frames being forwarded or egressed as untagged or VL as specified in 288 Section 5.3. 290 3. Campus Wide VL versus FGL Semantic Differences 292 There are differences between the semantics across a TRILL campus for 293 VL and FGL labeled TRILL Data frames. 295 With VL, data label IDs have the same meaning throughout the campus 296 and are from the same label space as the VLAN IDs used on Ethernet 297 links to end stations. 299 With TRILL FGL, many things remain the same. Ports of FGL TRILL 300 switches, up through the usual VLAN and priority processing, act as 301 they do for VL TRILL switches: Ethernet links between FGL TRILL 302 switches still have only C-VLAN tagging on them and TRILL switch 303 ports provide a VLAN ID for an incoming frame and accepts a VLAN ID 304 for a frame being queued for output. Appointed Forwarders [RFC6439] 305 on a link are still appointed for a C-VLAN. The Designated VLAN for 306 an Ethernet link is still a C-VLAN. 308 The larger FGL space is a different space from the VL data label 309 space. For ports configured for FGL, the C-VLAN on an ingressed 310 native frame is mapped to the FGL data label space with a potentially 311 different mapping for each port. A similar FGL to C-VLAN mapping 312 occurs per port on egress. Thus, for ports configured for FGL, the 313 native frame C-VLAN on one link corresponding to an FGL can be 314 different from the native frame C-VLAN corresponding to that same FGL 315 on a different link elsewhere in the campus or even a different link 316 attached to the same RBridge. The FGL label space is flat and does 317 not hierarchically encode any particular number of native frame C- 318 VLAN bits or the like. FGLs in TRILL Data frames appear only inside 319 the TRILL Header after the inner MAC addresses. They are only seen by 320 TRILL aware devices. 322 FGL RBridge ports can be configured for FGL or VL with VL being the 323 default. As with a base protocol [RFC6325] RBridge, an unconfigured 324 FGL TRILL switch port reports an untagged frame it receives as being 325 in VLAN 1. 327 4. Interaction with VL TRILL Switches 329 It is not possible for VL TRILL switches to handle FGL frames even if 330 the VL TRILL switch is only acting in the transit capacity. This is 331 because VL frames are required to have 0x8100 at the beginning of the 332 data label where FGL TRILL switches have 0x893B. VL-only TRILL 333 switches conformant to [RFC6325] should discard frames with this new 334 value after the inner MAC addresses and, if they do not discard such 335 frames, they will be confused (see Section 9 below). 337 If there are FGL TRILL switches in a campus, it is assumed that the 338 intent is for all TRILL switches in that campus to support FGL. Any 339 VL TRILL switches present are isolated by FGL TRILL switches as 340 follows: FGL RBridges will report their FGL capability in LSPs. Thus 341 FGL TRILL switches (and any management system with access to the link 342 state database) will be able to detect the existence of TRILL 343 switches in the campus that do not support FGL. If any such VL TRILL 344 switches are present on a link then, although all other aspects of 345 the adjacency machinery work as normal [RFC6327], any FGL TRILL 346 switches on the link will not create a pseudo node for the link if 347 they are DRB and do not announce any adjacencies they have on the 348 link. As a result, although adjacencies between two or more VL 349 RBridge ports on the link could become part of the campus topology 350 and pass TRILL Data frames, no adjacency from an FGL RBridge port to 351 a VL RBridge port or to a pseudonode will be reported for such a 352 mixed FGL/VL link. Since an adjacency must be reported up by both 353 ends before it becomes part of the campus topology, even though 354 adjacencies to an FGL RBridge might be reported by a VL RBridge, no 355 TRILL Data can flow between an FGL RBridge port and a VL RBridge 356 port. 358 The usual DRB election operates on a link with mixed FLG and VL 359 ports. If an FGL RBridge port is DRB, it MUST handle all native 360 traffic or appoint only other FGL ports as forwarder for one or more 361 VLANs, so that all end stations will get service to the FGL campus. 362 If a VL RBridge port is DRB, it will not understand that FGL RBridge 363 ports are different. To the extent that a VL DRB handles native 364 frames or appoints other VL ports on a link to handle native frames 365 for one or more VLANs, the end stations sending and receiving those 366 native frames will be isolated from the FGL campus. To the extent 367 that a VL DRB happens to appoint an FGL port as Appointed Forwarder 368 for one or more VLANs, the end stations sending and receiving native 369 frames in those VLANs will get service to the FGL campus. This 370 somewhat odd corner case behavior is considered acceptable because it 371 is assumed that VL TRILL switches in an FGL campus are infrequent 372 misconfigurations. 374 For links configured as point-to-point, if the TRILL switches at each 375 end are both VL or both FGL, a bi-directional adjacency can be formed 376 by the usual mechanisms. If one is VL and one is FGL but the point- 377 to-point link is otherwise correctly configured, the VL TRILL switch 378 will report an adjacency but the LFG one will not. As a result, the 379 link will not become part of the topology and TRILL Data cannot flow 380 over the link, isolating the VL TRILL switch. 382 5. Fine-Grained Labeling Details 384 This section specifies ingress, transit, egress, and other processing 385 of TRILL Data frames with regard to FGLs. A transit or egress FGL 386 TRILL switch determines that a TRILL Data frame is FGL by detecting 387 that the inner MAC address fields are followed by 0x893B. 389 5.1 Ingress Processing 391 An FGL RBridge MAY be configured, on one or more ports, to ingress 392 native frames as FGL. Any ports not so configured that accepts a 393 native frame perform the previously specified VL ingress processing 394 on native frames [RFC6325]. There is no change in Appointed 395 Forwarder logic (see Section 5.4). 397 FGL TRILL switches MUST support configurable per port mapping from 398 the VL of a native frame, as reported by the ingress port, to an FGL. 399 FGL TRILL switches MAY support other methods to determine the FGL of 400 an incoming native frame, such as based on the protocol of the native 401 frame or local knowledge. 403 The FGL ingress process MUST place the priority and DEI associated 404 with an ingressed native frame in upper 4 bits of the Inner.Label Low 405 Order part. It SHOULD also associate a possibly different mapped 406 priority and DEI with an ingressed frame. The mapped priority is 407 placed in the Inner.Label High Part. If such mapping is not supported 408 then the original priority and DEI MUST be placed in the Inner.Label 409 High Part. 411 An FGL ingress RBridge MAY serially TRILL unicast a multi-destination 412 TRILL Data frame to the relevant egress TRILL switches after 413 encapsulating it as a TRILL known unicast data frame (M=0) and SHOULD 414 unicast such a multi-destination TRILL Data frame if there is only 415 one relevant egress FGL RBridge. For FGL RBridges, this permits 416 serial unicast of multi-destination frames by the ingress as an 417 alternative to the use of a distribution tree. The relevant egress 418 TRILL switches are determined by starting with those announcing 419 connectivity to the frame's (X.Y) label. That set SHOULD be further 420 filtered based on multicast listener and multicast router 421 connectivity if the native frame was a multicast frame. 423 5.2 Transit Processing 425 TRILL Data frame transit processing is fairly straightforward as 426 described in Section 5.2.1 for known unicast TRILL Data frames and in 427 Section 5.2.2 for multi-destination TRILL Data frames. 429 5.2.1 Unicast Transit Processing 431 There is very little change in TRILL Data frame unicast transit 432 processing. A transit TRILL switch forwards any unicast TRILL Data 433 frame to the next hop towards the egress RBridge as specified in the 434 TRILL Header. All transit TRILL switches, whether VL or FGL, MUST 435 take the priority and DEI used to forward a frame from the Inner.VLAN 436 label or the FGL Inner.Label High Part. These bits are in the same 437 place in the frame. 439 5.2.2 Multi-Destination Transit Processing 441 Multi-destination TRILL Data frames are forwarded on a distribution 442 tree selected by the ingress TRILL switch except that an FGL ingress 443 RBridge MAY choose to TRILL unicast such a frame to all relevant 444 egress TRILL switches. The distribution trees do not distinguish 445 between FGL and VL multi-destination frames except, possibly, in 446 pruning behavior. All distribution trees are calculated as provided 447 for in the TRILL base protocol standard [RFC6325]. There is no change 448 in the Reverse Path Forwarding Check. 450 An FGL RBridge, say RB1, having an FGL multi-destination frame for 451 label (X.Y) to forward on a distribution tree, SHOULD prune that tree 452 based on whether there are any edge TRILL switches on a tree branch 453 that are advertising connectivity to label (X.Y). In addition, RB1 454 SHOULD prune multicast frames based on reported multicast listener 455 and multicast router attachment in (X.Y). 457 Pruning is an optimization. If a transit TRILL switch does less 458 pruning than it could, there may be greater link utilization than 459 strictly necessary but the campus will still operate correctly. For 460 example, a transit TRILL switch could prune based on only part of the 461 FGL such as only the High Part or only the Low Part. 463 5.3 Egress Processing 465 Egress processing is generally the reverse of ingress progressing 466 described in Section 5.1. 468 An FGL RBridge MUST be able to configurably convert the FGL in an FGL 469 TRILL Data frame it is egressing to a VLAN ID for the resulting 470 native frame on a per port basis. A port MAY be configured to strip 471 output VLAN tagging. It is the responsibility of the network manager 472 to properly configure the TRILL switches in the campus to obtain the 473 desired mappings. 475 The priority and DEI of the egressed native frame are taken from the 476 Inner.Label Low Order Part. 478 An FGL RBridge egresses FGL frames similarly to the egressing of VL 479 frames, as follows: 481 1. A known unicast FGL frame is egressed to the FGL port matching its 482 fine-grained label and Inner.MacDA. If there is no such port, it 483 is flooded out all FGL ports that have its FGL unless the TRILL 484 switch has knowledge that the frame's Inner.MacDA cannot be out 485 that port. 487 2. A multi-destination FGL frame is decapsulated and flooded out all 488 ports with its FGL, subject to multicast pruning. 490 FGL RBridges MUST accept multi-destination encapsulated frames that 491 are sent to them as TRILL unicast frames, that is, frames that may 492 have a multicast or broadcast Inner.MacDA (or are being sent to an 493 unknown unicast Inner.MacDA) and the TRILL Header M bit = 0. They 494 locally egress such frames, if appropriate, but MUST NOT forward them 495 (other than egressing them as native frames on their local links). 497 5.4 Appointed Forwarders and the DRB 499 There is no change in Adjacency [RFC6327] or Appointed Forwarder 500 logic [RFC6439] on a link regardless of whether some or all the ports 501 on the link are for FGL RBridges except as described in Section 4 502 above. 504 5.5 Address Learning 506 An FGL TRILL switch learns addresses on FGL ports based on the fine- 507 grained label rather than the native frame's VLAN. Addresses learned 508 from ingressed native frames on FGL ports are logically represented 509 by { MAC address, fine-grained label, port, confidence, timer } while 510 remote addresses learned from egressing FGL frames are logically 511 represented by { MAC address, fine-grained label, remote TRILL switch 512 nickname, confidence, timer }. 514 5.6 ESADI Extensions 516 The TRILL ESADI (End Station Address Distribution Information) 517 protocol is specified in [RFC6325] as optionally transmitting MAC 518 address connection information through TRILL Data frames between 519 participating TRILL switches over the virtual link provided by the 520 TRILL multicast frame distribution mechanism. In [RFC6325], the VLAN 521 to which an ESADI frame applies is indicated only by the Inner.VLAN 522 label and no indication of that VLAN is allowed within the ESADI 523 payload. 525 ESADI is extended to support FGL by providing for the indication of 526 the FGL to which an ESADI frame applies only in the Inner.Label of 527 that frame and no indication of that FGL is allowed within the ESADI 528 payload. 530 6. IS-IS Extensions 532 Extensions to the TRILL use of IS-IS are required to support FGL 533 include the following: 535 1. An method for a TRILL switch to announce itself in its LSP as 536 supporting FGL. 538 2. A sub-TLV analogous to Interested VLANs and Spanning Tree Roots 539 sub-TLV of the Router Capabilities TLV but indicating FGLs rather 540 than VLs (see Section 8.2). This is called the Interested Labels 541 and Spanning Tree Roots sub-TLV in [rfc6326bis]. 543 3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group Address 544 TLV that specifies an FGL rather than a VL (see Section 8.2.). 545 This are called the GLMAC-ADDR, GLIP-ADDR, and GLIP6 ADDR sub-TLVs 546 in [rfc6326bis]. 548 7. Comparison to Goals 550 Comparing TRILL FGL, as specified in this document, with the goals 551 given in Section 2.1, we find as follows: 553 1. Fine-Grained: FGL provides 2**24 labels, vastly more labels than 554 the 4K VL labels provided in [RFC6325]. 556 2. Silicon Considerations: Existing TRILL fast path silicon chips can 557 perform base TRILL Header insertion and removal to support ingress 558 and egress. In addition, it is believed that most such silicon 559 chips can also perform the native frame to FGL mapping and the 560 encoding of the FGL as specified herein, as well as the inverse 561 decoding and mapping. Some existing silicon can perform only one 562 of these operations on a frame in the fast path and is thus not 563 suitable to implement fast path TRILL FGL processing; however, 564 other existing chips are believed to be able to perform both 565 operations on the same frame in the fast path and are suitable for 566 FGL implementation. 568 3. Base RBridge Compatibility: As described in Section 3, FGL is not 569 compatible with TRILL switches conformant to the base 570 specification RBridges [RFC6325]. 572 4. Alternate Priority: The encoding specified in Section 2.3 provides 573 for a new priority and DEI in the Inner.Label First Part and a 574 place to preserve the original user priority and DEI in the Second 575 Part, so it can be restored on egress. 577 8. Allocation Considerations 579 Allocations by the IEEE Registration Authority and IANA are listed 580 below. 582 8.1 IEEE Allocation Considerations 584 The IEEE Registration Authority has assigned Ethertype 0x893B for use 585 as the FGL Ethertype. 587 8.2 IANA Considerations 589 IANA is requested to allocate capability bit TBD in the TRILL-VER 590 sub-TLV capability bits [RFC6326bis] to indicate an RBridge is FGL- 591 capable. 593 9. Security Considerations 595 See [RFC6325] for general RBridge Security Considerations. 597 As with any communications system, end-to-end encryption and 598 authentication should be considered for sensitive data. 600 Confusion between a frame with VL X and FGL (X.Y) is a potential 601 problem if a VL RBridge did not check for the occurrence of 0x8100 602 (see Sections 2.2 and 2.3) and discard such a frame. Possible 603 problems with such a VL RBridge would be as follows: 605 1. If it received a TRILL Data frame with FGL (X.Y) it could egress 606 it to an end station in VLAN-X. The payload of such an egressed 607 frame would appear to begin with Ethertype 0x893B which would 608 likely be discarded by an end station. Nevertheless, such an 609 egress would almost certainly be a violation of security policy. 611 2. If it received a multi-destination TRILL Data frame with FGL (X.Y) 612 and it pruned the distribution tree, it would incorrectly prune it 613 on the basis of VLAN-X. This could lead to the multi-destination 614 data frame not being delivered to all of its intended recipients. 616 These two potential problems would only occur in the case of the 617 misconfiguration of attaching such a VL RBridge to an FGL campus; 618 however, there is protection against this in that FGL RBridges will 619 not announce adjacency to VL RBridges (see Section 4). As a result, 620 no TRILL data frames can be exchanged between VL and FGL RBridges and 621 VL RBridges will be isolated for data puposes. 623 Acknowledgements 625 The comments and suggestions of the following are gratefully 626 acknowledged: 628 Anoop Ghanwani, Sujay Gupta, Weiguo Hao, Jon Hudson, Yizhou Li, 629 Vishwas Manral, Erik Nordmark, and Ilya Varlashkin. 631 The document was prepared in raw nroff. All macros used were defined 632 within the source file. 634 Normative References 636 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 637 Intermediate System Intra-Domain Routeing Exchange Protocol for 638 use in Conjunction with the Protocol for Providing the 639 Connectionless-mode Network Service (ISO 8473)", 2002. 641 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 642 networks - Virtual Bridged Local Area Networks", IEEE Std 643 802.1Q-2011, May 2011. 645 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997 648 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 649 Ghanwani, "Routing Bridges (RBridges): Base Protocol 650 Specification", RFC 6325, July 2011. 652 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 653 A. Ghanwani, "Transparent Interconnection of Lots of Links 654 (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, work in 655 progress. 657 Informative References 659 [RFC5556] - Touch, J. and R. Perlman, "Transparent Interconnection of 660 Lots of Links (TRILL): Problem and Applicability Statement", 661 RFC 5556, May 2009. 663 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 664 Layer-2 Systems", RFC 6165, April 2011. 666 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 667 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 668 6327, July 2011 670 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 671 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 672 6439, November 2011. 674 Change History 676 From -00 to -01: 678 Update author info and make editorial changes. 680 From -01 to -02 682 1. Change the value after the inner MAC addresses for FGL frames from 683 0x8100 to 0x893B 685 2. As a consequence of item 1 above, for safety prohibit use for 686 TRILL Data of links between FGL and VL RBridges, isolating any VL 687 RBridges. Make appropriate changes throughout document, including 688 Security Considerations section, based on this change. 690 3. Reference and contributor updates. 692 4. Various editorial changes. 694 Authors' Addresses 696 Donald Eastlake 3rd 697 Huawei Technologies 698 155 Beaver Street 699 Milford, MA 01757 USA 701 Phone: +1-508-333-2270 702 Email: d3e3e3@gmail.com 704 Mingui Zhang 705 Huawei Technologies Co., Ltd 706 Huawei Building, No.156 Beiqing Rd. 707 Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, 708 Beijing 100095 P.R. China 710 Email: zhangmingui@huawei.com 712 Puneet Agarwal 713 Broadcom Corporation 714 3151 Zanker Road 715 San Jose, CA 95134 USA 717 Phone: +1-949-926-5000 718 Email: pagarwal@broadcom.com 720 Radia Perlman 721 Intel Labs 722 2200 Mission College Blvd. 723 Santa Clara, CA 95054 USA 725 Phone: +1-408-765-8080 726 Email: Radia@alum.mit.edu 728 Dinesh G. Dutt 729 Cumulus Networks 730 1089 West Evelyn Avenue 731 Sunnyvale, CA 94086 USA 733 Email: ddutt.ietf@hobbesdutt.com 735 Copyright, Disclaimer, and Additional IPR Provisions 737 Copyright (c) 2012 IETF Trust and the persons identified as the 738 document authors. All rights reserved. 740 This document is subject to BCP 78 and the IETF Trust's Legal 741 Provisions Relating to IETF Documents 742 (http://trustee.ietf.org/license-info) in effect on the date of 743 publication of this document. Please review these documents 744 carefully, as they describe your rights and restrictions with respect 745 to this document. Code Components extracted from this document must 746 include Simplified BSD License text as described in Section 4.e of 747 the Trust Legal Provisions and are provided without warranty as 748 described in the Simplified BSD License. The definitive version of 749 an IETF Document is that published by, or under the auspices of, the 750 IETF. Versions of IETF Documents that are published by third parties, 751 including those that are translated into other languages, should not 752 be considered to be definitive versions of IETF Documents. The 753 definitive version of these Legal Provisions is that published by, or 754 under the auspices of, the IETF. Versions of these Legal Provisions 755 that are published by third parties, including those that are 756 translated into other languages, should not be considered to be 757 definitive versions of these Legal Provisions. For the avoidance of 758 doubt, each Contributor to the IETF Standards Process licenses each 759 Contribution that he or she makes as part of the IETF Standards 760 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 761 language to the contrary, or terms, conditions or rights that differ 762 from or are inconsistent with the rights and licenses granted under 763 RFC 5378, shall have any effect and shall be null and void, whether 764 published or posted by such Contributor, or included with or in such 765 Contribution.