Internet DRAFT - draft-eastlake-rbridge-compatibility

draft-eastlake-rbridge-compatibility




Network Working Group                                    Donald Eastlake
INTERNET-DRAFT                                               Susan Hares
Intended status: Informational                                    Huawei
                                                              Jon Hudson
                                                                 Brocade
Expires: February 27, 2012                               August 28, 2011



        RBridge and Switching Device Layering and Compatibility
             <draft-eastlake-rbridge-compatibility-02.txt>


Abstract

   This document describes a layering and peering model for network
   switches and end stations. It also discusses, using this model, the
   compatibility of RBridges (Routing Bridges) with Layer 3 routers and
   various types of bridges including Shortest Path Bridges. RBridges
   are devices that implement the IETF TRILL (TRansparent
   Interconnection of Lots of Links) standard.


Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html









D. Eastlake, S. Hares, J. Hudson                                [Page 1]

INTERNET-DRAFT                                     RBridge Compatibility


Table of Contents

      1. Introduction............................................3
      1.1 Simplifying Assumptions................................3
      1.2 Terminology............................................3

      2. Layers and Peering......................................4
      2.1 Basic Layers...........................................4
      2.2 Basic Peering..........................................5
      2.2.1 Bridges..............................................6
      2.2.2 Layer 3 Routers......................................6
      2.2.3 User End Stations....................................6
      2.3 More Layers............................................7
      2.3.1 RBridges (Routing Bridges)...........................8
      2.3.2 Customer Bridges and VLANs...........................9
      2.3.3 Provider Bridges and VLANs..........................11

      3. A Prevalent Confusion..................................13
      4. Shortest Path Bridges..................................16
      5. Conclusions............................................18

      6. IANA Considerations....................................19
      7. Security Considerations................................19
      8. Informative References.................................20
      9. Normative References...................................21



























D. Eastlake, S. Hares, J. Hudson                                [Page 2]

INTERNET-DRAFT                                     RBridge Compatibility


1. Introduction

   RBridges (Routing Bridges) provide transparent least-cost forwarding
   in networks with arbitrary topology using the IETF TRILL (TRansparent
   Interconnection of Lots of Links) standard [RFC6325] that builds on
   IS-IS (Intermediate System to Intermediate System) routing [IS-IS]
   [RFC1195] [RFC6326].

   This document describes a model of the layered relationship between
   types of switching devices and how this correlates with peering for
   some protocols. It also discusses the compatibility of RBridges with
   end stations, Layer 3 routers, Layer 2 Customer Bridges, general
   Layer 2 Provider Bridges, and Shortest Path Bridges.



1.1 Simplifying Assumptions

   There tend to be many twists and turns in the real world so, to keep
   this document to a reasonable size, the following assumptions are
   made:

   1. All physical links between devices are point-to-point Ethernet
      connections [802] [802.3].

   2. Although there are a variety of Layer 3 routers, we will assume
      pure IPv4/IPv6 [IS-IS] [RFC1195] routers.

   3. It is assumed that the reader has some general understanding of
      what Layer 3 routing and Layer 2 bridging [ITU-X.200] are, how
      Ethernet works, and is familiar with [RFC6325].



1.2 Terminology

   The terminology and acronyms of [RFC6325] are used in this document
   supplemented by the following definitions:

   Bridge - as used in this document, a device that transparently
         forwards frames using some version of the Spanning Tree
         Protocol.

   RBridge - Routing Bridge - a device generally conformant to the TRILL
         base protocol standard [RFC6325] that transparently routes
         frames.

   SPB - Shortest Path Bridge - a device that is not only a Bridge as
         defined above but that can also forward frames using bridging
         mechanisms that are configured using the IS-IS protocol.


D. Eastlake, S. Hares, J. Hudson                                [Page 3]

INTERNET-DRAFT                                     RBridge Compatibility


2. Layers and Peering

   This section discusses a model of the layered relationship between
   switching devices and how it affects peering for some protocols.



2.1 Basic Layers

   Relative layering is essential to a clear understanding of the model
   used by this document. While "Layer 2" and "Layer 3," in
   approximately the OSI (Open System Interconnect) sense [ITU-X.200],
   are commonly used terms, finer gradations are needed. For the most
   part, only relative layer between two technologies matters, i.e.,
   which is at a "higher" or "lower" layer, not whether they are
   precisely Layer 2 or Layer 3 or Layer 2.718281828459045 or Layer (2 +
   7i).

   To a general approximation, a device at Layer X sees all lower layer
   devices, that is devices at Layer Y where X > Y, as transparent. In
   other words, with the possible exception of some minor implementation
   details, "layer violating" optimizations, or odd corner cases, two
   devices at layer X don't particularly care if there are devices at
   layer Y (or lower) between them.

   On the other hand, to devices at Layer Y, all higher layer devices,
   that is devices at Layer X where X > Y, act as boundaries. That is,
   Layer X (or higher) devices bound a cloud of such Layer Y devices.

   In the past, when things were simpler, one could generally understand
   networks by distinguishing three layers as shown below:

                         +------------------+
                         | User End Station |
                         +---+-------+------+
                             |       |
                             |  +----+------+
                             |  | L3 Router |
                             |  +-----+-----+
                             |        |
                          +--+--------+--+
                          |    Bridge    |
                          +--------------+

                          Figure 1. Simple Layers

   The above diagram is meant to indicate that user end stations are at
   the highest relative layer, Layer 3 routers are at an intermediate
   layer, and bridges are at the lowest layer. The vertical lines mean
   that you can have bridges and routers between and directly connected


