TRILL: Fine-Grained Labeling
draft-ietf-trill-fine-labeling-02

TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                              Mingui Zhang
Intended status: Proposed Standard                                Huawei
Updates: 6325, 6327                                       Puneet Agarwal
                                                                Broadcom
                                                           Radia Perlman
                                                              Intel Labs
                                                             Dinesh Dutt
                                                        Cumulus Networks
Expires: April 20, 2012                                 October 21, 2012

                      TRILL: Fine-Grained Labeling
                <draft-ietf-trill-fine-labeling-02.txt>

Abstract

   The IETF has standardized TRILL (TRansparent Interconnection of Lots
   of Links), a protocol for least cost transparent frame routing in
   multi-hop networks with arbitrary topologies and link technologies,
   using link-state routing and encapsulation with a hop count.

   The TRILL base protocol standard supports labeling of TRILL data with
   up to 4K IDs. However, there are applications that require more fine-
   grained labeling of data. This document updates RFC 6325 and 6327 by
   specifying extensions to the TRILL base protocol to safely accomplish
   this.

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, et al                                              [Page 1]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

Table of Contents

      1. Introduction............................................3
      1.1 Terminology............................................3
      1.2 Contributors...........................................4

      2. Fine-Grained Labeling...................................5
      2.1 Goals..................................................5
      2.2 Base Protocol TRILL Data Labeling......................6
      2.3 Fine-Grained Labeling (FGL)............................7

      3. Campus Wide VL versus FGL Semantic Differences..........9
      4. Interaction with VL TRILL Switches.....................10

      5. Fine-Grained Labeling Details..........................12
      5.1 Ingress Processing....................................12
      5.2 Transit Processing....................................12
      5.2.1 Unicast Transit Processing..........................13
      5.2.2 Multi-Destination Transit Processing................13
      5.3 Egress Processing.....................................13
      5.4 Appointed Forwarders and the DRB......................14
      5.5 Address Learning......................................14
      5.6 ESADI Extensions......................................14

      6. IS-IS Extensions.......................................16
      7. Comparison to Goals....................................17

      8. Allocation Considerations..............................18
      8.1 IEEE Allocation Considerations........................18
      8.2 IANA Considerations...................................18

      9. Security Considerations................................19

      Acknowledgements..........................................19
      Normative References......................................20
      Informative References....................................20
      Change History............................................21

D. Eastlake, et al                                              [Page 2]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

1. Introduction

   The IETF has standardized the TRILL (TRansparent Interconnection of
   Lots of Links) protocol [RFC6325]. TRILL switches provide a solution
   for least cost transparent routing in multi-hop networks with
   arbitrary topologies and link technologies, using [IS-IS] [RFC6165]
   [RFC6326bis] link-state routing and encapsulation with a hop count.
   They address the problems outlined in [RFC5556]. TRILL switches are
   sometimes called RBridges (Routing Bridges).

   The TRILL base protocol standard supports labeling of TRILL data with
   up to 4K IDs. However, there are applications that require more fine-
   grained labeling of data for configurable isolation based on
   different tenants, service instances, or the like. This document
   updates [RFC6325] and [RFC6327] by specifying extensions to the TRILL
   base protocol to safely accomplish this.

   Familiarity with [RFC6325] and [RFC6326bis] is assumed in this
   document.

1.1 Terminology

   The terminology and acronyms of [RFC6325] are used in this document
   with the additions listed below.

      DEI - Drop Eligibility Indicator [802.1Q]

      FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-
            Grained Label

      FGL RBridge - A TRILL switch that support both FGL and VL

      Edge RBridge - A TRILL switch announcing VL or FGL connectivity in
            its LSP

      TRILL Switch - Alternative name for an RBridge

      VL - VLAN Labeling or VLAN Labeled or VLAN Label

      VL RBridge - A TRILL switch that supports VL but does not support
            FGL

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

D. Eastlake, et al                                              [Page 3]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

1.2 Contributors

   Thanks for the contributions of the following:

      Tissa Senevirathne

