<pre>Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 7172                                      M. Zhang
Updates: <a href="./rfc6325">6325</a>                                                     Huawei
Category: Standards Track                                     P. Agarwal
ISSN: 2070-1721                                                 Broadcom
                                                              R. Perlman
                                                              Intel Labs
                                                                 D. Dutt
                                                        Cumulus Networks
                                                                May 2014


         <span class="h1">Transparent Interconnection of Lots of Links (TRILL):</span>
                         <span class="h1">Fine-Grained Labeling</span>

Abstract

   The IETF has standardized Transparent Interconnection of Lots of
   Links (TRILL), a protocol for least-cost transparent frame routing in
   multi-hop networks with arbitrary topologies and link technologies,
   using link-state routing and a hop count.  The TRILL base protocol
   standard supports the labeling of TRILL Data packets with up to 4K
   IDs.  However, there are applications that require a larger number of
   labels providing configurable isolation of data.  This document
   updates <a href="./rfc6325">RFC 6325</a> by specifying optional extensions to the TRILL base
   protocol to safely accomplish this.  These extensions, called fine-
   grained labeling, are primarily intended for use in large data
   centers, that is, those with more than 4K users requiring
   configurable data isolation from each other.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7172">http://www.rfc-editor.org/info/rfc7172</a>.








<span class="grey">Eastlake, et al.             Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.





































<span class="grey">Eastlake, et al.             Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Contributors ...............................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Fine-Grained Labeling ...........................................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Goals ......................................................<a href="#page-6">6</a>
      <a href="#section-2.2">2.2</a>. Base Protocol TRILL Data Labeling ..........................<a href="#page-7">7</a>
      <a href="#section-2.3">2.3</a>. Fine-Grained Labeling (FGL) ................................<a href="#page-7">7</a>
      <a href="#section-2.4">2.4</a>. Reasons for VL and FGL Coexistence .........................<a href="#page-9">9</a>
   <a href="#section-3">3</a>. VL versus FGL Label Differences ................................<a href="#page-10">10</a>
   <a href="#section-4">4</a>. FGL Processing .................................................<a href="#page-11">11</a>
      <a href="#section-4.1">4.1</a>. Ingress Processing ........................................<a href="#page-11">11</a>
           <a href="#section-4.1.1">4.1.1</a>. Multi-Destination FGL Ingress ......................<a href="#page-11">11</a>
      <a href="#section-4.2">4.2</a>. Transit Processing ........................................<a href="#page-12">12</a>
           <a href="#section-4.2.1">4.2.1</a>. Unicast Transit Processing .........................<a href="#page-12">12</a>
           <a href="#section-4.2.2">4.2.2</a>. Multi-Destination Transit Processing ...............<a href="#page-12">12</a>
      <a href="#section-4.3">4.3</a>. Egress Processing .........................................<a href="#page-13">13</a>
      <a href="#section-4.4">4.4</a>. Appointed Forwarders and the DRB ..........................<a href="#page-14">14</a>
      <a href="#section-4.5">4.5</a>. Distribution Tree Construction ............................<a href="#page-14">14</a>
      <a href="#section-4.6">4.6</a>. Address Learning ..........................................<a href="#page-15">15</a>
      <a href="#section-4.7">4.7</a>. ESADI Extension ...........................................<a href="#page-15">15</a>
   <a href="#section-5">5</a>. FGL TRILL Interaction with VL TRILL ............................<a href="#page-15">15</a>
      <a href="#section-5.1">5.1</a>. FGL and VL Mixed Campus ...................................<a href="#page-15">15</a>
      <a href="#section-5.2">5.2</a>. FGL and VL Mixed Links ....................................<a href="#page-17">17</a>
      <a href="#section-5.3">5.3</a>. Summary of FGL-Safe Requirements ..........................<a href="#page-18">18</a>
   <a href="#section-6">6</a>. IS-IS Extensions ...............................................<a href="#page-19">19</a>
   <a href="#section-7">7</a>. Comparison with Goals ..........................................<a href="#page-19">19</a>
   <a href="#section-8">8</a>. Allocation Considerations ......................................<a href="#page-20">20</a>
      <a href="#section-8.1">8.1</a>. IEEE Allocation Considerations ............................<a href="#page-20">20</a>
      <a href="#section-8.2">8.2</a>. IANA Considerations .......................................<a href="#page-20">20</a>
   <a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-20">20</a>
   <a href="#appendix-A">Appendix A</a>. Serial Unicast ........................................<a href="#page-22">22</a>
   <a href="#appendix-B">Appendix B</a>. Mixed Campus Characteristics ..........................<a href="#page-23">23</a>
      <a href="#appendix-B.1">B.1</a>. Mixed Campus with High Cost Adjacencies ...................<a href="#page-23">23</a>
      <a href="#appendix-B.2">B.2</a>. Mixed Campus with Data Blocked Adjacencies ................<a href="#page-24">24</a>
   Acknowledgements ..................................................<a href="#page-25">25</a>
   References ........................................................<a href="#page-25">25</a>
      Normative References ...........................................<a href="#page-25">25</a>
      Informative References .........................................<a href="#page-26">26</a>