D. Eastlake, S. Hares, J. Hudson                                [Page 4]

INTERNET-DRAFT                                     RBridge Compatibility


   to user end stations and bridges between and directly connected to
   routers.

   The two types of devices above bridges act as boundaries for a
   bridging area. That is, user end stations and Layer 3 routers bound a
   bridged LAN (Local Area Network). To Layer 3 routers, bridges are
   approximately transparent but user end stations bound a routed area.
   And, finally, both bridges and Layer 3 routers are pretty much
   transparent to communications between user end stations.



2.2 Basic Peering

   In the cases we are discussing, if two devices are at the same layer,
   there is a significant protocol related to the device type in which
   (1) they peer with each other, (2) devices at lower layers are
   generally transparent to and do not interfere with such peering, and
   (3) devices at a higher layer block the protocol and do not permit
   peering through such higher layer devices.

   For example, consider the diagram below

        +----------+                                  +----------+
        | User End |                 peer             | User End |
        |  Station |..................................|  Station |
        +--+----+--+                                  +--+---+---+
          /      \                                       |   |
         |        |                                     /     \
  +------+-+not +-+------+     peer    +---------+     |       |
  | Router |peer| Router |.............| Router  |     |       |
  +--+-----+    +----+---+             +--+---+--+    /         \
     |               |                   /     \     |           |
     |               |                  /       \    |           |
+----+---+        +--+-----+peer+------+-+     +-+---+--+     +--+-----+
| Bridge |  not   | Bridge |....| Bridge | not | Bridge | not | Bridge |
|        |  peer  |        +----+        | peer|        | peer|        |
+--------+        +--------+    +--------+     +--------+     +--------+

                     Figure 2. Simple Layered Peering

   As shown in this diagram, for the model in this document, devices at
   the same level peer if and only if there are no higher layer devices
   intervening.

   How does this simple peering and layering work? It is generally
   implemented, as described below, by the discarding or propagation of
   frames based on their destination MAC address or their protocol type
   (typically represented by an Ethertype). (There are additional
   details not covered here for the sake of brevity such as registration


D. Eastlake, S. Hares, J. Hudson                                [Page 5]

INTERNET-DRAFT                                     RBridge Compatibility


   protocols, OAM, link level protocols, and IEEE 802.1 Two-Port MAC
   Relays.)



2.2.1 Bridges

   At the bridging and link layers there are reserved MAC multicast
   addresses that are used, particularly the block from
   01-80-C2-00-00-00 to 01-80-C2-00-00-0F [802.1Q]. From the beginning,
   the specifications for bridges included a requirement to discard any
   frame sent to an address in this block if the bridge did not
   understand a protocol that used that address.



2.2.2 Layer 3 Routers

   Layer 3 routers normally only recognize or forward frames in the
   specific Layer 3 protocol(s) they are routing and those related to
   the routing protocol itself. For example, an IPv4/IPv6 router will
   recognize or forward only IPv4/IPv6 packets (including IPv4/IPv6
   multicast if it handles such traffic) and Layer 3 routing control
   frames such as those for Layer 3 IS-IS.

   (IPv4/IPv6 multicast uses MAC multicast addresses 01-00-5E-00-00-00
   to 01-00-5E-7F-FF-FF (IPv4) and 33-33-00-00-00-00 to 33-33-FF-FF-FF-
   FF (IPv6) [RFC5342] and Layer 3 IS-IS routing uses MAC multicast
   addresses 01-80-C2-00-00-14 and 01-80-C2-00-00-15 [IS-IS].)

   Layer 3 routers normally do not route frames sent to any of the
   bridging and link layer multicast addresses thus blocking bridge
   peering and properly limiting the scope of link protocols. But
   bridges forward IS-IS routing frames, IPv4 and IPv6 multicast frames
   and, of course, unicast frames addressed to a router or end station.
   Thus, of the devices we are discussing in this section, bridges can
   transparently connect Layer 3 routers but Layer 3 routers block
   bridging protocols and bound bridged LANs.