D. Eastlake, et al                                              [Page 4]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

2. Fine-Grained Labeling

   The essence of Fine-Grained Labeling (FGL) is that (a) when TRILL
   Data frames are ingressed or created they may incorporate a label
   from a set consisting of significantly more than 4K labels, (b) TRILL
   switch (RBridge) ports can be labeled with a set of such labels, and
   (c) an FGL TRILL Data frame cannot be egressed through an RBridge
   port unless its fine-grained label (FGL) matches one of the labels of
   the port.

   Section 2.1 lists FGL goals.  Section 2.2 briefly outlines the more
   coarse TRILL base protocol standard [RFC6325] data labeling. And
   Section 2.3 outlines a method of FGL of TRILL Data frames.

2.1 Goals

   There are several goals that should be met by FGL in TRILL.  They are
   briefly described in the list below in approximate order by priority
   with the most important first.

   1. Fine-Grained

      Some networks have a large number of entities that need
      configurable isolation, whether those entities are independent
      customers, applications, or branches of a single endeavor or some
      combination of these or other entities. The labeling supported by
      [RFC6325] provides for only ( 2**12 - 2 ) valid identifiers or
      labels. A substantially larger number is required.

   2. Silicon Considerations

      Fine-grained labeling (FGL) should, to the extent practical, use
      existing features, processing, and fields that are already
      supported in at least some fast path silicon implementations that
      currently support the TRILL base protocol.

   3. Base RBridge Compatibility

      To support some incremental conversion scenarios, it is desirable
      that not all RBridges in a campus using FGL be required to be FGL
      aware. That is, it is desirable that RBridges not implementing the
      FGL feature and performing at least the transit forwarding
      function can usefully process TRILL Data frames that incorporate
      FGL.

D. Eastlake, et al                                              [Page 5]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

   4. Alternate Priority

      It would be desirable for an ingress TRILL Switch to be able to
      assign a different priority to an FGL TRILL Data frame for its
      ingress-to-egress propagation from the priority of the original
      native frame. The original priority should be restored on egress.

2.2 Base Protocol TRILL Data Labeling

   This section provides a brief review of the [RFC6325] TRILL Data
   frame internal VL Labeling and changes the description of the TRILL
   Header by moving its end point. This description change does not
   involve any change in the bits on the wire or in the behavior of
   existing [RFC6325] RBridges.

   Currently TRILL Data frames have the VL structure shown below:

               +-------------------------------------------+
               | Link Header (depends on link technology)  |
               | (if link is an Ethernet link the link     |
               |  header may include an Outer.VLAN tag)    |
               +-------------------------------------------+
               | TRILL Header                              |
               | +---------------------------------------+ |
               | |    Initial Fields and Options         | |
               | +---------------------------------------+ |
               | |         Inner.MacDA         | (6 bytes) |
               | +-----------------------------+           |
               | |         Inner.MacSA         | (6 bytes) |
               | +-----------------------+-----+           |
               | | Ethertype 0x8100      |       (2 bytes) |
               | +-----------------------+                 |
               | | Inner.VLAN Label      |       (2 bytes) |
               | +-----------------------+                 |
               +-------------------------------------------+
               |               Native Payload              |
               +-------------------------------------------+
               | Link Trailer (depends on link technology) |
               +-------------------------------------------+

                       Figure 1. TRILL Data with VL

   In the base protocol as specified in [RFC6325] the 0x8100 value is
   always present and is followed by the Inner.VLAN field which includes
   the 12-bit VL.

D. Eastlake, et al                                              [Page 6]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