<span class="grey">Eastlake, et al.             Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The IETF has standardized the Transparent Interconnection of Lots of
   Links (TRILL) protocol [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], which provides a solution for
   least-cost transparent routing in multi-hop networks with arbitrary
   topologies and link technologies, using [<a href="#ref-IS-IS" title="&quot;Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)&quot;">IS-IS</a>] [<a href="./rfc6165" title="&quot;Extensions to IS-IS for Layer-2 Systems&quot;">RFC6165</a>] [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>]
   link-state routing and a hop count.  TRILL switches are sometimes
   called RBridges (Routing Bridges).

   The TRILL base protocol standard supports the labeling of TRILL Data
   packets with up to 4K IDs.  However, there are applications that
   require a larger number of labels of data for configurable isolation
   based on different tenants, service instances, or the like.  This
   document updates [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] by specifying optional extensions to the
   TRILL base protocol to safely accomplish this.  These extensions,
   called fine-grained labeling, are primarily intended for use in large
   data centers, that is, those with more than 4K users requiring
   configurable data isolation from each other.

   This document describes a format for allowing a data label of
   24 bits, known as a "fine-grained label", or FGL.  It also describes
   coexistence and migration from current RBridges, known as "VL" (for
   "VLAN Labeled") RBridges, to TRILL switches that can support FGL
   ("Fine-Grained Labeled") packets.  Because various VL implementations
   might handle FGL packets incorrectly, FGL packets cannot be
   introduced until either all VL RBridges are upgraded to what we will
   call "FGL-safe", which means that they will not "do anything bad"
   with FGL packets, or all FGL RBridges take special precautions on any
   port by which they are connected to a VL RBridge.  FGL-safe
   requirements are summarized in <a href="#section-5.3">Section 5.3</a>.

   It is hoped that many RBridges can become FGL-safe through a software
   upgrade.  VL RBridges and FGL-safe RBridges can coexist without any
   disruption to service, as long as no FGL packets are introduced.

   If all RBridges are upgraded to FGL-safe, FGL traffic can be
   successfully handled by the campus without any topology restrictions.
   The existence of FGL traffic is known to all FGL RBridges because
   some RBridge (say, RB3) that might source or sink FGL traffic will
   advertise interest in one or more fine-grained labels in its
   contribution to the link state (its LSP).  If any VL RBridges remain
   at the point when any RBridge announces that it might source or sink
   FGL traffic, the adjacent FGL-safe RBridges MUST ensure that no FGL
   packets are forwarded to their VL RBridge neighbor(s).  The details
   are specified in <a href="#section-5.1">Section 5.1</a> below.






<span class="grey">Eastlake, et al.             Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Terminology</span>

   The terminology and acronyms of [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] are used in this document
   with the additions listed below.

      DEI - Drop Eligibility Indicator [<a href="#ref-802.1Q" title="&quot;IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks&quot;">802.1Q</a>].

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

      FGL-edge - An FGL TRILL switch advertising interest in an FGL
            label.

      FGL link - A link where all of the attached TRILL switches are
            FGL.

      FGL-safe - A TRILL switch that can safely be given an FGL data
            packet, as summarized in <a href="#section-5.3">Section 5.3</a>.

      RBridge - Alternative name for a TRILL switch.

      TRILL switch - Alternative name for an RBridge.

      VL - VLAN Labeling or VLAN Labeled or VLAN Label.

      VL link - A link where any one or more of the attached RBridges
            are VL.

      VL RBridge - A TRILL switch that supports VL but is not FGL-safe.

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Contributors</span>

   Thanks for the contributions of the following:

      Tissa Senevirathne and Jon Hudson

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Fine-Grained Labeling</span>

   The essence of Fine-Grained Labeling (FGL) is that (a) when frames
   are ingressed or created they may incorporate a data label from a set
   consisting of significantly more than 4K labels, (b) TRILL switch
   ports can be labeled with a set of such fine-grained data labels,





<span class="grey">Eastlake, et al.             Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   and (c) an FGL TRILL Data packet cannot be egressed through a TRILL
   switch port unless its fine-grained label (FGL) matches one of the
   data labels of the port.

   <a href="#section-2.1">Section 2.1</a> lists FGL goals.  <a href="#section-2.2">Section 2.2</a> briefly outlines the more
   coarse TRILL base protocol standard [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] data labeling.
   <a href="#section-2.3">Section 2.3</a> outlines FGL for TRILL Data packets.  <a href="#section-2.4">Section 2.4</a>
   discusses VL and FGL coexistence.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Goals</span>

   There are several goals that would be desirable for FGL 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
      [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] provides for only 2**12 - 2 valid identifiers or labels
      (VLANs).  A substantially larger number is required.

   2. Silicon

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

   3. Base RBridge Interoperation

      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 if RBridges not implementing the
      FGL features can exchange VL TRILL Data packets with FGL TRILL
      switches.

   4. Alternate Priority

      Under some circumstances, it would be desirable for traffic from
      an attached non-TRILL network to be handled, while transiting a
      TRILL network, with a different priority from the priority of the
      original native frames.  This could be accomplished by the ingress
      TRILL switch assigning a different priority to the FGL TRILL Data
      packet resulting from ingressing the native frames.  The original
      priority should be restored on egress.



<span class="grey">Eastlake, et al.             Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Base Protocol TRILL Data Labeling</span>

   This section provides a brief review of the [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] TRILL Data
   packet VL Labeling and changes the description of the TRILL Header by
   moving the point at which the TRILL Header ends.  This change in
   description does not involve any change in the bits on the wire or in
   the behavior of VL TRILL switches.

   VL TRILL Data packets have the 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 [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], the 0x8100 value is
   always present and is followed by the Inner.VLAN field, which
   includes the 12-bit VL.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Fine-Grained Labeling (FGL)</span>

   FGL expands the variety of data labels available under the TRILL
   protocol to include a fine-grained label (FGL) with a 12-bit high
   order part and a 12-bit low order part.  In this document, FGLs are
   denoted as "(X.Y)", where X is the high order part and Y is the low
   order part of the FGL.





<span class="grey">Eastlake, et al.             Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   FGL TRILL Data packets have the 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 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 packets, the inner Media Access Control (MAC) address fields
   are followed by the FGL information using 0x893B.  There MUST be two
   occurrences of 0x893B, as shown.  Should a TRILL switch processing an
   FGL TRILL Data packet notice that the second occurrence is actually
   some other value, it MUST discard the packet.  (A TRILL switch
   transiting a TRILL Data packet is not required to examine any fields
   past the initial fixed fields and options, although it may do so to
   support Equal-Cost Multi-Path (ECMP) or distribution tree pruning.)