2.2.3 User End Stations

   A pure user end station does not normally forward any frames
   received. Thus it clearly meets the layering criterion of blocking
   the peering of devices at all lower layers. Devices cannot peer if
   they cannot exchange frames. (Of course, it is possible to have what
   is thought of as a user end station also act like a bridge or router
   or whatever, but then it isn't a pure user end station any more, is
   it?)  An example of a protocol by which end stations peer is TCP/IP.


D. Eastlake, S. Hares, J. Hudson                                [Page 6]

INTERNET-DRAFT                                     RBridge Compatibility


   But wait, you say, it is common for an end station to speak TCP/IP
   with a bridge or a router, for SNMP or SSH or the like. Actually, the
   best way to look at such interactions, and the way they are commonly
   implemented, is that the TCP/IP interactions with a bridge or router
   are with a virtual end station inside that bridge or router. To have
   included this in Figure 2, we could draw an end station box at the
   top for each bridge or router box and draw a link from the end
   station down to the corresponding bridge or router. Thus the model of
   end stations peering with each other using TCP/IP is pretty much
   correct.



2.3 More Layers

   The world is now more complex than that described above. There can be
   quite a number of layers but, for the purposes of this document, the
   five layers shown in the diagram below are adequate.

                   +--------------------------------+
                   |        User End Station        |
                   +-+---+----+-------------------+-+
                     |   |    |                   |
                     |   | +--+---------------+   |
                     |   | |    L3 Router     |   |
                     |   | +----+--------+--+-+  /
                     |   |      |        |  |   /
                     | +-+------+------+ |   \ /
                     | |    RBridge    | |    X
                     | +--+-------+----+ |   /  \
                     |    |       |      |  |    \
                     |    | +-----+------+--+-+   \
                     |    | | Customer Bridge |   |
                     |    | +-------+---------+   |
                     |    |         |             |
                   +-+----+---------+-------------+-+
                   |        Provider Bridge         |
                   +--------------------------------+

                           Figure 3. More Layers

   As in Figure 1, the position of a box in this diagram corresponds to
   the relative layer of the device type. And the more or less vertical
   connections, which exist between every pair of types indicate that it
   is workable to have devices of any type shown between and directly
   connected to instances of any higher layer device shown.

   The additions are a layer for RBridges (Routing Bridges), devices
   that implement the IETF TRILL standard [RFC6325] [RFC6326], and the
   splitting of the bridge layer into Customer Bridges and Provider


D. Eastlake, S. Hares, J. Hudson                                [Page 7]

INTERNET-DRAFT                                     RBridge Compatibility


   Bridges. RBridges are discussed in Section 2.3.1, Customer Bridges
   and VLANs are discussed in Section 2.3.2, and Provider Bridges and
   Provider VLANs are discussed in Section 2.3.3.

   The transparency and bounding properties of layers, depending on
   their relative position, are as before. Any of the four types of
   devices shown layered above provider bridges will bound a provider
   bridged LAN. To customer bridges, provider bridges are approximately
   transparent, while RBridges, Layer 3 routers, and user end stations
   will bound a customer bridged LAN. To RBridges, customer and provider
   bridges are approximately transparent while Layer 3 routers and user
   end stations bound an RBridge campus. To Layer 3 routers, bridging
   and RBridges are all approximately transparent while user end
   stations bound a routed area. And user end stations see all four
   types of devices layered below user end stations as approximately
   transparent.



2.3.1 RBridges (Routing Bridges)

   RBridges are devices that implement the IETF TRILL standard.
   (Approval of the TRILL base protocol [RFC6325] as an IETF standard
   was announced 15 March 2010. Approval of the TRILL base protocol
   specific IS-IS code points and formats [RFC6326] used as an IETF
   standard was announced 9 February 2011.)

   There have been endless arguments about whether RBridges are routers
   or bridges. They are neither. They are a new type of device that is
   demonstrably higher layer than a Layer 2 bridge, because they bound
   bridging protocols such as spanning tree and stop bridges from
   peering with each other, and demonstrably lower layer than Layer 3
   routing because they are transparent to Layer 3 routing such as IS-
   IS. So Layer 3 routers can peer through RBridges.

   Nevertheless, when looked at in one way, RBridges are a type of
   router because they implement a Hop Count, can do equal cost multi-
   path, swap the outer link header on each RBridge hop, etc. But,
   looked at another way, they appear to be a type of bridge because
   they transparently deliver frames unmodified, can provide useful plug
   and play service with zero configuration, honor frame customer VLANs
   and priorities, and the like.

   Arguing about what an RBridge "really" is like arguing about whether
   a proton is really a wave or a particle. The fact that you can
   perform experiments that provide very strong evidence that a proton
   is a wave and other experiments that provide the same for it being a
   particle does not make it a wave or just a particle. A proton is
   really just a proton and has wave/particle duality. Just so, the fact
   that you can present strong arguments that an RBridge is a router or