2.3 Fine-Grained Labeling (FGL)

   FGL expands the data label available under the TRILL base protocol
   standard to a fine-grained label (FGL) with a 12-bit high order part
   and a 12-bit low order part. In this document, FGLs are usually
   denoted as "(X.Y)" where X is the high order part and Y is the low
   order part of the FGL. The FGL information appears in the TRILL
   Header as shown below.

               +-------------------------------------------+
               | Link Header (depends on link technology)  |
               | (if link is an Ethernet link the link     |
               |  header may include an Outer.VLAN tag)    |
               +-------------------------------------------+
               | TRILL Header                              |
               | +---------------------------------------+ |
               | |    Initial Fields and Options         | |
               | +---------------------------------------+ |
               | |         Inner.MacDA         | (6 bytes) |
               | +-----------------------------+           |
               | |         Inner.MacSA         | (6 bytes) |
               | +-----------------------+-----+           |
               | | Ethertype 0x893B      |       (2 bytes) |
               | +-----------------------+                 |
               | | Inner.Label High Part |       (2 bytes) |
               | +-----------------------+                 |
               | | Ethertype 0x893B      |       (2 bytes) |
               | +-----------------------+                 |
               | | Inner.Label Low Part  |       (2 bytes) |
               | +-----------------------+                 |
               +-------------------------------------------+
               |               Native Payload              |
               +-------------------------------------------+
               | Link Trailer (depends on link technology) |
               +-------------------------------------------+

                       Figure 2. TRILL Data with FGL

   For FGL frames, the inner MAC address fields are followed by the FGL
   information using 0x893B.

   The two bytes following each 0x893B have, in their low order 12 bits,
   fine-grained label information. The upper 4 bits of those two bytes
   are used for a 3-bit priority field and one drop eligibility
   indicator (DEI) bit.

   The priority field of the Inner.Label High Part is the priority used
   for frame transport across the TRILL campus from ingress to egress.
   The label bits in the Inner.Label High Part are the high order part
   of the FGL and those bits in the Inner.Label Low Part are the low

D. Eastlake, et al                                              [Page 7]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

   order part of the FGL.

   The appropriate FGL value for an ingressed native frame is determined
   by the ingress RBridge port as specified in Section 5.1.  Ports of
   TRILL switches supporting FGL also have capabilities to transmit
   frames being forwarded or egressed as untagged or VL as specified in
   Section 5.3.

D. Eastlake, et al                                              [Page 8]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

3. Campus Wide VL versus FGL Semantic Differences

   There are differences between the semantics across a TRILL campus for
   VL and FGL labeled TRILL Data frames.

   With VL, data label IDs have the same meaning throughout the campus
   and are from the same label space as the VLAN IDs used on Ethernet
   links to end stations.

   With TRILL FGL, many things remain the same. Ports of FGL TRILL
   switches, up through the usual VLAN and priority processing, act as
   they do for VL TRILL switches: Ethernet links between FGL TRILL
   switches still have only C-VLAN tagging on them and TRILL switch
   ports provide a VLAN ID for an incoming frame and accepts a VLAN ID
   for a frame being queued for output. Appointed Forwarders [RFC6439]
   on a link are still appointed for a C-VLAN. The Designated VLAN for
   an Ethernet link is still a C-VLAN.

   The larger FGL space is a different space from the VL data label
   space. For ports configured for FGL, the C-VLAN on an ingressed
   native frame is mapped to the FGL data label space with a potentially
   different mapping for each port. A similar FGL to C-VLAN mapping
   occurs per port on egress. Thus, for ports configured for FGL, the
   native frame C-VLAN on one link corresponding to an FGL can be
   different from the native frame C-VLAN corresponding to that same FGL
   on a different link elsewhere in the campus or even a different link
   attached to the same RBridge. The FGL label space is flat and does
   not hierarchically encode any particular number of native frame C-
   VLAN bits or the like. FGLs in TRILL Data frames appear only inside
   the TRILL Header after the inner MAC addresses. They are only seen by
   TRILL aware devices.

   FGL RBridge ports can be configured for FGL or VL with VL being the
   default. As with a base protocol [RFC6325] RBridge, an unconfigured
   FGL TRILL switch port reports an untagged frame it receives as being
   in VLAN 1.

D. Eastlake, et al                                              [Page 9]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

