idnits 2.17.1 draft-eastlake-rbridge-compatibility-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 == Line 655 has weird spacing: '... Bridge bri...' == Line 656 has weird spacing: '... Bridge pro...' -- The document date (August 28, 2011) is 4625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 2 INTERNET-DRAFT Susan Hares 3 Intended status: Informational Huawei 4 Jon Hudson 5 Brocade 6 Expires: February 27, 2012 August 28, 2011 8 RBridge and Switching Device Layering and Compatibility 9 11 Abstract 13 This document describes a layering and peering model for network 14 switches and end stations. It also discusses, using this model, the 15 compatibility of RBridges (Routing Bridges) with Layer 3 routers and 16 various types of bridges including Shortest Path Bridges. RBridges 17 are devices that implement the IETF TRILL (TRansparent 18 Interconnection of Lots of Links) standard. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the TRILL working group mailing list. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Table of Contents 46 1. Introduction............................................3 47 1.1 Simplifying Assumptions................................3 48 1.2 Terminology............................................3 50 2. Layers and Peering......................................4 51 2.1 Basic Layers...........................................4 52 2.2 Basic Peering..........................................5 53 2.2.1 Bridges..............................................6 54 2.2.2 Layer 3 Routers......................................6 55 2.2.3 User End Stations....................................6 56 2.3 More Layers............................................7 57 2.3.1 RBridges (Routing Bridges)...........................8 58 2.3.2 Customer Bridges and VLANs...........................9 59 2.3.3 Provider Bridges and VLANs..........................11 61 3. A Prevalent Confusion..................................13 62 4. Shortest Path Bridges..................................16 63 5. Conclusions............................................18 65 6. IANA Considerations....................................19 66 7. Security Considerations................................19 67 8. Informative References.................................20 68 9. Normative References...................................21 70 1. Introduction 72 RBridges (Routing Bridges) provide transparent least-cost forwarding 73 in networks with arbitrary topology using the IETF TRILL (TRansparent 74 Interconnection of Lots of Links) standard [RFC6325] that builds on 75 IS-IS (Intermediate System to Intermediate System) routing [IS-IS] 76 [RFC1195] [RFC6326]. 78 This document describes a model of the layered relationship between 79 types of switching devices and how this correlates with peering for 80 some protocols. It also discusses the compatibility of RBridges with 81 end stations, Layer 3 routers, Layer 2 Customer Bridges, general 82 Layer 2 Provider Bridges, and Shortest Path Bridges. 84 1.1 Simplifying Assumptions 86 There tend to be many twists and turns in the real world so, to keep 87 this document to a reasonable size, the following assumptions are 88 made: 90 1. All physical links between devices are point-to-point Ethernet 91 connections [802] [802.3]. 93 2. Although there are a variety of Layer 3 routers, we will assume 94 pure IPv4/IPv6 [IS-IS] [RFC1195] routers. 96 3. It is assumed that the reader has some general understanding of 97 what Layer 3 routing and Layer 2 bridging [ITU-X.200] are, how 98 Ethernet works, and is familiar with [RFC6325]. 100 1.2 Terminology 102 The terminology and acronyms of [RFC6325] are used in this document 103 supplemented by the following definitions: 105 Bridge - as used in this document, a device that transparently 106 forwards frames using some version of the Spanning Tree 107 Protocol. 109 RBridge - Routing Bridge - a device generally conformant to the TRILL 110 base protocol standard [RFC6325] that transparently routes 111 frames. 113 SPB - Shortest Path Bridge - a device that is not only a Bridge as 114 defined above but that can also forward frames using bridging 115 mechanisms that are configured using the IS-IS protocol. 117 2. Layers and Peering 119 This section discusses a model of the layered relationship between 120 switching devices and how it affects peering for some protocols. 122 2.1 Basic Layers 124 Relative layering is essential to a clear understanding of the model 125 used by this document. While "Layer 2" and "Layer 3," in 126 approximately the OSI (Open System Interconnect) sense [ITU-X.200], 127 are commonly used terms, finer gradations are needed. For the most 128 part, only relative layer between two technologies matters, i.e., 129 which is at a "higher" or "lower" layer, not whether they are 130 precisely Layer 2 or Layer 3 or Layer 2.718281828459045 or Layer (2 + 131 7i). 133 To a general approximation, a device at Layer X sees all lower layer 134 devices, that is devices at Layer Y where X > Y, as transparent. In 135 other words, with the possible exception of some minor implementation 136 details, "layer violating" optimizations, or odd corner cases, two 137 devices at layer X don't particularly care if there are devices at 138 layer Y (or lower) between them. 140 On the other hand, to devices at Layer Y, all higher layer devices, 141 that is devices at Layer X where X > Y, act as boundaries. That is, 142 Layer X (or higher) devices bound a cloud of such Layer Y devices. 144 In the past, when things were simpler, one could generally understand 145 networks by distinguishing three layers as shown below: 147 +------------------+ 148 | User End Station | 149 +---+-------+------+ 150 | | 151 | +----+------+ 152 | | L3 Router | 153 | +-----+-----+ 154 | | 155 +--+--------+--+ 156 | Bridge | 157 +--------------+ 159 Figure 1. Simple Layers 161 The above diagram is meant to indicate that user end stations are at 162 the highest relative layer, Layer 3 routers are at an intermediate 163 layer, and bridges are at the lowest layer. The vertical lines mean 164 that you can have bridges and routers between and directly connected 165 to user end stations and bridges between and directly connected to 166 routers. 168 The two types of devices above bridges act as boundaries for a 169 bridging area. That is, user end stations and Layer 3 routers bound a 170 bridged LAN (Local Area Network). To Layer 3 routers, bridges are 171 approximately transparent but user end stations bound a routed area. 172 And, finally, both bridges and Layer 3 routers are pretty much 173 transparent to communications between user end stations. 175 2.2 Basic Peering 177 In the cases we are discussing, if two devices are at the same layer, 178 there is a significant protocol related to the device type in which 179 (1) they peer with each other, (2) devices at lower layers are 180 generally transparent to and do not interfere with such peering, and 181 (3) devices at a higher layer block the protocol and do not permit 182 peering through such higher layer devices. 184 For example, consider the diagram below 186 +----------+ +----------+ 187 | User End | peer | User End | 188 | Station |..................................| Station | 189 +--+----+--+ +--+---+---+ 190 / \ | | 191 | | / \ 192 +------+-+not +-+------+ peer +---------+ | | 193 | Router |peer| Router |.............| Router | | | 194 +--+-----+ +----+---+ +--+---+--+ / \ 195 | | / \ | | 196 | | / \ | | 197 +----+---+ +--+-----+peer+------+-+ +-+---+--+ +--+-----+ 198 | Bridge | not | Bridge |....| Bridge | not | Bridge | not | Bridge | 199 | | peer | +----+ | peer| | peer| | 200 +--------+ +--------+ +--------+ +--------+ +--------+ 202 Figure 2. Simple Layered Peering 204 As shown in this diagram, for the model in this document, devices at 205 the same level peer if and only if there are no higher layer devices 206 intervening. 208 How does this simple peering and layering work? It is generally 209 implemented, as described below, by the discarding or propagation of 210 frames based on their destination MAC address or their protocol type 211 (typically represented by an Ethertype). (There are additional 212 details not covered here for the sake of brevity such as registration 213 protocols, OAM, link level protocols, and IEEE 802.1 Two-Port MAC 214 Relays.) 216 2.2.1 Bridges 218 At the bridging and link layers there are reserved MAC multicast 219 addresses that are used, particularly the block from 220 01-80-C2-00-00-00 to 01-80-C2-00-00-0F [802.1Q]. From the beginning, 221 the specifications for bridges included a requirement to discard any 222 frame sent to an address in this block if the bridge did not 223 understand a protocol that used that address. 225 2.2.2 Layer 3 Routers 227 Layer 3 routers normally only recognize or forward frames in the 228 specific Layer 3 protocol(s) they are routing and those related to 229 the routing protocol itself. For example, an IPv4/IPv6 router will 230 recognize or forward only IPv4/IPv6 packets (including IPv4/IPv6 231 multicast if it handles such traffic) and Layer 3 routing control 232 frames such as those for Layer 3 IS-IS. 234 (IPv4/IPv6 multicast uses MAC multicast addresses 01-00-5E-00-00-00 235 to 01-00-5E-7F-FF-FF (IPv4) and 33-33-00-00-00-00 to 33-33-FF-FF-FF- 236 FF (IPv6) [RFC5342] and Layer 3 IS-IS routing uses MAC multicast 237 addresses 01-80-C2-00-00-14 and 01-80-C2-00-00-15 [IS-IS].) 239 Layer 3 routers normally do not route frames sent to any of the 240 bridging and link layer multicast addresses thus blocking bridge 241 peering and properly limiting the scope of link protocols. But 242 bridges forward IS-IS routing frames, IPv4 and IPv6 multicast frames 243 and, of course, unicast frames addressed to a router or end station. 244 Thus, of the devices we are discussing in this section, bridges can 245 transparently connect Layer 3 routers but Layer 3 routers block 246 bridging protocols and bound bridged LANs. 248 2.2.3 User End Stations 250 A pure user end station does not normally forward any frames 251 received. Thus it clearly meets the layering criterion of blocking 252 the peering of devices at all lower layers. Devices cannot peer if 253 they cannot exchange frames. (Of course, it is possible to have what 254 is thought of as a user end station also act like a bridge or router 255 or whatever, but then it isn't a pure user end station any more, is 256 it?) An example of a protocol by which end stations peer is TCP/IP. 258 But wait, you say, it is common for an end station to speak TCP/IP 259 with a bridge or a router, for SNMP or SSH or the like. Actually, the 260 best way to look at such interactions, and the way they are commonly 261 implemented, is that the TCP/IP interactions with a bridge or router 262 are with a virtual end station inside that bridge or router. To have 263 included this in Figure 2, we could draw an end station box at the 264 top for each bridge or router box and draw a link from the end 265 station down to the corresponding bridge or router. Thus the model of 266 end stations peering with each other using TCP/IP is pretty much 267 correct. 269 2.3 More Layers 271 The world is now more complex than that described above. There can be 272 quite a number of layers but, for the purposes of this document, the 273 five layers shown in the diagram below are adequate. 275 +--------------------------------+ 276 | User End Station | 277 +-+---+----+-------------------+-+ 278 | | | | 279 | | +--+---------------+ | 280 | | | L3 Router | | 281 | | +----+--------+--+-+ / 282 | | | | | / 283 | +-+------+------+ | \ / 284 | | RBridge | | X 285 | +--+-------+----+ | / \ 286 | | | | | \ 287 | | +-----+------+--+-+ \ 288 | | | Customer Bridge | | 289 | | +-------+---------+ | 290 | | | | 291 +-+----+---------+-------------+-+ 292 | Provider Bridge | 293 +--------------------------------+ 295 Figure 3. More Layers 297 As in Figure 1, the position of a box in this diagram corresponds to 298 the relative layer of the device type. And the more or less vertical 299 connections, which exist between every pair of types indicate that it 300 is workable to have devices of any type shown between and directly 301 connected to instances of any higher layer device shown. 303 The additions are a layer for RBridges (Routing Bridges), devices 304 that implement the IETF TRILL standard [RFC6325] [RFC6326], and the 305 splitting of the bridge layer into Customer Bridges and Provider 306 Bridges. RBridges are discussed in Section 2.3.1, Customer Bridges 307 and VLANs are discussed in Section 2.3.2, and Provider Bridges and 308 Provider VLANs are discussed in Section 2.3.3. 310 The transparency and bounding properties of layers, depending on 311 their relative position, are as before. Any of the four types of 312 devices shown layered above provider bridges will bound a provider 313 bridged LAN. To customer bridges, provider bridges are approximately 314 transparent, while RBridges, Layer 3 routers, and user end stations 315 will bound a customer bridged LAN. To RBridges, customer and provider 316 bridges are approximately transparent while Layer 3 routers and user 317 end stations bound an RBridge campus. To Layer 3 routers, bridging 318 and RBridges are all approximately transparent while user end 319 stations bound a routed area. And user end stations see all four 320 types of devices layered below user end stations as approximately 321 transparent. 323 2.3.1 RBridges (Routing Bridges) 325 RBridges are devices that implement the IETF TRILL standard. 326 (Approval of the TRILL base protocol [RFC6325] as an IETF standard 327 was announced 15 March 2010. Approval of the TRILL base protocol 328 specific IS-IS code points and formats [RFC6326] used as an IETF 329 standard was announced 9 February 2011.) 331 There have been endless arguments about whether RBridges are routers 332 or bridges. They are neither. They are a new type of device that is 333 demonstrably higher layer than a Layer 2 bridge, because they bound 334 bridging protocols such as spanning tree and stop bridges from 335 peering with each other, and demonstrably lower layer than Layer 3 336 routing because they are transparent to Layer 3 routing such as IS- 337 IS. So Layer 3 routers can peer through RBridges. 339 Nevertheless, when looked at in one way, RBridges are a type of 340 router because they implement a Hop Count, can do equal cost multi- 341 path, swap the outer link header on each RBridge hop, etc. But, 342 looked at another way, they appear to be a type of bridge because 343 they transparently deliver frames unmodified, can provide useful plug 344 and play service with zero configuration, honor frame customer VLANs 345 and priorities, and the like. 347 Arguing about what an RBridge "really" is like arguing about whether 348 a proton is really a wave or a particle. The fact that you can 349 perform experiments that provide very strong evidence that a proton 350 is a wave and other experiments that provide the same for it being a 351 particle does not make it a wave or just a particle. A proton is 352 really just a proton and has wave/particle duality. Just so, the fact 353 that you can present strong arguments that an RBridge is a router or 354 that an RBridge is a bridge does not make RBridges be one of those 355 types. RBridges are just RBridges, a new type of device at a new 356 layer. 358 Looking downward in our layering and peering model from RBridges, 359 RBridges as currently standardized do not forward frames sent to any 360 of the addresses in the basic 01-80-C2-00-00-00 to 01-80-C2-00-00-0F 361 bridging and link protocols block. Thus they bound and are layered 362 above bridging protocols and they appropriately scope link protocols. 363 In particular, this means they bound the various versions of the 364 spanning tree protocol. It was always a goal of TRILL to bound the 365 spanning tree protocol due to its poor performance in large networks 366 [RFC5556]. RBridge ports may still interact with bridging and/or 367 link protocols but those bridging and/or link protocols cannot 368 communicate through an RBridge between ports of that RBridge. 370 The TRILL protocol itself, including IS-IS control frames supporting 371 TRILL, uses unicast frames addressed to RBridge ports and multicast 372 frames sent to MAC addresses in the block from 01-80-C2-00-00-40 to 373 01-80-C2-00-00-4F. That block has been reserved exclusively for TRILL 374 use by the IEEE Registration Authority [RegAuth]. Since these 375 addresses have no special meaning to bridges, bridges forward them 376 normally and thus bridges are transparent to TRILL. 378 On the other hand, looking up our layering and peering model from 379 RBridges, because this block of TRILL multicast addresses has no 380 special meaning to Layer 3 routers, frames addressed to them are 381 discarded by Layer 3 routers, bounding the RBridge campus. Thus 382 RBridges are layered below Layer 3 routers. User end stations also 383 bound an RBridge campus, even if they are multi-port, because the 384 don't normally forward anything. 386 The default for a bridge is to forward frames it doesn't know 387 anything about. The default for a Layer 3 router is to discard frames 388 it doesn't know anything about. The default for a user end station is 389 to forward no frames. 391 2.3.2 Customer Bridges and VLANs 393 (The discussion of bridge types and VLANs in this and the immediately 394 following section may seem a bit tedious but stick with it, they are 395 of some relevance to the topic of this document.) 397 Bridging worked well enough that there was a desire to share bridged 398 LANs across multiple Layer 2 communities. To differentiate these 399 communities, a "tag" was specified to indicate the particular "VLAN" 400 (Virtual LAN) a frame was in. It consisted of the Ethertype 0x8100 401 followed by 2 bytes that include a 12-bit VLAN identifier. (For 402 brevity, the use of the remaining four bits in these two bytes will 403 be ignored.) This tag goes after the MAC destination and source 404 addresses and before the payload in Ethernet frames. It labels the 405 frame as being in the VLAN indicated. Use of other than a default 406 VLAN requires configuration. 408 Devices at different layers commonly treat VLANs differently but VLAN 409 treatment is a characteristic that can vary for different devices at 410 the same layer: 412 Bridges: Typically data frames sent between VLAN-aware bridges are 413 VLAN tagged but, since most end stations are not VLAN-aware, those 414 sent to/from end stations are usually not. The VLAN of an untagged 415 frame received by a VLAN aware bridge is typically determined by 416 the port on which it arrives but may be determined by the frame's 417 protocol or other factors. Unless a VLAN group or the like is 418 configured, bridges keep data in different VLANs isolated. Bridge 419 ports can be configured to filter on VLAN. 421 RBridges: Customer VLANs are treated by RBridges in a manner similar 422 to bridges. There are differences but they are not relevant to 423 this document. 425 Layer 3 Routers: Some Layer 3 routers are VLAN aware and some are 426 not. They typically treat data in different VLANs arriving at a 427 port as arriving on different virtual ports. In this case, the 428 data internal to the Layer 3 router has typically lost its VLAN 429 tagging and the router may not consider VLAN identity in deciding 430 which port or ports to output the packet on or whether to drop a 431 packet. If VLAN unaware, a Layer 3 router treats the VLAN tag as 432 part of the data; however, that data might not be routed because, 433 if the VLAN tag Ethertype was visible to the router, it would not 434 be recognized as a type of Layer 3 traffic to route. 436 User End Stations: User end stations are generally VLAN unaware and 437 also might treat a VLAN tag as part of the data; however, in that 438 case the data would not typically be processed because the VLAN 439 tag Ethertype would not be recognized as a type of traffic a VLAN 440 unaware end station is interested in. 442 When provider bridges and VLANs, discussed in Section 2.3.3, were 443 added to IEEE 802.1, the previously standardized bridges and VLANs, 444 discussed above, were retroactively called "customer" bridges and 445 "customer" VLANs to distinguish them from provider bridges and VLANs. 447 2.3.3 Provider Bridges and VLANs 449 "Provider" facilities derive from the concept of a carrier providing 450 Ethernet connectivity to customers. As a first approximation, they 451 would like to be transparent to the customer devices and traffic. So, 452 naturally, Provider Bridges are at a lower layer than customer 453 bridges. As a result, customer bridges and all higher layer devices 454 block peering between provider bridges and bound provider bridged 455 LANs. This is primarily accomplished by (1) provider bridges being 456 transparent to multicast address 01-80-C2-00-00-00, the address used 457 for Customer Bridge spanning tree peering and the like and (2) 458 provider facilities using the multicast address 01-80-C2-00-00-08, a 459 destination address customer bridges discard, for provider bridge 460 peering. 462 Of course, the bits don't know anything about business relationships 463 so "provider" facilities can be used inside the network of what a 464 carrier would consider a "customer". 466 Provider Bridges use VLANs but they use a different tag. The VLAN ID 467 field is the same size, 12 bits, but the Ethertype is different 468 (0x88A8) and they are called S-tags, for service tags, and customer 469 VLAN tags are now commonly called C-tags. 471 The first type of Provider Bridge specified use of S-tags and S-VLANs 472 to separate the traffic from different customers or services. If 473 there are already C-tags in place, this results in two nested VLAN 474 tags, an S-tag and then a C-tag relative to that S-tag. This is 475 colloquially known as "Q-in-Q". 477 To the extent that provider bridged LANs are supplying a service to 478 multiple different customers, provider facilities want to protect 479 themselves from customer behavior. They are typically more 480 configuration dependent than customer bridges. If customer facing 481 "edge" ports and internally connected ports are rigorously 482 configured, then the provider bridging should be relatively immune to 483 customers forging provider control frames or the like. In fact, such 484 frames need not have been "forged". It can easily be the case that 485 what is desired is a second order provider or the like, connecting 486 "customer" LANs that are already using the provider bridging 487 protocols. 489 "Q-in-Q", or nested VLAN tags, do not isolate provider bridges from 490 having to learn customer MAC addresses for transit traffic and use of 491 S-tags in the obvious way to isolate services limits the number of 492 services to 4K. Provider Backbone Bridges (PBBs) overcame these 493 limitations. PBBs use a "MAC-in-MAC" encapsulation so that customer 494 MAC addresses are nested inside PBB MAC addresses and those customer 495 MAC addresses need only be learned by edge PBBs. PBBs also use an 496 expanded tag, called an I-tag, that provides a 24-bit Service 497 Instance Identifier that can be used, in effect, as a VLAN. PBB can 498 make use of an outer VLAN tag that uses the same Ethertype as the S- 499 VLAN tag but is called a "B-VLAN tag" (backbone VLAN) and is used for 500 different purposes than the S-VLAN, purposes such as traffic 501 engineering. 503 Customer and provider bridging are both standardized by IEEE 802.1 504 and they are more entangled than one might expect for two different 505 layers. For example, there are "provider aware" customer bridges that 506 use S-tags on frames they submit to provider bridges to indicate the 507 service desired for the frame. However, generally, all layers above 508 customer bridging are S-tag ignorant; they treat an S-tag as just 509 part of the data 511 What happens when an RBridge gets a frame with an S-tag? This is a 512 trick question. At first glance, it seems pretty ugly. RBridges as 513 currently specified don't recognize S-tags and treat them as part of 514 the payload. An RBridge campus could ingress such a frame and egress 515 it, still S-tagged, from another port or ports of the same or some 516 other RBridge, perhaps causing some confusion. 518 But, wait a minute, how is this any different from what any provider- 519 ignorant customer bridge would do if it got a frame starting with an 520 S-tag? Or what a Layer 3 router might do? In fact, it is pretty much 521 the same. 523 Asking this trick question is like asking what happens if you divide 524 1 by 0. If you have gotten to a place where you are trying to divide 525 1 by 0, you've already made a mistake. Just so, if you have gotten to 526 the point where a frame intended for a provider device, as denoted by 527 an S-tag, is being sent to a customer device that does not understand 528 S-tags, particularly one that will likely forward it, such as a 529 customer bridge or an RBridge, your network is already misconfigured. 531 3. A Prevalent Confusion 533 When the TRILL Working Group was starting up in the IETF, IEEE 802.1 534 was working on its Provider Backbone Bridging (PBB) project. It 535 happens that both protocols do what is called "MAC-in-MAC", although 536 they do it for different but overlapping sets of reasons. These 537 reasons include, in the TRILL protocol, providing a place for a Hop 538 Count and options, and in the PBB amendment to the 802.1Q protocol, 539 providing a place for a 24-bit Service Instance Identifier and a new 540 priority field. (There are other differences.) In both cases original 541 destination and source MAC addresses are nested inside new 542 destination and source MAC address fields that are used inside the 543 RBridge campus (TRILL) or Provider Backbone Bridging region (PBB) and 544 these new address fields are discarded and the original addresses are 545 restored on exit from that campus or region. 547 The coincidence of TRILL and PBB both doing "MAC-in-MAC" has been a 548 source of endless confusion. For years, at essentially every TRILL 549 Working Group meeting someone would ask a question that made it clear 550 that, perhaps because TRILL and PBB both did "MAC-in-MAC", the 551 questioner believed that TRILL *must* be a provider protocol 552 appropriate for use by carriers connecting parts of customer 553 networks. But encapsulation, or a "MAC-in-MAC tag", or whatever you 554 want to call it, has nothing to do with the relative layer of a 555 protocol in the model discussed in this document. Based on that 556 model, RBridges, as currently standardized, are customer devices 557 above the customer bridge layer, while PBBs are provider devices at 558 the Provider Bridging layer. 560 For example, there is no problem connecting different parts of an 561 RBridge campus together through provider bridging. If you used 562 Provider Backbone Bridges for such provider bridging, as shown below, 563 you would have two nested levels of "MAC-in-MAC" inside the provider 564 bridged LAN for the RBridge campus TRILL Data frames. The provider 565 bridged LAN would look to TRILL like just a transparent part of a 566 TRILL level link between RBridges. 568 +---------+ +-----+ +-----+ +---------+ 569 ----| RBridge |-----| PBB |-------| PBB |-----| RBridge |---- 570 ^ +---------+ ^ +-----+ ^ +-----+ ^ +---------+ ^ 571 | | | | | 572 Note 1 Note 2 Note 3 Note 2 Note 1 574 Figure 4 576 Note 1: Zero or one level of MAC-in-MAC depending on the extent of 577 the RBridge campus. 578 Note 2: Inside an RBridge campus. One level of MAC-in-MAC. 579 Note 3: Inside Provider Back Bridged region that is in turn inside an 580 RBridge campus. Two levels of MAC-in-MAC. 582 The RBridges in the above diagram peer with each other through the 583 PBBs, becoming part of one RBridge campus that encompasses the 584 entirety of the provider bridge LAN that includes the PBBs shown. The 585 RBridges are part of the bounds of that provider bridged LAN. If 586 there are any other RBridges connected elsewhere to that provider 587 bridged LAN or to customer bridges connected to the that provider 588 bridged LAN, those RBridges will also be part of that RBridge campus. 590 On the other hand, if the nesting is reversed, the Provider Backbone 591 Bridges will, of course, be unable to peer through the higher layer 592 RBridges and the RBridges will bound any adjacent provider bridged 593 LAN(s). As a result, for traffic between end stations that are off 594 the left and right edges of the page in Figure 5 and assuming no 595 additional RBridges between the RBridges shown and those end 596 stations, there will be no more than one level of "MAC-in-MAC" 597 nesting as shown below. 599 +-----+ +---------+ +---------+ +-----+ 600 ----| PBB |-----| RBridge |-------| RBridge |-----| PBB |---- 601 ^ +-----+ ^ +---------+ ^ +---------+ ^ +-----+ ^ 602 | | | | | 603 Note 4 Note 5 Note 6 Note 5 Note 4 605 Figure 5 607 Note 4: Zero or one level of MAC-in-MAC depending on the extent of 608 the PBB region. 609 Note 5: Native frames with zero levels of MAC-in-MAC. 610 Note 6: Inside an RBridge campus. One level of MAC-in-MAC. 612 In Figure 5, because the PBBs cannot peer through the RBridges, they 613 are each part of a separate PBB region unless there is a path, not 614 shown, uniting them into a single PBB region. 616 You can shuffle the boxes around in the above diagrams in other ways, 617 but this does not reveal anything particularly interesting. For 618 example: 620 | | | | | | 621 +-----+ +---------+ +-----+ +---------+ 622 ----| PBB |-----| RBridge |-----| PBB |-----| RBridge |---- 623 +-----+ +---------+ +-----+ +---------+ 624 | | | | | | 626 Figure 6 628 Looking at Figure 6, it is certainly possible to confuse yourself, 629 perhaps if you try to think about the RBridges as simultaneously 630 being bridges and routers and apply some particular ideas about how 631 bridge and routers are "supposed" to work. But, if you apply the 632 simple principles given in this document, it is easy to see what 633 happens. From the RBridges' point of view, the PBBs are approximately 634 transparent, so all of the above diagram is part of a single RBridge 635 campus. From the PBBs' point of view, PBBs cannot peer through 636 RBridges so the RBridge facing PBB ports are PBB edge ports and the 637 PBBs shown are parts of one or two PBB regions depending on whether 638 there is a PBB path between them. (No such path is shown in Figure 639 6.) 641 For Figures 4 through 6 you could replace "PBB" and "RBridge" with 642 any relatively lower layer and relatively higher layer devices with 643 the same results as to regions and bounds. (The "MAC-in-MAC" comments 644 above would only apply to the extent that one or both of the devices 645 types were RBridges or the PBB type of Provider Bridge, the only 646 devices discussed that do "MAC-in-MAC".) The names of the regions 647 involved would change as follows, based on the vocabulary used in 648 this document: 650 Device Region Name in this document 651 --------------- ------------------------------ 652 End Station network 653 Layer 3 router routed area 654 RBridge campus 655 Customer Bridge bridged LAN 656 Provider Bridge provider bridged LAN 658 4. Shortest Path Bridges 660 Shortest Path Bridges (SPBs) are being specified by IEEE 802.1 661 through their [802.1aq] drafts (and in the applicable parts of the 662 IEEE virtual LAN bridging standard [802.1Q] that is to be amended by 663 802.1aq). ([802.1aq] is anticipated to become an IEEE Standard 664 sometime in 2012.) 666 Shortest Path Bridges have been somewhat of a moving target. They 667 started as a variety of Provider Bridge operating within the Provider 668 Bridging layer. Later, a type of SPB based on Provider Backbone 669 Bridging (PBB) was added. We will refer to these as PBB SPB and non- 670 PBB SPB. (The IEEE 802.1 abbreviation for PBB SPB is SPBM (where M 671 stands for MAC Mode) and for non-PBB SPB, it is SPBV (where V stands 672 for VID (VLAN ID) Mode.) Like previous Provider Backbone Bridges, 673 PBB SPBs only peer with each other over point-to-point links. 675 SPBs of either type can forward frames using bridging mechanisms that 676 are configured to provide least-cost paths. In the earliest versions 677 of SPB, this was done with many instances of spanning tree protocol 678 but later SPB drafts specify the use of the IS-IS protocol to 679 configure bridge-forwarding mechanisms. All versions of SPB so far 680 have also retained the ability to forward using variations of the 681 spanning tree protocol. Which method is used for a particular frame 682 is determined by that frame's VLAN and the SPB's configuration. 684 Earlier SPB drafts specified only the use of the standard multicast 685 addresses used for Layer 3 routing for SPB IS-IS. While it might seem 686 this would interfere with Layer 3 routing, as long as the ports for 687 PBB SPB are properly configured as to which are edge ports and which 688 are internal ports, then any Layer 3 IS-IS control frames transiting 689 a SPB region using the PBB type of SPB will be encapsulated and not 690 falsely recognized as SPB IS-IS control frames. However, this does 691 not help the non-PBB version of SPB; so more recent SPB drafts 692 include the proposed allocation of provider bridging layer multicast 693 addresses, presumably from within the bridging and link protocols 694 multicast address block (01-80-C2-00-00-00 to 01-80-C2-00-00-0F), for 695 use in non-PBB SPB IS-IS. 697 In addition, recent versions of the SPB draft have suggested that 698 customer bridging layer multicast addresses be assigned for optional 699 use in sending SPB IS-IS control frames, presumably also from the 700 bridging and link multicast address block, and suggest that there 701 should be a way to have what would appear to be customer bridging 702 layer SPBs. 704 (As discussed in Section 2.3.1, for TRILL IS-IS, RBridges as 705 currently standardized use multicast addresses dedicated to the TRILL 706 protocol. These addresses do not overlap with the Layer 3 IS-IS 707 multicast addresses or with any of the bridging and link protocols 708 multicast addresses.) 710 5. Conclusions 712 This document describes a model of switching device layers and 713 peering that the authors believe corresponds to common ideas of 714 layers for such devices. Based on this model, RBridges implementing 715 the IETF TRILL standard are compatible, well behaved devices that 716 cleanly fit into a specific relative layer of their own. 718 Also based on this device layer and peering model, the current IEEE 719 802.1 Shortest Path Bridging (SPB) draft appears to specify similarly 720 compatible and well behaved devices. SPBs were originally at the 721 Provider Bridging layer but their specification appears to be 722 undergoing extension so they may also optionally operate at the 723 Customer Bridging layer. 725 As required by the original TRILL WG Charter, a review by the IEEE 726 802.1 Working Group of the TRILL base protocol specification was 727 requested before its approval as an IETF standard. This resulted in 728 the IEEE 802.1 Liaison of 1 March 2009 to the IETF [Liaison] which 729 states in part: 731 "By inserting RBridges into a C-VLAN network a network structure 732 is created that is incompatible with current 802.1Q S-VLAN and B- 733 VLAN network architecture." 735 The IEEE 802.1 "S-VLAN and B-VLAN network architecture" is, as far as 736 the authors can tell, the layer at which Provider Bridges and 737 Provider Backbone Bridges operate. RBridges work just fine with 738 provider bridging in accordance with their relative layer (see Figure 739 3). Thus the authors believe that the IEEE 802.1 Working Group's 740 assertion of "incompatibility" is incorrect. And the IEEE 802.1 741 Working Group liaison's subsequent intimation that such mixed RBridge 742 and bridge networks would be, to use the word chosen by 802.1, 743 "broken", is equally incorrect. 745 RBridges as currently standardized and the latest Shortest Path 746 Bridging draft have similar goals when viewed at a high level of 747 abstraction. It is true that they achieve these goals through 748 different mechanisms and can be considered to be in competition; 749 however, the authors are unable to find any way in which they 750 currently conflict in a technical sense. Given that SPB is not yet an 751 IEEE standard and continues to evolve, whether this will be true when 752 802.1aq is finally approved as an IEEE standard (anticipated to occur 753 in 2012) cannot, unfortunately, be determined at this time. 755 6. IANA Considerations 757 This document requires no IANA actions. RFC Editor: Please delete 758 this section before publication. 760 7. Security Considerations 762 This is an informational document that does not consider security 763 questions or threats. 765 8. Informative References 767 [802] - IEEE 802, "IEEE Standard for Local and Metropolitan Area 768 Networks / Overview and Architecture", 802-2001, 6 December 769 2001. 771 [802.1aq] - IEEE 802.1, "Local and Metropolitan Area Networks / 772 Virtual Bridged Local Area Networks / Amendment 9: Shortest 773 Path Bridging", Draft P802.1aq/D4.0, 14 June 2011. 775 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 776 networks - Virtual Bridged Local Area Networks", IEEE Std 777 802.1Q-2011, May 2011. 779 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 780 Intermediate System Intra-Domain Routeing Exchange Protocol for 781 use in Conjunction with the Protocol for Providing the 782 Connectionless-mode Network Service (ISO 8473)", 2002. 784 [ITU-X.200] - ITU-T, "X.200 : Information technology - Open Systems 785 Interconnection - Basic Reference Model: The basic model", July 786 1994. 788 [Liaison] - IEEE 802.1, 789 or 790 , 1 March 2009. 793 [RegAuth] - IEEE Registration Authority, 794 http://standards.ieee.org/develop/regauth/index.html 796 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 797 dual environments", RFC 1195, December 1990. 799 [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol 800 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 801 2008. 803 [RFC5556] - Touch, J. and R. Perlman, "Transparent Interconnection of 804 Lots of Links (TRILL): Problem and Applicability Statement", 805 RFC 5556, May 2009. 807 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 808 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 809 July 2011. 811 [RFC6326] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, and A. 812 Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011. 814 9. Normative References 816 This is an empty normative references section to make the nits 817 checker happy. As an informational document, there are no normative 818 references. RFC Editor: please delete this section before 819 publication. 821 Authors' Addresses 823 Donald Eastlake, 3rd 824 Huawei Technologies (USA) 825 155 Beaver Street 826 Milford, MA 01757 USA 828 Tel: +1-508-333-2270 829 EMail: d3e3e3@gmail.com 831 Susan Hares 832 Huawei Technologies (USA) 833 2330 Central Expressway, 834 Santa Clara, CA 95050, USA 836 EMail: shares@huawei.com 838 Jon Hudson 839 Brocade 840 130 Holger Way 841 San Jose, CA 95134 USA 843 EMail: jon.hudson@gmail.com 845 Copyright, Disclaimer, and Additional IPR Provisions 847 Copyright (c) 2011 IETF Trust and the persons identified as the 848 document authors. All rights reserved. 850 This document is subject to BCP 78 and the IETF Trust's Legal 851 Provisions Relating to IETF Documents 852 (http://trustee.ietf.org/license-info) in effect on the date of 853 publication of this document. Please review these documents 854 carefully, as they describe your rights and restrictions with respect 855 to this document. Code Components extracted from this document must 856 include Simplified BSD License text as described in Section 4.e of 857 the Trust Legal Provisions and are provided without warranty as 858 described in the Simplified BSD License. The definitive version of 859 an IETF Document is that published by, or under the auspices of, the 860 IETF. Versions of IETF Documents that are published by third parties, 861 including those that are translated into other languages, should not 862 be considered to be definitive versions of IETF Documents. The 863 definitive version of these Legal Provisions is that published by, or 864 under the auspices of, the IETF. Versions of these Legal Provisions 865 that are published by third parties, including those that are 866 translated into other languages, should not be considered to be 867 definitive versions of these Legal Provisions. For the avoidance of 868 doubt, each Contributor to the IETF Standards Process licenses each 869 Contribution that he or she makes as part of the IETF Standards 870 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 871 language to the contrary, or terms, conditions or rights that differ 872 from or are inconsistent with the rights and licenses granted under 873 RFC 5378, shall have any effect and shall be null and void, whether 874 published or posted by such Contributor, or included with or in such 875 Contribution.