D. Eastlake, S. Hares, J. Hudson                                [Page 8]

INTERNET-DRAFT                                     RBridge Compatibility


   that an RBridge is a bridge does not make RBridges be one of those
   types. RBridges are just RBridges, a new type of device at a new
   layer.

   Looking downward in our layering and peering model from RBridges,
   RBridges as currently standardized do not forward frames sent to any
   of the addresses in the basic 01-80-C2-00-00-00 to 01-80-C2-00-00-0F
   bridging and link protocols block. Thus they bound and are layered
   above bridging protocols and they appropriately scope link protocols.
   In particular, this means they bound the various versions of the
   spanning tree protocol. It was always a goal of TRILL to bound the
   spanning tree protocol due to its poor performance in large networks
   [RFC5556].  RBridge ports may still interact with bridging and/or
   link protocols but those bridging and/or link protocols cannot
   communicate through an RBridge between ports of that RBridge.

   The TRILL protocol itself, including IS-IS control frames supporting
   TRILL, uses unicast frames addressed to RBridge ports and multicast
   frames sent to MAC addresses in the block from 01-80-C2-00-00-40 to
   01-80-C2-00-00-4F. That block has been reserved exclusively for TRILL
   use by the IEEE Registration Authority [RegAuth]. Since these
   addresses have no special meaning to bridges, bridges forward them
   normally and thus bridges are transparent to TRILL.

   On the other hand, looking up our layering and peering model from
   RBridges, because this block of TRILL multicast addresses has no
   special meaning to Layer 3 routers, frames addressed to them are
   discarded by Layer 3 routers, bounding the RBridge campus. Thus
   RBridges are layered below Layer 3 routers. User end stations also
   bound an RBridge campus, even if they are multi-port, because the
   don't normally forward anything.

   The default for a bridge is to forward frames it doesn't know
   anything about. The default for a Layer 3 router is to discard frames
   it doesn't know anything about. The default for a user end station is
   to forward no frames.



2.3.2 Customer Bridges and VLANs

   (The discussion of bridge types and VLANs in this and the immediately
   following section may seem a bit tedious but stick with it, they are
   of some relevance to the topic of this document.)

   Bridging worked well enough that there was a desire to share bridged
   LANs across multiple Layer 2 communities. To differentiate these
   communities, a "tag" was specified to indicate the particular "VLAN"
   (Virtual LAN) a frame was in. It consisted of the Ethertype 0x8100
   followed by 2 bytes that include a 12-bit VLAN identifier. (For


D. Eastlake, S. Hares, J. Hudson                                [Page 9]

INTERNET-DRAFT                                     RBridge Compatibility


   brevity, the use of the remaining four bits in these two bytes will
   be ignored.) This tag goes after the MAC destination and source
   addresses and before the payload in Ethernet frames. It labels the
   frame as being in the VLAN indicated. Use of other than a default
   VLAN requires configuration.

   Devices at different layers commonly treat VLANs differently but VLAN
   treatment is a characteristic that can vary for different devices at
   the same layer:

   Bridges: Typically data frames sent between VLAN-aware bridges are
      VLAN tagged but, since most end stations are not VLAN-aware, those
      sent to/from end stations are usually not. The VLAN of an untagged
      frame received by a VLAN aware bridge is typically determined by
      the port on which it arrives but may be determined by the frame's
      protocol or other factors. Unless a VLAN group or the like is
      configured, bridges keep data in different VLANs isolated. Bridge
      ports can be configured to filter on VLAN.

   RBridges: Customer VLANs are treated by RBridges in a manner similar
      to bridges. There are differences but they are not relevant to
      this document.

   Layer 3 Routers: Some Layer 3 routers are VLAN aware and some are
      not. They typically treat data in different VLANs arriving at a
      port as arriving on different virtual ports. In this case, the
      data internal to the Layer 3 router has typically lost its VLAN
      tagging and the router may not consider VLAN identity in deciding
      which port or ports to output the packet on or whether to drop a
      packet. If VLAN unaware, a Layer 3 router treats the VLAN tag as
      part of the data; however, that data might not be routed because,
      if the VLAN tag Ethertype was visible to the router, it would not
      be recognized as a type of Layer 3 traffic to route.

   User End Stations: User end stations are generally VLAN unaware and
      also might treat a VLAN tag as part of the data; however, in that
      case the data would not typically be processed because the VLAN
      tag Ethertype would not be recognized as a type of traffic a VLAN
      unaware end station is interested in.

   When provider bridges and VLANs, discussed in Section 2.3.3, were
   added to IEEE 802.1, the previously standardized bridges and VLANs,
   discussed above, were retroactively called "customer" bridges and
   "customer" VLANs to distinguish them from provider bridges and VLANs.