4. Interaction with VL TRILL Switches

   It is not possible for VL TRILL switches to handle FGL frames even if
   the VL TRILL switch is only acting in the transit capacity. This is
   because VL frames are required to have 0x8100 at the beginning of the
   data label where FGL TRILL switches have 0x893B. VL-only TRILL
   switches conformant to [RFC6325] should discard frames with this new
   value after the inner MAC addresses and, if they do not discard such
   frames, they will be confused (see Section 9 below).

   If there are FGL TRILL switches in a campus, it is assumed that the
   intent is for all TRILL switches in that campus to support FGL. Any
   VL TRILL switches present are isolated by FGL TRILL switches as
   follows: FGL RBridges will report their FGL capability in LSPs. Thus
   FGL TRILL switches (and any management system with access to the link
   state database) will be able to detect the existence of TRILL
   switches in the campus that do not support FGL. If any such VL TRILL
   switches are present on a link then, although all other aspects of
   the adjacency machinery work as normal [RFC6327], any FGL TRILL
   switches on the link will not create a pseudo node for the link if
   they are DRB and do not announce any adjacencies they have on the
   link. As a result, although adjacencies between two or more VL
   RBridge ports on the link could become part of the campus topology
   and pass TRILL Data frames, no adjacency from an FGL RBridge port to
   a VL RBridge port or to a pseudonode will be reported for such a
   mixed FGL/VL link. Since an adjacency must be reported up by both
   ends before it becomes part of the campus topology, even though
   adjacencies to an FGL RBridge might be reported by a VL RBridge, no
   TRILL Data can flow between an FGL RBridge port and a VL RBridge
   port.

   The usual DRB election operates on a link with mixed FLG and VL
   ports. If an FGL RBridge port is DRB, it MUST handle all native
   traffic or appoint only other FGL ports as forwarder for one or more
   VLANs, so that all end stations will get service to the FGL campus.
   If a VL RBridge port is DRB, it will not understand that FGL RBridge
   ports are different. To the extent that a VL DRB handles native
   frames or appoints other VL ports on a link to handle native frames
   for one or more VLANs, the end stations sending and receiving those
   native frames will be isolated from the FGL campus. To the extent
   that a VL DRB happens to appoint an FGL port as Appointed Forwarder
   for one or more VLANs, the end stations sending and receiving native
   frames in those VLANs will get service to the FGL campus. This
   somewhat odd corner case behavior is considered acceptable because it
   is assumed that VL TRILL switches in an FGL campus are infrequent
   misconfigurations.

   For links configured as point-to-point, if the TRILL switches at each
   end are both VL or both FGL, a bi-directional adjacency can be formed
   by the usual mechanisms. If one is VL and one is FGL but the point-

D. Eastlake, et al                                             [Page 10]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

   to-point link is otherwise correctly configured, the VL TRILL switch
   will report an adjacency but the LFG one will not. As a result, the
   link will not become part of the topology and TRILL Data cannot flow
   over the link, isolating the VL TRILL switch.

D. Eastlake, et al                                             [Page 11]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

5. Fine-Grained Labeling Details

   This section specifies ingress, transit, egress, and other processing
   of TRILL Data frames with regard to FGLs. A transit or egress FGL
   TRILL switch determines that a TRILL Data frame is FGL by detecting
   that the inner MAC address fields are followed by 0x893B.