<span class="grey">Eastlake, et al.             Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   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 as shown below.

               0  1  2   3  4  5  6  7  8  9 10 11 12 13 14 15
             +--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
             |priority|DEI|    label information              |
             +--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+

                     Figure 3: FGL Part Data Structure

   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
   order part of the FGL.  The priority field of the Inner.Label Low
   Part is remembered from the data frame as ingressed and is restored
   on egress.

   The appropriate FGL value for an ingressed or locally originated
   native frame is determined by the ingress TRILL switch port as
   specified in <a href="#section-4.1">Section 4.1</a>.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Reasons for VL and FGL Coexistence</span>

   For several reasons, as listed below, it is desirable for FGL TRILL
   switches to be able to handle both FGL and VL TRILL Data packets.

   o  Continued support of VL packets means that, by taking the
      precautions specified herein, in many cases such arrangements as
      VL TRILL switches easily exchanging VL packets through a core of
      FGL TRILL switches are possible.

   o  Due to the way TRILL works, it may be desirable to have a
      maintenance VLAN or FGL [<a href="./rfc7174" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework&quot;">RFC7174</a>] in which all TRILL switches in
      the campus indicate interest.  It will be simpler to use the same
      type of label for all TRILL switches for this purpose.  That
      implies using VL if there might be any VL TRILL switches in the
      campus.

   o  If a campus is being upgraded from VL to FGL, continued support of
      VL allows long-term support of edges labeled as VL.








<span class="grey">Eastlake, et al.             Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  VL versus FGL Label Differences</span>

   There are differences between the semantics across a TRILL campus for
   TRILL Data packets that are data labeled with VL and FGL.

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

   The larger FGL data label 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 stripped and 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 TRILL switch.  The FGL label
   space is flat and does not hierarchically encode any particular
   number of native frame C-VLAN bits or the like.  FGLs appear only
   inside TRILL Data packets after the inner MAC addresses.

   It is the responsibility of the network manager to properly configure
   the TRILL switches in the campus to obtain the desired mappings.
   Such configuration is expected to be automatic in many cases, based
   on configuration databases and orchestration systems.

   With FGL TRILL switches, many things remain the same because an FGL
   can appear only as the Inner.Label inside a TRILL Data packet.  As
   such, only TRILL-aware devices will see a fine-grained label.  The
   Outer.VLAN that may appear on native frames and that may appear on
   TRILL Data packets if they are on an Ethernet link can only be a
   C-VLAN tag.  Thus, ports of FGL TRILL switches, up through the usual
   VLAN and priority processing, act as they do for VL TRILL switches:
   TRILL switch ports provide a C-VLAN ID for an incoming frame and
   accept a C-VLAN ID for a frame being queued for output.  Appointed
   Forwarders [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>] on a link are still appointed for a C-VLAN.  The
   Designated VLAN for an Ethernet link is still a C-VLAN.

   FGL TRILL switches have capabilities that are a superset of those for
   VL TRILL switches.  FGL TRILL switch ports can be configured for FGL
   or VL, with VL being the default.  As with a base protocol [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>]
   TRILL switch, an unconfigured FGL TRILL switch port reports an
   untagged frame it receives as being in VLAN 1.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  FGL Processing</span>

   This section specifies ingress, transit, egress, and other processing
   details for FGL TRILL switches.  A transit or egress FGL TRILL switch
   determines that a TRILL Data packet is FGL by detecting that the
   Inner.MacSA is followed by 0x893B.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Ingress Processing</span>

   FGL-edge TRILL switch ports are configurable to ingress native frames
   as FGL.  Any port not so configured performs the previously specified
   [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] VL ingress processing on native frames resulting in a VL
   TRILL Data packet.  (There is no change in Appointed Forwarder logic
   (see <a href="#section-4.4">Section 4.4</a>).)  An FGL-safe TRILL switch may have only VL ports,
   in which case it is not required to support the capabilities for FGL
   ingress described in this section.

   FGL-edge TRILL switches support configurable per-port mapping from
   the C-VLAN 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 methods based on the
   protocol of the native frame or based on local knowledge.

   The FGL ingress process MUST copy the priority and DEI (Drop
   Eligibility Indicator) associated with an ingressed native frame to
   the 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, but a TRILL switch might not be able to do so
   because of implementation limitations.  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.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Multi-Destination FGL Ingress</span>

   If a native frame that has a broadcast, multicast, or unknown MAC
   destination address is FGL ingressed, it MUST be handled in one of
   the following two ways.  The choice of which method to use can vary
   from frame to frame, at the choice of the ingress TRILL switch.

   1. Ingress as a TRILL multi-destination data packet (TRILL Header M
      bit = 1) on a distribution tree rooted at a nickname held by an
      FGL RBridge or by the pseudonode of an FGL link.  FGL TRILL Data
      packets MUST NOT be sent on a tree rooted at a nickname held by a
      VL TRILL switch or by the pseudonode of a VL link.






<span class="grey">Eastlake, et al.             Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   2. Serially TRILL unicast the ingressed frame to the relevant egress
      TRILL switches by using a known unicast TRILL Header (M bit = 0).
      An FGL ingress TRILL switch SHOULD unicast a multi-destination
      TRILL Data packet if there is only one relevant egress FGL TRILL
      switch.  The relevant egress TRILL switches are determined by
      starting with those announcing interest in the frame's (X.Y)
      label.  That set SHOULD be further filtered based on multicast
      listener and multicast router attachment LSP announcements if the
      native frame was a multicast frame.

   Using a TRILL unicast header for a multi-destination frame when it
   has only one actual destination RBridge almost always improves
   traffic spreading and decreases latency as discussed in <a href="#appendix-A">Appendix A</a>.
   How to decide whether to use a distribution tree or serial unicast
   for a multi-destination TRILL Data packet that has more than one
   destination TRILL switch is beyond the scope of this document.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Transit Processing</span>

   Any FGL TRILL switch MUST be capable of TRILL Data packet transit
   processing.  Such processing is fairly straightforward as described
   in <a href="#section-4.2.1">Section 4.2.1</a> for known unicast TRILL Data packets and in
   <a href="#section-4.2.2">Section 4.2.2</a> for multi-destination TRILL Data packets.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Unicast Transit Processing</span>

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

   An FGL TRILL switch MUST properly distinguish flows if it provides
   ECMP for unicast FGL TRILL Data packets.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Multi-Destination Transit Processing</span>

   Multi-destination TRILL Data packets are forwarded on a distribution
   tree selected by the ingress TRILL switch, except that an FGL ingress
   TRILL switch MAY TRILL unicast such a frame to all relevant egress
   TRILL switches, all as described in <a href="#section-4.1">Section 4.1</a>.  The distribution
   trees do not distinguish between FGL and VL multi-destination
   packets, except in pruning behavior if they provide pruning.  There
   is no change in the Reverse Path Forwarding Check.





<span class="grey">Eastlake, et al.             Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   An FGL TRILL switch (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 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.  A
   transit TRILL switch MAY prune based on an arbitrary subset of the
   bits in the FGL label, for example, only the High Part or only the
   Low Part of the label.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Egress Processing</span>

   Egress processing is generally the reverse of ingress progressing
   described in <a href="#section-4.1">Section 4.1</a>.  An FGL-safe TRILL switch may have only VL
   ports, in which case it is not required to support the capabilities
   for FGL egress described in this section.

   An FGL-edge TRILL switch MUST be able to convert, in a configurable
   fashion, from the FGL in an FGL TRILL Data packet it is egressing to
   the C-VLAN ID for the resulting native frame with different mappings
   on a per-port basis.  The priority and DEI of the egressed native
   frame are taken from the Inner.Label Low Order Part.  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.

   FGL egress is similar to VL egress, as follows:

   1. If the Inner.MacDA is All-Egress-RBridges, special processing
      applies, based on the payload Ethertype (for example, End-Station
      Address Distribution Information (ESADI) [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] or RBridge
      Channel [<a href="./rfc7178" title="&quot;Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support&quot;">RFC7178</a>]), and if the payload Ethertype is unknown, the
      packet is discarded.  If the Inner.MacDA is not
      All-Egress-RBridges, then either item 2 or item 3 below applies,
      as appropriate.

   2. A known unicast FGL TRILL Data packet (TRILL Header M bit = 0)
      with a unicast Inner.MacDA is egressed to the FGL port or ports
      matching its FGL and Inner.MacDA.  If there are no such ports, it
      is flooded out of all FGL ports that have its FGL, except any
      ports for which the TRILL switch has knowledge that the frame's
      Inner.MacDA cannot be present on the link out of that port.




<span class="grey">Eastlake, et al.             Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   3. A multi-destination FGL TRILL Data packet is decapsulated and
      flooded out of all ports that have its FGL, subject to multicast
      pruning.  The same processing applies to a unicast FGL TRILL Data
      packet with a broadcast or multicast Inner.MacDA that might be
      received due to serial unicast.

   An FGL TRILL switch MUST NOT egress an FGL packet with label (X.Y) to
   any port not configured with that FGL, even if the port is configured
   to egress VL packets in VLAN X.

   FGL TRILL switches MUST accept multi-destination TRILL Data packets
   that are sent to them as TRILL unicast packets (packets with the
   TRILL Header M bit set to 0).  They locally egress such packets, if
   appropriate, but MUST NOT forward them (other than egressing them as
   native frames on their local links).

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Appointed Forwarders and the DRB</span>

   There is no change in adjacency [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], DRB (Designated RBridge)
   election, or Appointed Forwarder logic [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>] on a link,
   regardless of whether some or all the ports on the link are for FGL
   TRILL switches, with one exception: implementations SHOULD provide
   that their default priority for a VL RBridge port to be the DRB is
   less than their default priority for an FGL RBridge to be the DRB.
   This will assure that, in the unconfigured case, an FGL RBridge will
   be elected DRB when using that implementation.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Distribution Tree Construction</span>

   All distribution trees are calculated as provided for in the TRILL
   base protocol standard [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] as updated by [<a href="./rfc7180" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7180</a>], with the
   exception that the default tree root priority for a nickname held by
   an FGL TRILL switch or an FGL link pseudonode is 0x9000.  As a
   result, they will be chosen in preference to VL nicknames in the
   absence of configuration.  If distribution tree roots are configured,
   there MUST be at least one tree rooted at a nickname held by an FGL
   TRILL switch or by an FGL link pseudonode.  If distribution tree
   roots are misconfigured so there would not be such a tree, then the
   highest priority FGL nickname to be a tree root is used to construct
   an additional tree, regardless of configuration.  (VL TRILL switches
   will not know about this additional distribution tree but, through
   the use of Step (A) or (B) in <a href="#section-5.1">Section 5.1</a>, no VL TRILL switch should
   ever receive a multi-destination TRILL Data packet using this
   additional tree.)







<span class="grey">Eastlake, et al.             Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  Address Learning</span>

   An FGL TRILL switch learns addresses from the data plane on ports
   configured for FGL 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, FGL, port,
   confidence, timer }, while remote addresses learned from egressing
   FGL packets are logically represented by { MAC address, FGL, remote
   TRILL switch nickname, confidence, timer }.

<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>.  ESADI Extension</span>

   The TRILL ESADI (End-Station Address Distribution Information)
   protocol is specified in [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] as optionally transmitting MAC
   address connection information through TRILL Data packets between
   participating TRILL switches over the virtual link provided by the
   TRILL multi-destination packet distribution mechanism.  In [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>],
   the VL to which an ESADI packet applies is indicated only by the
   Inner.VLAN label, and no indication of that VL is allowed within the
   ESADI payload.

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

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  FGL TRILL Interaction with VL TRILL</span>

   This section discusses mixing FGL-safe and VL TRILL switches in a
   campus.  It does not apply if the campus is entirely FGL-safe or if
   there are no FGL-edges.  <a href="#section-5.1">Section 5.1</a> specifies what behaviors are
   needed to render such mixed campuses safe.  See also <a href="#appendix-B">Appendix B</a> for a
   discussion of campus characteristics when these behaviors are in use.
   <a href="#section-5.2">Section 5.2</a> gives details of link-local mixed behavior.

   It is best, if possible, for VL TRILL switches to be upgraded to
   FGL-safe before introducing FGL-edges (and therefore FGL data
   packets).

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  FGL and VL Mixed Campus</span>

   By definition, it is not possible for VL TRILL switches to safely
   handle FGL traffic, even if the VL TRILL switch is only acting in the
   transit capacity.  If a TRILL switch can safely transit FGL TRILL
   Data packets, then it qualifies as FGL-safe but will still be assumed
   to be VL until it advertises in its LSP that it is FGL-safe.





<span class="grey">Eastlake, et al.             Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   VL frames are required to have 0x8100 at the beginning of the data
   label, where FGL frames have 0x893B.  VL TRILL switches conformant to
   [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] should discard frames with this new value after the inner
   MAC addresses.  However, if they do not discard such frames, they
   could be confused and egress them into the wrong VLAN (see <a href="#section-9">Section 9</a>
   below) or persistently reorder them due to miscomputing flows for
   ECMP, or they could improperly prune their distribution if they are
   multi-destination so that they would fail to reach some intended
   destinations.  Such difficulties are avoided by taking all practical
   steps to minimize the chance of a VL TRILL switch handling an FGL
   TRILL Data packet.  These steps are specified below.

   FGL-safe switches will report their FGL capability in LSPs.  Thus,
   FGL-safe 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.

   Once a TRILL switch advertises an FGL-edge, any FGL-safe TRILL switch
   (RB1 in this discussion) that observes, on one of its ports, a VL
   RBridge on the link out of that port, MUST take Step (A) or (B) below
   for that port and also take Step (C) further below.  ("Observes"
   means that it has an adjacency to the VL TRILL switch that is in any
   state other than Down [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>] and holds an LSP fragment zero for
   it, showing that it is not FGL-safe.)  Finally, for there to be full
   FGL connectivity, the campus topology must be such that all FGL TRILL
   switches are reachable from all other FGL TRILL switches without
   going through a VL TRILL switch.

   (A) If RB1 can discard any FGL TRILL Data packet that would be output
       through a port where it observes a VL RBridge, while allowing the
       output of VL TRILL Data packets through that port, then

       A1. RB1 MUST so discard all FGL TRILL Data output packets that
           would otherwise be output through the port, and

       A2. For all adjacencies out of that port (even adjacencies to
           other FGL RBridges or a pseudonode) in the Report state
           [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], RB1 MUST report that adjacency cost as 2**23
           greater than it would have otherwise reported, but not more
           than 2**24 - 2 (the highest link cost still usable in least-
           cost path calculations and distribution tree construction).
           This assures that if any path through FGL-safe TRILL switches
           exists, such a path will be computed.

   (B) If RB1 cannot discard any FGL TRILL Data packet that would be
       output through a port where it observes a VL RBridge while
       allowing VL TRILL Data packets, then RB1 MUST, for all
       adjacencies out of that port (even adjacencies to other FGL-safe



<span class="grey">Eastlake, et al.             Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


       RBridges or a pseudonode) in the Report state [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], report
       the adjacency cost as 2**24 - 1.  As specified in IS-IS
       [<a href="./rfc5305" title="&quot;IS-IS Extensions for Traffic Engineering&quot;">RFC5305</a>], that cost will stop the adjacency from being used in
       least-cost path calculations, including distribution tree
       construction (see <a href="./rfc7180#section-2.1">Section&nbsp;2.1 of [RFC7180]</a>) but will still leave
       it visible in the topology and usable, for example, by any
       traffic engineered path mechanism.

   (C) The roots for all distribution trees used for FGL TRILL Data
       packets must be nicknames held by an FGL-safe TRILL switch or by
       a pseudonode representing an FGL link.  As provided in
       <a href="#section-4.5">Section 4.5</a>, there will always be such a distribution tree.

   Using the increased adjacency cost specified in part A2 of Step (A)
   above, VL links will be avoided unless no other path is available for
   typical data center link speeds using the default link cost
   determination method specified in Item 1 of <a href="./rfc6325#section-4.2.4.4">Section&nbsp;4.2.4.4 of
   [RFC6325]</a>.  However, if links have low speed (such as about
   100 megabits/second or less) or some non-default method is used for
   determining link costs, then link costs MUST be adjusted such that no
   adjacency between FGL-safe TRILL switches has a cost greater than
   200,000.

   To summarize, for a mixed TRILL campus to be safe once FGL-edges are
   introduced, it is essential that the steps above be followed by
   FGL-safe RBridges, to ensure that paths between such RBridges do not
   include VL RBridges, and to ensure that FGL packets are never
   forwarded to VL RBridges.  That is, all FGL-safe switches MUST do
   Step (A) or (B) for any port out of which they observe a VL RBridge
   neighbor.  Also, for full FGL connectivity, all FGL-safe TRILL
   switches MUST do Step (C) and be connected in a single FGL contiguous
   area.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  FGL and VL Mixed Links</span>

   The usual DRB election operates on a link with mixed FGL and VL
   ports.  If an FGL TRILL switch port is a DRB, it can handle all
   native traffic.  It MUST appoint only other FGL TRILL switch ports as
   Appointed Forwarder for any VLANs that are to be mapped to FGL.

   For VLANs that are not being mapped to FGL, if Step (A) is being
   followed (see <a href="#section-5.1">Section 5.1</a>), it can appoint either a VL or FGL TRILL
   switch for a VLAN on the link to be handled by a VL.  If Step (B) is
   being followed, an FGL DRB MUST only appoint FGL Appointed
   Forwarders, so that all end stations will get service to the FGL
   campus.  If a VL RBridge is a DRB, it will not understand that FGL
   TRILL switch ports are different.  To the extent that Step (B) is in
   effect and a VL DRB handles native frames or appoints other VL TRILL



<span class="grey">Eastlake, et al.             Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   switch ports on a link to handle native frames for one or more VLANs,
   the end stations sending and receiving those native frames may be
   isolated from the FGL campus.  When 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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Summary of FGL-Safe Requirements</span>

   The list below summarizes the requirements for a TRILL switch to be
   FGL-safe.

   1. For both unicast and multi-destination data, RB1 MUST NOT forward
      an FGL packet to a VL neighbor RB2.  This is accomplished as
      specified in <a href="#section-5.1">Section 5.1</a>.

   2. For both unicast and multi-destination data, RB1 MUST NOT egress a
      packet onto a link that does not belong in that FGL.

   3. For unicast data, RB1 must forward the FGL packet properly to the
      egress nickname in the TRILL Header.  This means that it MUST NOT
      delete the packet because of not having the expected VLAN tag, it
      MUST NOT insert a VLAN tag, and it MUST NOT misclassify a flow so
      as to persistently misorder packets, because the TRILL fields are
      now 4 bytes longer than in VL TRILL packets.

   4. For multi-destination data, RB1 must forward the packet properly
      along the specified tree.  This means that RB1 MUST NOT falsely
      prune the packet.  RB1 is allowed not to prune at all, but it MUST
      NOT prevent an FGL packet from reaching all the links with that
      FGL by incorrectly refusing to forward the FGL packet along a
      branch in the tree.

   5. RB1 must advertise, in its LSP, that it is FGL-safe.

   Point 1 above, for a TRILL switch to correctly support ECMP, and
   point 2, for a TRILL switch to correctly prune distribution trees,
   require that the TRILL switch properly recognize and distinguish
   between the two Ethertypes that can occur immediately after the
   Inner.MacSA in a TRILL Data packet.











<span class="grey">Eastlake, et al.             Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IS-IS Extensions</span>

   Extensions related to TRILL's use of IS-IS are required to support
   FGL and must include the following:

   1. A method for a TRILL switch to announce itself in its LSP as
      FGL-safe (see <a href="#section-8.2">Section 8.2</a>).

   2. A sub-TLV analogous to the Interested VLANs and Spanning Tree
      Roots sub-TLV of the Router Capabilities TLV but indicating FGLs
      rather than VLs.  This is called the Interested Labels and
      Spanning Tree Roots (INT-LABEL) sub-TLV in [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>].

   3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group Address
      TLV that specifies an FGL rather than a VL.  These are called the
      GLMAC-ADDR, GLIP-ADDR, and GLIPV6-ADDR sub-TLVs in [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>].

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Comparison with Goals</span>

   Comparing TRILL FGL, as specified in this document, with the goals
   given in <a href="#section-2.1">Section 2.1</a>, we find the following:

   1. Fine-Grained: FGL provides 2**24 labels, vastly more than the
      4094 (4K) VLAN labels supported in TRILL as specified in
      [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>].

   2. Silicon: 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 chips can perform only one of
      these operations on a frame in one pass through the fast path;
      however, other existing chips are believed to be able to perform
      both operations on the same frame in one pass through their fast
      path.  It is also believed that most FGL TRILL switches will be
      capable of having their ports configured to discard FGL packets.
      Such a capability makes interoperation with VL TRILL switches
      practical using Step (A) as opposed to Step (B) (see <a href="#section-5.1">Section 5.1</a>).

   3. Base RBridge Interoperation: As described in <a href="#section-3">Section 3</a>, FGL is not
      generally compatible with TRILL switches conformant to the base
      specification [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>].  In particular, a VL TRILL switch cannot
      be an FGL TRILL switch because there is a risk that it would
      mishandle FGL packets.  However, a contiguous set of VL TRILL
      switches can exchange VL frames, regardless of the presence of FGL
      TRILL switches in the campus.  The provisions of <a href="#section-5">Section 5</a> support
      reasonable interoperation and migration scenarios.



<span class="grey">Eastlake, et al.             Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   4. Alternate Priority: The encoding specified in <a href="#section-2.3">Section 2.3</a> and the
      ingress/egress processing specified in <a href="#section-4">Section 4</a> provide for a new
      priority and DEI in the Inner.Label High Part and a place to
      preserve the original user priority and DEI in the Low Part so
      that it can be restored on egress.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Allocation Considerations</span>

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

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  IEEE Allocation Considerations</span>

   The IEEE Registration Authority has assigned Ethertype 0x893B for
   TRILL FGL.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  IANA Considerations</span>

   IANA has allocated capability flag 1 in the TRILL-VER sub-TLV
   capability flags [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>] to indicate that a TRILL switch is
   FGL-safe.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   See [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] for general TRILL security considerations.

   As with any communications system, end-to-end encryption and
   authentication should be considered for sensitive data.  In this
   case, that would be encryption and authentication extending from a
   source end station and carried through the TRILL campus to a
   destination end station.

   Confusion between a packet with VL X and a packet with FGL (X.Y) or
   confusion due to a malformed frame is a potential problem if an FGL
   TRILL switch did not properly check for the occurrence of 0x8100 or
   0x893B immediately after the Inner.MacSA (see Sections <a href="#section-2.2">2.2</a> and <a href="#section-2.3">2.3</a>)
   and handle the frame appropriately.

   [<a id="ref-RFC6325">RFC6325</a>] requires that the Ethertype immediately after the
   Inner.MacSA be 0x8100.  A VL TRILL switch that did not discard a
   packet with some other value there could cause problems.  If it
   received a TRILL Data packet with FGL (X.Y) or with junk after the
   Inner.MacSA that included X where a VLAN ID would appear, then:

   1. It could egress the packet to an end station in VLAN X.  If the
      packet was a well-formed FGL frame, the payload of such an
      egressed native frame would appear to begin with Ethertype 0x893B,
      which would likely be discarded by an end station.  In any case,



<span class="grey">Eastlake, et al.             Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


      such an egress would almost certainly be a violation of security
      policy requiring the configurable separation of differently
      labeled data.

   2. If the packet was multi-destination and the TRILL switch pruned
      the distribution tree, it would incorrectly prune it on the basis
      of VLAN X.  For an FGL packet, this would probably lead to the
      multi-destination data packet not being delivered to all of its
      intended recipients.

   Possible problems with an FGL TRILL switch that (a) received a TRILL
   Data packet with junk after the Inner.MacSA that included X where a
   VLAN ID would appear and (b) did not check the Ethertype immediately
   after the Inner.MacSA would be that it could improperly egress the
   packet in VLAN X, violating security policy.  If the packet was
   multi-destination and was improperly forwarded, it should be
   discarded by properly implemented TRILL switches downstream in the
   distribution tree and never egressed, but the propagation of the
   packet would still waste bandwidth.

   To avoid these problems, all TRILL switches MUST check the Ethertype
   immediately after the Inner.MacSA and, if it is a value they do not
   know how to handle, either discard the frame or make no decisions
   based on any data after that Ethertype.  In addition, care must be
   taken to avoid FGL packets being sent to or through VL TRILL switches
   that will discard them if the VL TRILL switch is properly implemented
   or mishandle them if it is not properly implemented.  This is
   accomplished as specified in <a href="#section-5.1">Section 5.1</a>.























<span class="grey">Eastlake, et al.             Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Serial Unicast</span>

   This informational appendix discusses the advantages and
   disadvantages of using serial unicast instead of a distribution tree
   for multi-destination TRILL Data packets.  See Sections <a href="#section-4.1">4.1</a> and <a href="#section-4.3">4.3</a>.
   This document requires that FGL TRILL switches accept serial unicast,
   but there is no requirement that they be able to send serial unicast.

   Consider a large TRILL campus with hundreds of TRILL switches in
   which, say, 300 end stations are in some particular FGL data label.

   At one extreme, if all 300 end stations were on links attached to a
   single TRILL switch, then no other TRILL switch would be advertising
   interest in that FGL.  As a result, it is likely that because of
   pruning a multi-destination (say, broadcast) frame from one such end
   station would not be sent to any another TRILL switch, even if put on
   a distribution tree.

   At the other extreme, assume that the 300 end stations are attached,
   one each, to 300 different TRILL switches; in that case, you are
   almost certainly better off using a distribution tree because if you
   tried to serially unicast you would have to output 300 copies,
   probably including multiple copies through the same port, and would
   cause much higher link utilization.

   Now assume that these 300 end stations are connected to exactly two
   TRILL switches, say, 200 to one and 100 to the other.  Using unicast
   TRILL Data packets between these two TRILL switches is best because
   the frames will follow least-cost paths, possibly with such traffic
   spread over a number of least-cost paths with equal cost.  On the
   other hand, if distribution trees were used, each frame would be
   constrained to the tree used for that frame and would likely follow a
   higher cost route and only a single path would be available per tree.
   Thus, this document says that unicast SHOULD be used if there are
   exactly two TRILL switches involved.

   The decision of whether to use a distribution tree or serial unicast
   if the end stations are connected to more than two TRILL switches is
   more complex.  Which would be better would depend on many factors,
   including network topology and application data patterns.  How to
   make this decision in such cases is beyond the scope of this
   document.









<span class="grey">Eastlake, et al.             Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Mixed Campus Characteristics</span>

   This informational appendix describes the characteristics of a TRILL
   campus with mixed FGL-safe and VL TRILL switches for two cases:
   <a href="#appendix-B.1">Appendix B.1</a> discusses the case where all FGL adjacencies with VL are
   handled by Step (A) in <a href="#section-5.1">Section 5.1</a>, and <a href="#appendix-B.2">Appendix B.2</a> discusses the
   case where all FGL adjacencies with VL are handled by Step (B) in
   <a href="#section-5.1">Section 5.1</a>.

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  Mixed Campus with High Cost Adjacencies</span>

   If the FGL TRILL switches use Step (A) in <a href="#section-5.1">Section 5.1</a>, then VL and
   FGL TRILL switches will be able to interoperate for VL traffic.
   Least-cost paths will avoid any FGL -&gt; VL TRILL switch hops unless no
   other reasonable path is available.  In conjunction with <a href="#section-4.5">Section 4.5</a>,
   there will be at least one distribution tree rooted at a nickname
   held by an FGL TRILL switch or the pseudonode for an FGL link.
   Furthermore, if the FGL TRILL switches in the campus form a single
   contiguous island, this distribution tree will have a fully connected
   sub-tree covering that island.  Thus, any FGL TRILL Data packets sent
   on this tree will be able to reach any other FGL TRILL switch without
   attempting to go through any VL TRILL switches.  (Such an attempt
   would cause the FGL packet to be discarded as specified in part A1 of
   Step (A).)

   If supported, Step (A) is particularly effective in a campus with an
   FGL TRILL switch core and VL TRILL switches in one or more islands
   around that core.  For example, consider the campus below.  This
   campus has an FGL core consisting of FGL01 to FGL14 and three VL
   islands consisting of VL01 to VL04, VL05, and VL06 to VL14.

                  *VL01--*VL02
                    |      |
                  *VL03--*VL04                *VL05
                    |      |                    |
                  FGL01--FGL02--FGL03--FGL04--FGL05
                    |      |      |      |      |
                  FGL06--FGL07--FGL08--FGL09--FGL10
                    |      |      |      |      |
                  FGL11--FGL12--*VL06--*VL07---FGL13
                           |      |      |      |
                         *VL08--*VL09--*VL10---FGL14
                           |      |      |      |
                         *VL11--*VL12--*VL13--*VL14







<span class="grey">Eastlake, et al.             Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   Assuming that the FGL TRILL switches in this campus all implement
   Step (A), then end stations connected through a VL port can be
   connected anywhere in the campus to VL or FGL TRILL switches and, if
   in the same VLAN, will communicate.  End stations connected through
   an FGL port on FGL TRILL switches will communicate if their local
   VLANs are mapped to the same FGL.

   Due to the high cost of FGL-to-VL adjacencies used in path
   computations, VL TRILL switches are avoided on paths between FGL
   TRILL switches.  For example, even if the speed and default adjacency
   cost of all the connections shown above were the same, traffic from
   FGL12 to FGL13 would follow the 5-hop path FGL12 - FGL07 - FGL08 -
   FGL09 - FGL10 - FGL13 rather than the 3-hop path FGL12 - VL09 - VL10
   - FGL14.

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  Mixed Campus with Data Blocked Adjacencies</span>

   If the FGL TRILL switches use Step (B) in <a href="#section-5.1">Section 5.1</a>, then least-
   cost and distribution tree TRILL Data communication between VL and
   FGL TRILL switches is blocked, although TRILL IS-IS communication is
   normal.  This data blocking, although implemented only by FGL TRILL
   switches, has relatively symmetric effects.  The following paragraphs
   assume that such data blocking between VL and FGL is in effect
   throughout the campus.

   A campus of mostly FGL TRILL switches implementing Step (B) with a
   few isolated VL TRILL switches scattered throughout will work well in
   terms of connectivity for end stations attached to those FGL
   switches, except that they will be unable to communicate with any end
   stations for which a VL switch is appointed forwarder.  The VL TRILL
   switches will be isolated and will only be able to route TRILL Data
   to the extent that they happen to be contiguously connected to other
   VL TRILL switches.  Distribution trees computed by the FGL switches
   will not include any VL switches (see <a href="./rfc7180#section-2.1">Section&nbsp;2.1 of [RFC7180]</a>).

   A campus of mostly VL TRILL switches with a few isolated FGL TRILL
   switches scattered throughout will also work reasonably well as
   described immediately above but with all occurrences of "FGL" and
   "VL" swapped.

   However, a campus so badly misconfigured that it consists of a
   randomly intermingled mixture of VL and FGL TRILL switches using
   Step (B) is likely to offer very poor data service, due to many links
   being blocked for data.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


Acknowledgements

   The comments and suggestions of the following, listed in alphabetic
   order, are gratefully acknowledged:

      Stewart Bryant, Spencer Dawkins, Adrian Farrel, Anoop Ghanwani,
      Sujay Gupta, Weiguo Hao, Phanidhar Koganti, Yizhou Li, Vishwas
      Manral, Rajeev Manur, Thomas Narten, Gayle Nobel, Erik Nordmark,
      Pete Resnick, Olen Stokes, Sean Turner, Ilya Varlashkin, and
      Xuxiaohu.

References

Normative References

   [<a id="ref-802.1Q">802.1Q</a>]   IEEE 802.1, "IEEE Standard for Local and metropolitan area
              networks--Media Access Control (MAC) Bridges and Virtual
              Bridged Local Area Networks", IEEE Std 802.1Q-2011,
              August 2011.

   [<a id="ref-IS-IS">IS-IS</a>]    ISO/IEC 10589:2002, Second Edition, "Information
              technology -- Telecommunications and information exchange
              between systems -- Intermediate System to Intermediate
              System intra-domain routeing information exchange protocol
              for use in conjunction with the protocol for providing the
              connectionless-mode network service (ISO 8473)", 2002.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC5305">RFC5305</a>]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", <a href="./rfc5305">RFC 5305</a>, October 2008.

   [<a id="ref-RFC6325">RFC6325</a>]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", <a href="./rfc6325">RFC 6325</a>, July 2011.

   [<a id="ref-RFC7176">RFC7176</a>]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
              D., and A. Banerjee, "Transparent Interconnection of Lots
              of Links (TRILL) Use of IS-IS", <a href="./rfc7176">RFC 7176</a>, May 2014.

   [<a id="ref-RFC7177">RFC7177</a>]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
              V. Manral, "Transparent Interconnection of Lots of Links
              (TRILL): Adjacency", <a href="./rfc7177">RFC 7177</a>, May 2014.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   [<a id="ref-RFC7180">RFC7180</a>]  Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
              A. Banerjee, "Transparent Interconnection of Lots of Links
              (TRILL): Clarifications, Corrections, and Updates"
              <a href="./rfc7180">RFC 7180</a>, May 2014.

Informative References

   [<a id="ref-RFC6165">RFC6165</a>]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", <a href="./rfc6165">RFC 6165</a>, April 2011.

   [<a id="ref-RFC6439">RFC6439</a>]  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
              Hu, "Routing Bridges (RBridges): Appointed Forwarders",
              <a href="./rfc6439">RFC 6439</a>, November 2011.

   [<a id="ref-RFC7174">RFC7174</a>]  Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
              3rd, "Transparent Interconnection of Lots of Links (TRILL)
              Operations, Administration, and Maintenance (OAM)
              Framework", <a href="./rfc7174">RFC 7174</a>, May 2014.

   [<a id="ref-RFC7178">RFC7178</a>]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
              Ward, "Transparent Interconnection of Lots of Links
              (TRILL): RBridge Channel Support", <a href="./rfc7178">RFC 7178</a>, May 2014.

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








<span class="grey">Eastlake, et al.             Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7172">RFC 7172</a>              TRILL: Fine-Grained Labeling              May 2014</span>


   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
























Eastlake, et al.             Standards Track                   [Page 27]
</pre>