D. Eastlake, S. Hares, J. Hudson                               [Page 10]

INTERNET-DRAFT                                     RBridge Compatibility


2.3.3 Provider Bridges and VLANs

   "Provider" facilities derive from the concept of a carrier providing
   Ethernet connectivity to customers. As a first approximation, they
   would like to be transparent to the customer devices and traffic. So,
   naturally, Provider Bridges are at a lower layer than customer
   bridges. As a result, customer bridges and all higher layer devices
   block peering between provider bridges and bound provider bridged
   LANs. This is primarily accomplished by (1) provider bridges being
   transparent to multicast address 01-80-C2-00-00-00, the address used
   for Customer Bridge spanning tree peering and the like and (2)
   provider facilities using the multicast address 01-80-C2-00-00-08, a
   destination address customer bridges discard, for provider bridge
   peering.

   Of course, the bits don't know anything about business relationships
   so "provider" facilities can be used inside the network of what a
   carrier would consider a "customer".

   Provider Bridges use VLANs but they use a different tag. The VLAN ID
   field is the same size, 12 bits, but the Ethertype is different
   (0x88A8) and they are called S-tags, for service tags, and customer
   VLAN tags are now commonly called C-tags.

   The first type of Provider Bridge specified use of S-tags and S-VLANs
   to separate the traffic from different customers or services. If
   there are already C-tags in place, this results in two nested VLAN
   tags, an S-tag and then a C-tag relative to that S-tag. This is
   colloquially known as "Q-in-Q".

   To the extent that provider bridged LANs are supplying a service to
   multiple different customers, provider facilities want to protect
   themselves from customer behavior. They are typically more
   configuration dependent than customer bridges. If customer facing
   "edge" ports and internally connected ports are rigorously
   configured, then the provider bridging should be relatively immune to
   customers forging provider control frames or the like. In fact, such
   frames need not have been "forged". It can easily be the case that
   what is desired is a second order provider or the like, connecting
   "customer" LANs that are already using the provider bridging
   protocols.

   "Q-in-Q", or nested VLAN tags, do not isolate provider bridges from
   having to learn customer MAC addresses for transit traffic and use of
   S-tags in the obvious way to isolate services limits the number of
   services to 4K. Provider Backbone Bridges (PBBs) overcame these
   limitations. PBBs use a "MAC-in-MAC" encapsulation so that customer
   MAC addresses are nested inside PBB MAC addresses and those customer
   MAC addresses need only be learned by edge PBBs. PBBs also use an
   expanded tag, called an I-tag, that provides a 24-bit Service


D. Eastlake, S. Hares, J. Hudson                               [Page 11]

INTERNET-DRAFT                                     RBridge Compatibility


   Instance Identifier that can be used, in effect, as a VLAN. PBB can
   make use of an outer VLAN tag that uses the same Ethertype as the S-
   VLAN tag but is called a "B-VLAN tag" (backbone VLAN) and is used for
   different purposes than the S-VLAN, purposes such as traffic
   engineering.

   Customer and provider bridging are both standardized by IEEE 802.1
   and they are more entangled than one might expect for two different
   layers. For example, there are "provider aware" customer bridges that
   use S-tags on frames they submit to provider bridges to indicate the
   service desired for the frame. However, generally, all layers above
   customer bridging are S-tag ignorant; they treat an S-tag as just
   part of the data

   What happens when an RBridge gets a frame with an S-tag? This is a
   trick question. At first glance, it seems pretty ugly. RBridges as
   currently specified don't recognize S-tags and treat them as part of
   the payload. An RBridge campus could ingress such a frame and egress
   it, still S-tagged, from another port or ports of the same or some
   other RBridge, perhaps causing some confusion.

   But, wait a minute, how is this any different from what any provider-
   ignorant customer bridge would do if it got a frame starting with an
   S-tag? Or what a Layer 3 router might do? In fact, it is pretty much
   the same.

   Asking this trick question is like asking what happens if you divide
   1 by 0. If you have gotten to a place where you are trying to divide
   1 by 0, you've already made a mistake. Just so, if you have gotten to
   the point where a frame intended for a provider device, as denoted by
   an S-tag, is being sent to a customer device that does not understand
   S-tags, particularly one that will likely forward it, such as a
   customer bridge or an RBridge, your network is already misconfigured.



















D. Eastlake, S. Hares, J. Hudson                               [Page 12]

INTERNET-DRAFT                                     RBridge Compatibility