5.1 Ingress Processing

   An FGL RBridge MAY be configured, on one or more ports, to ingress
   native frames as FGL. Any ports not so configured that accepts a
   native frame perform the previously specified VL ingress processing
   on native frames [RFC6325].  There is no change in Appointed
   Forwarder logic (see Section 5.4).

   FGL TRILL switches MUST support configurable per port mapping from
   the VL of a native frame, as reported by the ingress port, to an FGL.
   FGL TRILL switches MAY support other methods to determine the FGL of
   an incoming native frame, such as based on the protocol of the native
   frame or local knowledge.

   The FGL ingress process MUST place the priority and DEI associated
   with an ingressed native frame in upper 4 bits of the Inner.Label Low
   Order part. It SHOULD also associate a possibly different mapped
   priority and DEI with an ingressed frame. The mapped priority is
   placed in the Inner.Label High Part. If such mapping is not supported
   then the original priority and DEI MUST be placed in the Inner.Label
   High Part.

   An FGL ingress RBridge MAY serially TRILL unicast a multi-destination
   TRILL Data frame to the relevant egress TRILL switches after
   encapsulating it as a TRILL known unicast data frame (M=0) and SHOULD
   unicast such a multi-destination TRILL Data frame if there is only
   one relevant egress FGL RBridge. For FGL RBridges, this permits
   serial unicast of multi-destination frames by the ingress as an
   alternative to the use of a distribution tree. The relevant egress
   TRILL switches are determined by starting with those announcing
   connectivity to the frame's (X.Y) label. That set SHOULD be further
   filtered based on multicast listener and multicast router
   connectivity if the native frame was a multicast frame.

5.2 Transit Processing

   TRILL Data frame transit processing is fairly straightforward as
   described in Section 5.2.1 for known unicast TRILL Data frames and in
   Section 5.2.2 for multi-destination TRILL Data frames.

D. Eastlake, et al                                             [Page 12]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

5.2.1 Unicast Transit Processing

   There is very little change in TRILL Data frame unicast transit
   processing. A transit TRILL switch forwards any unicast TRILL Data
   frame to the next hop towards the egress RBridge as specified in the
   TRILL Header. All transit TRILL switches, whether VL or FGL, MUST
   take the priority and DEI used to forward a frame from the Inner.VLAN
   label or the FGL Inner.Label High Part. These bits are in the same
   place in the frame.

5.2.2 Multi-Destination Transit Processing

   Multi-destination TRILL Data frames are forwarded on a distribution
   tree selected by the ingress TRILL switch except that an FGL ingress
   RBridge MAY choose to TRILL unicast such a frame to all relevant
   egress TRILL switches.  The distribution trees do not distinguish
   between FGL and VL multi-destination frames except, possibly, in
   pruning behavior. All distribution trees are calculated as provided
   for in the TRILL base protocol standard [RFC6325]. There is no change
   in the Reverse Path Forwarding Check.

   An FGL RBridge, say RB1, having an FGL multi-destination frame for
   label (X.Y) to forward on a distribution tree, SHOULD prune that tree
   based on whether there are any edge TRILL switches on a tree branch
   that are advertising connectivity to label (X.Y). In addition, RB1
   SHOULD prune multicast frames based on reported multicast listener
   and multicast router attachment in (X.Y).

   Pruning is an optimization. If a transit TRILL switch does less
   pruning than it could, there may be greater link utilization than
   strictly necessary but the campus will still operate correctly. For
   example, a transit TRILL switch could prune based on only part of the
   FGL such as only the High Part or only the Low Part.

5.3 Egress Processing

   Egress processing is generally the reverse of ingress progressing
   described in Section 5.1.

   An FGL RBridge MUST be able to configurably convert the FGL in an FGL
   TRILL Data frame it is egressing to a VLAN ID for the resulting
   native frame on a per port basis. A port MAY be configured to strip
   output VLAN tagging. It is the responsibility of the network manager
   to properly configure the TRILL switches in the campus to obtain the
   desired mappings.

D. Eastlake, et al                                             [Page 13]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

   The priority and DEI of the egressed native frame are taken from the
   Inner.Label Low Order Part.

   An FGL RBridge egresses FGL frames similarly to the egressing of VL
   frames, as follows:

   1. A known unicast FGL frame is egressed to the FGL port matching its
      fine-grained label and Inner.MacDA. If there is no such port, it
      is flooded out all FGL ports that have its FGL unless the TRILL
      switch has knowledge that the frame's Inner.MacDA cannot be out
      that port.

   2. A multi-destination FGL frame is decapsulated and flooded out all
      ports with its FGL, subject to multicast pruning.

   FGL RBridges MUST accept multi-destination encapsulated frames that
   are sent to them as TRILL unicast frames, that is, frames that may
   have a multicast or broadcast Inner.MacDA (or are being sent to an
   unknown unicast Inner.MacDA) and the TRILL Header M bit = 0. They
   locally egress such frames, if appropriate, but MUST NOT forward them
   (other than egressing them as native frames on their local links).

5.4 Appointed Forwarders and the DRB

   There is no change in Adjacency [RFC6327] or Appointed Forwarder
   logic [RFC6439] on a link regardless of whether some or all the ports
   on the link are for FGL RBridges except as described in Section 4
   above.

5.5 Address Learning

   An FGL TRILL switch learns addresses on FGL ports based on the fine-
   grained label rather than the native frame's VLAN. Addresses learned
   from ingressed native frames on FGL ports are logically represented
   by { MAC address, fine-grained label, port, confidence, timer } while
   remote addresses learned from egressing FGL frames are logically
   represented by { MAC address, fine-grained label, remote TRILL switch
   nickname, confidence, timer }.

5.6 ESADI Extensions

   The TRILL ESADI (End Station Address Distribution Information)
   protocol is specified in [RFC6325] as optionally transmitting MAC
   address connection information through TRILL Data frames between

D. Eastlake, et al                                             [Page 14]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

   participating TRILL switches over the virtual link provided by the
   TRILL multicast frame distribution mechanism. In [RFC6325], the VLAN
   to which an ESADI frame applies is indicated only by the Inner.VLAN
   label and no indication of that VLAN is allowed within the ESADI
   payload.

   ESADI is extended to support FGL by providing for the indication of
   the FGL to which an ESADI frame applies only in the Inner.Label of
   that frame and no indication of that FGL is allowed within the ESADI
   payload.

D. Eastlake, et al                                             [Page 15]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

6. IS-IS Extensions

   Extensions to the TRILL use of IS-IS are required to support FGL
   include the following:

   1. An method for a TRILL switch to announce itself in its LSP as
      supporting FGL.

   2. A sub-TLV analogous to Interested VLANs and Spanning Tree Roots
      sub-TLV of the Router Capabilities TLV but indicating FGLs rather
      than VLs (see Section 8.2). This is called the Interested Labels
      and Spanning Tree Roots sub-TLV in [rfc6326bis].

   3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group Address
      TLV that specifies an FGL rather than a VL (see Section 8.2.).
      This are called the GLMAC-ADDR, GLIP-ADDR, and GLIP6 ADDR sub-TLVs
      in [rfc6326bis].

D. Eastlake, et al                                             [Page 16]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

7. Comparison to Goals

   Comparing TRILL FGL, as specified in this document, with the goals
   given in Section 2.1, we find as follows:

   1. Fine-Grained: FGL provides 2**24 labels, vastly more labels than
      the 4K VL labels provided in [RFC6325].

   2. Silicon Considerations: Existing TRILL fast path silicon chips can
      perform base TRILL Header insertion and removal to support ingress
      and egress. In addition, it is believed that most such silicon
      chips can also perform the native frame to FGL mapping and the
      encoding of the FGL as specified herein, as well as the inverse
      decoding and mapping. Some existing silicon can perform only one
      of these operations on a frame in the fast path and is thus not
      suitable to implement fast path TRILL FGL processing; however,
      other existing chips are believed to be able to perform both
      operations on the same frame in the fast path and are suitable for
      FGL implementation.

   3. Base RBridge Compatibility: As described in Section 3, FGL is not
      compatible with TRILL switches conformant to the base
      specification RBridges [RFC6325].

   4. Alternate Priority: The encoding specified in Section 2.3 provides
      for a new priority and DEI in the Inner.Label First Part and a
      place to preserve the original user priority and DEI in the Second
      Part, so it can be restored on egress.

D. Eastlake, et al                                             [Page 17]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

8. Allocation Considerations

   Allocations by the IEEE Registration Authority and IANA are listed
   below.