3. A Prevalent Confusion

   When the TRILL Working Group was starting up in the IETF, IEEE 802.1
   was working on its Provider Backbone Bridging (PBB) project. It
   happens that both protocols do what is called "MAC-in-MAC", although
   they do it for different but overlapping sets of reasons. These
   reasons include, in the TRILL protocol, providing a place for a Hop
   Count and options, and in the PBB amendment to the 802.1Q protocol,
   providing a place for a 24-bit Service Instance Identifier and a new
   priority field. (There are other differences.) In both cases original
   destination and source MAC addresses are nested inside new
   destination and source MAC address fields that are used inside the
   RBridge campus (TRILL) or Provider Backbone Bridging region (PBB) and
   these new address fields are discarded and the original addresses are
   restored on exit from that campus or region.

   The coincidence of TRILL and PBB both doing "MAC-in-MAC" has been a
   source of endless confusion. For years, at essentially every TRILL
   Working Group meeting someone would ask a question that made it clear
   that, perhaps because TRILL and PBB both did "MAC-in-MAC", the
   questioner believed that TRILL *must* be a provider protocol
   appropriate for use by carriers connecting parts of customer
   networks. But encapsulation, or a "MAC-in-MAC tag", or whatever you
   want to call it, has nothing to do with the relative layer of a
   protocol in the model discussed in this document. Based on that
   model, RBridges, as currently standardized, are customer devices
   above the customer bridge layer, while PBBs are provider devices at
   the Provider Bridging layer.

   For example, there is no problem connecting different parts of an
   RBridge campus together through provider bridging. If you used
   Provider Backbone Bridges for such provider bridging, as shown below,
   you would have two nested levels of "MAC-in-MAC" inside the provider
   bridged LAN for the RBridge campus TRILL Data frames. The provider
   bridged LAN would look to TRILL like just a transparent part of a
   TRILL level link between RBridges.

          +---------+     +-----+       +-----+     +---------+
      ----| RBridge |-----| PBB |-------| PBB |-----| RBridge |----
       ^  +---------+  ^  +-----+   ^   +-----+  ^  +---------+  ^
       |               |            |            |               |
      Note 1         Note 2       Note 3       Note 2        Note 1

                                   Figure 4

   Note 1: Zero or one level of MAC-in-MAC depending on the extent of
      the RBridge campus.
   Note 2: Inside an RBridge campus. One level of MAC-in-MAC.
   Note 3: Inside Provider Back Bridged region that is in turn inside an
      RBridge campus. Two levels of MAC-in-MAC.


D. Eastlake, S. Hares, J. Hudson                               [Page 13]

INTERNET-DRAFT                                     RBridge Compatibility


   The RBridges in the above diagram peer with each other through the
   PBBs, becoming part of one RBridge campus that encompasses the
   entirety of the provider bridge LAN that includes the PBBs shown. The
   RBridges are part of the bounds of that provider bridged LAN. If
   there are any other RBridges connected elsewhere to that provider
   bridged LAN or to customer bridges connected to the that provider
   bridged LAN, those RBridges will also be part of that RBridge campus.

   On the other hand, if the nesting is reversed, the Provider Backbone
   Bridges will, of course, be unable to peer through the higher layer
   RBridges and the RBridges will bound any adjacent provider bridged
   LAN(s). As a result, for traffic between end stations that are off
   the left and right edges of the page in Figure 5 and assuming no
   additional RBridges between the RBridges shown and those end
   stations, there will be no more than one level of "MAC-in-MAC"
   nesting as shown below.

          +-----+     +---------+       +---------+     +-----+
      ----| PBB |-----| RBridge |-------| RBridge |-----| PBB |----
       ^  +-----+  ^  +---------+   ^   +---------+  ^  +-----+  ^
       |           |                |                |           |
      Note 4     Note 5           Note 6           Note 5    Note 4

                                   Figure 5

   Note 4: Zero or one level of MAC-in-MAC depending on the extent of
      the PBB region.
   Note 5: Native frames with zero levels of MAC-in-MAC.
   Note 6: Inside an RBridge campus. One level of MAC-in-MAC.


   In Figure 5, because the PBBs cannot peer through the RBridges, they
   are each part of a separate PBB region unless there is a path, not
   shown, uniting them into a single PBB region.

   You can shuffle the boxes around in the above diagrams in other ways,
   but this does not reveal anything particularly interesting. For
   example:

              |           |   |           |           |   |
           +-----+     +---------+     +-----+     +---------+
       ----| PBB |-----| RBridge |-----| PBB |-----| RBridge |----
           +-----+     +---------+     +-----+     +---------+
              |           |   |           |           |   |

                                   Figure 6

   Looking at Figure 6, it is certainly possible to confuse yourself,
   perhaps if you try to think about the RBridges as simultaneously
   being bridges and routers and apply some particular ideas about how


D. Eastlake, S. Hares, J. Hudson                               [Page 14]