8.1 IEEE Allocation Considerations

   The IEEE Registration Authority has assigned Ethertype 0x893B for use
   as the FGL Ethertype.

8.2 IANA Considerations

   IANA is requested to allocate capability bit TBD in the TRILL-VER
   sub-TLV capability bits [RFC6326bis] to indicate an RBridge is FGL-
   capable.

D. Eastlake, et al                                             [Page 18]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

9. Security Considerations

   See [RFC6325] for general RBridge Security Considerations.

   As with any communications system, end-to-end encryption and
   authentication should be considered for sensitive data.

   Confusion between a frame with VL X and FGL (X.Y) is a potential
   problem if a VL RBridge did not check for the occurrence of 0x8100
   (see Sections 2.2 and 2.3) and discard such a frame. Possible
   problems with such a VL RBridge would be as follows:

   1. If it received a TRILL Data frame with FGL (X.Y) it could egress
      it to an end station in VLAN-X. The payload of such an egressed
      frame would appear to begin with Ethertype 0x893B which would
      likely be discarded by an end station. Nevertheless, such an
      egress would almost certainly be a violation of security policy.

   2. If it received a multi-destination TRILL Data frame with FGL (X.Y)
      and it pruned the distribution tree, it would incorrectly prune it
      on the basis of VLAN-X. This could lead to the multi-destination
      data frame not being delivered to all of its intended recipients.

   These two potential problems would only occur in the case of the
   misconfiguration of attaching such a VL RBridge to an FGL campus;
   however, there is protection against this in that FGL RBridges will
   not announce adjacency to VL RBridges (see Section 4). As a result,
   no TRILL data frames can be exchanged between VL and FGL RBridges and
   VL RBridges will be isolated for data puposes.

Acknowledgements

   The comments and suggestions of the following are gratefully
   acknowledged:

      Anoop Ghanwani, Sujay Gupta, Weiguo Hao, Jon Hudson, Yizhou Li,
      Vishwas Manral, Erik Nordmark, and Ilya Varlashkin.

   The document was prepared in raw nroff. All macros used were defined
   within the source file.

D. Eastlake, et al                                             [Page 19]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

Normative References

   [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.

   [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.

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997

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

   [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and
         A. Ghanwani, "Transparent Interconnection of Lots of Links
         (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, work in
         progress.

Informative References

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

   [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for
         Layer-2 Systems", RFC 6165, April 2011.

   [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
         and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
         6327, July 2011

   [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
         Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
         6439, November 2011.

D. Eastlake, et al                                             [Page 20]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

Change History

   From -00 to -01:

      Update author info and make editorial changes.

   From -01 to -02

   1. Change the value after the inner MAC addresses for FGL frames from
      0x8100 to 0x893B

   2. As a consequence of item 1 above, for safety prohibit use for
      TRILL Data of links between FGL and VL RBridges, isolating any VL
      RBridges. Make appropriate changes throughout document, including
      Security Considerations section, based on this change.

   3. Reference and contributor updates.

   4. Various editorial changes.

D. Eastlake, et al                                             [Page 21]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

Authors' Addresses

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

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

   Mingui Zhang
   Huawei Technologies Co., Ltd
   Huawei Building, No.156 Beiqing Rd.
   Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District,
   Beijing 100095 P.R. China

   Email: zhangmingui@huawei.com

   Puneet Agarwal
   Broadcom Corporation
   3151 Zanker Road
   San Jose, CA 95134 USA

   Phone: +1-949-926-5000
   Email: pagarwal@broadcom.com

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054 USA

   Phone: +1-408-765-8080
   Email: Radia@alum.mit.edu

   Dinesh G. Dutt
   Cumulus Networks
   1089 West Evelyn Avenue
   Sunnyvale, CA 94086 USA

   Email: ddutt.ietf@hobbesdutt.com

D. Eastlake, et al                                             [Page 22]
INTERNET-DRAFT                              TRILL: Fine-Grained Labeling

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2012 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, et al                                             [Page 23]