INTERNET-DRAFT                                     RBridge Compatibility


   bridge and routers are "supposed" to work. But, if you apply the
   simple principles given in this document, it is easy to see what
   happens. From the RBridges' point of view, the PBBs are approximately
   transparent, so all of the above diagram is part of a single RBridge
   campus. From the PBBs' point of view, PBBs cannot peer through
   RBridges so the RBridge facing PBB ports are PBB edge ports and the
   PBBs shown are parts of one or two PBB regions depending on whether
   there is a PBB path between them. (No such path is shown in Figure
   6.)

   For Figures 4 through 6 you could replace "PBB" and "RBridge" with
   any relatively lower layer and relatively higher layer devices with
   the same results as to regions and bounds. (The "MAC-in-MAC" comments
   above would only apply to the extent that one or both of the devices
   types were RBridges or the PBB type of Provider Bridge, the only
   devices discussed that do "MAC-in-MAC".) The names of the regions
   involved would change as follows, based on the vocabulary used in
   this document:


       Device             Region Name in this document
      ---------------    ------------------------------
       End Station        network
       Layer 3 router     routed area
       RBridge            campus
       Customer Bridge    bridged LAN
       Provider Bridge    provider bridged LAN

























D. Eastlake, S. Hares, J. Hudson                               [Page 15]

INTERNET-DRAFT                                     RBridge Compatibility


4. Shortest Path Bridges

   Shortest Path Bridges (SPBs) are being specified by IEEE 802.1
   through their [802.1aq] drafts (and in the applicable parts of the
   IEEE virtual LAN bridging standard [802.1Q] that is to be amended by
   802.1aq). ([802.1aq] is anticipated to become an IEEE Standard
   sometime in 2012.)

   Shortest Path Bridges have been somewhat of a moving target. They
   started as a variety of Provider Bridge operating within the Provider
   Bridging layer. Later, a type of SPB based on Provider Backbone
   Bridging (PBB) was added. We will refer to these as PBB SPB and non-
   PBB SPB. (The IEEE 802.1 abbreviation for PBB SPB is SPBM (where M
   stands for MAC Mode) and for non-PBB SPB, it is SPBV (where V stands
   for VID (VLAN ID) Mode.)  Like previous Provider Backbone Bridges,
   PBB SPBs only peer with each other over point-to-point links.

   SPBs of either type can forward frames using bridging mechanisms that
   are configured to provide least-cost paths. In the earliest versions
   of SPB, this was done with many instances of spanning tree protocol
   but later SPB drafts specify the use of the IS-IS protocol to
   configure bridge-forwarding mechanisms. All versions of SPB so far
   have also retained the ability to forward using variations of the
   spanning tree protocol. Which method is used for a particular frame
   is determined by that frame's VLAN and the SPB's configuration.

   Earlier SPB drafts specified only the use of the standard multicast
   addresses used for Layer 3 routing for SPB IS-IS. While it might seem
   this would interfere with Layer 3 routing, as long as the ports for
   PBB SPB are properly configured as to which are edge ports and which
   are internal ports, then any Layer 3 IS-IS control frames transiting
   a SPB region using the PBB type of SPB will be encapsulated and not
   falsely recognized as SPB IS-IS control frames. However, this does
   not help the non-PBB version of SPB; so more recent SPB drafts
   include the proposed allocation of provider bridging layer multicast
   addresses, presumably from within the bridging and link protocols
   multicast address block (01-80-C2-00-00-00 to 01-80-C2-00-00-0F), for
   use in non-PBB SPB IS-IS.

   In addition, recent versions of the SPB draft have suggested that
   customer bridging layer multicast addresses be assigned for optional
   use in sending SPB IS-IS control frames, presumably also from the
   bridging and link multicast address block, and suggest that there
   should be a way to have what would appear to be customer bridging
   layer SPBs.

   (As discussed in Section 2.3.1, for TRILL IS-IS, RBridges as
   currently standardized use multicast addresses dedicated to the TRILL
   protocol. These addresses do not overlap with the Layer 3 IS-IS
   multicast addresses or with any of the bridging and link protocols


D. Eastlake, S. Hares, J. Hudson                               [Page 16]

INTERNET-DRAFT                                     RBridge Compatibility


   multicast addresses.)



















































D. Eastlake, S. Hares, J. Hudson                               [Page 17]

INTERNET-DRAFT                                     RBridge Compatibility


5. Conclusions

   This document describes a model of switching device layers and
   peering that the authors believe corresponds to common ideas of
   layers for such devices. Based on this model, RBridges implementing
   the IETF TRILL standard are compatible, well behaved devices that
   cleanly fit into a specific relative layer of their own.

   Also based on this device layer and peering model, the current IEEE
   802.1 Shortest Path Bridging (SPB) draft appears to specify similarly
   compatible and well behaved devices. SPBs were originally at the
   Provider Bridging layer but their specification appears to be
   undergoing extension so they may also optionally operate at the
   Customer Bridging layer.

   As required by the original TRILL WG Charter, a review by the IEEE
   802.1 Working Group of the TRILL base protocol specification was
   requested before its approval as an IETF standard. This resulted in
   the IEEE 802.1 Liaison of 1 March 2009 to the IETF [Liaison] which
   states in part:

      "By inserting RBridges into a C-VLAN network a network structure
      is created that is incompatible with current 802.1Q S-VLAN and B-
      VLAN network architecture."

   The IEEE 802.1 "S-VLAN and B-VLAN network architecture" is, as far as
   the authors can tell, the layer at which Provider Bridges and
   Provider Backbone Bridges operate. RBridges work just fine with
   provider bridging in accordance with their relative layer (see Figure
   3). Thus the authors believe that the IEEE 802.1 Working Group's
   assertion of "incompatibility" is incorrect. And the IEEE 802.1
   Working Group liaison's subsequent intimation that such mixed RBridge
   and bridge networks would be, to use the word chosen by 802.1,
   "broken", is equally incorrect.

   RBridges as currently standardized and the latest Shortest Path
   Bridging draft have similar goals when viewed at a high level of
   abstraction. It is true that they achieve these goals through
   different mechanisms and can be considered to be in competition;
   however, the authors are unable to find any way in which they
   currently conflict in a technical sense. Given that SPB is not yet an
   IEEE standard and continues to evolve, whether this will be true when
   802.1aq is finally approved as an IEEE standard (anticipated to occur
   in 2012) cannot, unfortunately, be determined at this time.








D. Eastlake, S. Hares, J. Hudson                               [Page 18]

INTERNET-DRAFT                                     RBridge Compatibility


6. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please delete
   this section before publication.



7. Security Considerations

   This is an informational document that does not consider security
   questions or threats.









































D. Eastlake, S. Hares, J. Hudson                               [Page 19]

INTERNET-DRAFT                                     RBridge Compatibility


8. Informative References

   [802] - IEEE 802, "IEEE Standard for Local and Metropolitan Area
         Networks / Overview and Architecture", 802-2001, 6 December
         2001.

   [802.1aq] - IEEE 802.1, "Local and Metropolitan Area Networks /
         Virtual Bridged Local Area Networks / Amendment 9: Shortest
         Path Bridging", Draft P802.1aq/D4.0, 14 June 2011.

   [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
         networks - Virtual Bridged Local Area Networks", IEEE Std
         802.1Q-2011, May 2011.

   [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
         Intermediate System Intra-Domain Routeing Exchange Protocol for
         use in Conjunction with the Protocol for Providing the
         Connectionless-mode Network Service (ISO 8473)", 2002.

   [ITU-X.200] - ITU-T, "X.200 : Information technology - Open Systems
         Interconnection - Basic Reference Model: The basic model", July
         1994.

   [Liaison] - IEEE 802.1,
         <https://datatracker.ietf.org/documents/LIAISON/file710.pdf> or
         <http://www.ieee802.org/1/files/public/docs2009/liaison-to-
         trill-wg-0309.pdf>, 1 March 2009.

   [RegAuth] - IEEE Registration Authority,
         http://standards.ieee.org/develop/regauth/index.html

   [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
         dual environments", RFC 1195, December 1990.

   [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
         Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
         2008.

   [RFC5556] - Touch, J. and R. Perlman, "Transparent Interconnection of
         Lots of Links (TRILL): Problem and Applicability Statement",
         RFC 5556, May 2009.

   [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
         July 2011.

   [RFC6326] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, and A.
         Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.




D. Eastlake, S. Hares, J. Hudson                               [Page 20]

INTERNET-DRAFT                                     RBridge Compatibility


9. Normative References

   This is an empty normative references section to make the nits
   checker happy. As an informational document, there are no normative
   references. RFC Editor: please delete this section before
   publication.














































D. Eastlake, S. Hares, J. Hudson                               [Page 21]

INTERNET-DRAFT                                     RBridge Compatibility


Authors' Addresses

   Donald Eastlake, 3rd
   Huawei Technologies (USA)
   155 Beaver Street
   Milford, MA 01757 USA

   Tel:   +1-508-333-2270
   EMail: d3e3e3@gmail.com


   Susan Hares
   Huawei Technologies (USA)
   2330 Central Expressway,
   Santa Clara, CA 95050, USA

   EMail: shares@huawei.com


   Jon Hudson
   Brocade
   130 Holger Way
   San Jose, CA 95134 USA

   EMail: jon.hudson@gmail.com



























D. Eastlake, S. Hares, J. Hudson                               [Page 22]

INTERNET-DRAFT                                     RBridge Compatibility


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.





















D. Eastlake, S. Hares, J. Hudson                               [Page 23]