[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-eastlake-trill-rbridge-fine-labeling) 00 01 RFC 7172

TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                              Mingui Zhang
Intended status: Proposed Standard                                Huawei
Updates: 6325                                             Puneet Agarwal
                                                                Broadcom
                                                             Dinesh Dutt
                                                                   Cisco
                                                           Radia Perlman
                                                              Intel Labs
Expires: June 7, 2012                                   December 8, 2011

                      TRILL: Fine-Grained Labeling
                <draft-ietf-trill-fine-labeling-00.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 by
   specifying extensions to the TRILL base protocol to 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

      2. Fine-Grained Labeling...................................4
      2.1 Requirements...........................................4
      2.2 Base Protocol TRILL Data Labeling......................5
      2.3 Fine-Grained Labeling (FGL)............................5

      3. Campus Wide VL versus FGL Semantic Differences..........7

      4. Coexistence with VL TRILL Switches......................8
      4.1 VL Specifiable Data Labels.............................8

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

      6. IS-IS Extensions.......................................14
      7. Comparison to Requirements.............................15

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

      9. Security Considerations................................17
      Acknowledgements..........................................17
      Normative References......................................18
      Informative References....................................18
















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 frame 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 service instances, tenants, or the like. This document
   updates [RFC6325] by specifying extensions to the TRILL base protocol
   to 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 support 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


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 of significantly more than 4K labels, (b) TRILL switch
   ports can be labeled with a set of such labels, and (c) an FGL TRILL
   Data frame cannot be egressed through a TRILL switch port unless its
   fine-grained label (FGL) matches one of the labels of the port.

   Section 2.1 lists FGL requirements.  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 Requirements

   There are several requirements 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 TRILL fast path silicon
      implementations.

   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.

   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


D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


      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)  |
               | (may include VLAN tag if an Ethernet link)|
               +-------------------------------------------+
               | 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) |
               +-------------------------------------------+

   As specified in [RFC6325] the 0x8100 value is always present and is
   followed by the Inner.VLAN field which includes the 12-bit VLAN
   label.



2.3 Fine-Grained Labeling (FGL)

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


D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


               +-------------------------------------------+
               | Link Header (depends on link technology)  |
               | (may include VLAN tag if an Ethernet link)|
               +-------------------------------------------+
               | TRILL Header                              |
               | +---------------------------------------+ |
               | |    Initial Fields and Options         | |
               | +---------------------------------------+ |
               | |         Inner.MacDA         | (6 bytes) |
               | +-----------------------------+           |
               | |         Inner.MacSA         | (6 bytes) |
               | +-----------------------------+           |
               | | EtherType 0x8100        |     (2 bytes) |
               | +-------------------------+               |
               | | Inner.Label First Part  |     (2 bytes) |
               | +-------------------------+               |
               | | EtherType 0x893B        |     (2 bytes) |
               | +-------------------------+               |
               | | Inner.Label Second Part |     (2 bytes) |
               | +-------------------------+               |
               +-------------------------------------------+
               |               Native Payload              |
               +-------------------------------------------+
               | Link Trailer (depends on link technology) |
               +-------------------------------------------+

   The fixed format area of the TRILL Header with the Inner.Label and
   EtherType fields 0x8100 and 0x893B is mandatory for FGL frames. It is
   designed for backward compatibility with IETF standard [RFC6325]
   conformant RBridges although such RBridges will only be aware of the
   most significant 12-bits of the FGL.

   The two bytes following the EX-TAG EtherType 0x893B have, in their
   low order 12 bits, the low order part of the fine-grained label. 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 First Part is the priority used
   for frame transport from ingress to egress.

   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 VLAN tagged as
   specified in Section 5.3.







D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


3. Campus Wide VL versus FGL Semantic Differences

   There are significant differences between the semantics across a
   campus for VLs and FGLs of 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, at and below the EISS (Extended Internal Sublayer Service)
   interface, act as they do for VL RBridges: Ethernet links still have
   C-VLAN tagging on them and the EISS of TRILL switch ports provide a
   VLAN ID for an incoming frame and accept 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 a link is a C-VLAN.

   The larger FGL space is a different flat 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 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 payload after the TRILL EtherType. As a result, 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, by default an FGL
   TRILL switch port reports an untagged frame it receives as being in
   VLAN 1.

















D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


4. Coexistence with VL TRILL Switches

   Unmodified VL RBridges will operate properly as transit TRILL
   switches. Transit TRILL switches look at the VL or FGL data labeling
   only for the filtering of multi-destination frames.  If an RBridge
   does not perform filtering, or filters on only part of the fields in
   the packet, the only consequence is that multi-destination frames
   will use more bandwidth than necessary. VL RBridges would only look
   at the high order X of the (X.Y) FGL, which are in the position where
   a VL RBridge would expect to find a VL data label. Thus they will not
   be able to prune as effectively as transit FGL TRILL switches could
   because they will ignore the lower order half of the FGL. (Transit
   RBridge that fully support FGL can, of course, prune on the full
   FGL.)

   To avoid potential problems with VL RBridges, the high order X of an
   (X.Y) FGL MUST NOT be zero or 0xFFF.

   It would be more serious if a VL edge RBridge, RB1, unaware of FGL,
   forwarded an FGL frame with FGL (X.Y) onto a link through an RB1 port
   configured as VL VLAN-X. VL RB1 would strip the TRILL Header only
   through the Inner.Label First Part and forward the packet with the
   Inner.Label Second Part and preceding 0x893B field still present.
   This might cause other problems on the link. It would also be
   problematic if a malicious end station could forge an apparent FGL
   (X.Y) frame by including extra fields in native frames ingressed by a
   VL edge RBridge. Therefore, it is highly desirable for all the edge
   RBridges to be FGL TRILL switches.

   FGL RBridge will report the FGL capability in LSPs, so FGL RBridges
   (and any management system with access to the link state database)
   will be able to detect the existence of VL edge RBridges.



4.1 VL Specifiable Data Labels

   It might be useful, in a particular campus with mixed VL and FGL
   TRILL switches, to have some end station VLANs accessible via VL edge
   RBridges.  This is supported by reserving some number of VLANs (say
   the first k), to be VL-addressable.  These VLANs will be specified
   with a VL data label, whether or not any of the edge TRILL switches
   attached to these end station VLANs are FGL-capable.  When VL-
   specifiable VLANs are used in a FGL campus the upper half of an FGL
   MUST NOT be equal to the value of any VL-specifiable data label.

   If this rule is violated, the network misconfiguration is detected by
   the FGL TRILL switches that will then refuse in ingress to or egress
   from label (X.Y) while end station VLAN X connectivity is VL-
   specifiable as described below.


D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


   To avoid FGL frames getting pruned by VL RBridges, an FGL RBridge
   that ingresses to or egresses from (X.Y) MUST advertise in its LSP
   that it is connected to VLAN X. To avoid confusion, it is necessary
   to distinguish whether a TRILL switch is advertising VL-specifiable
   connectivity to VLAN X or just advertising such connectivity to avoid
   incorrect VL RBridge pruning.

   A VL data label X is VL-specifiable in a campus if either of the
   following two conditions apply:

   1. A VL RBridge advertises connectivity to VLAN-X.

   2. An FGL RBridge advertises connectivity to VLAN-X but does not
      advertise connectivity to FGL (X.Y) for any Y.






































D. Eastlake, et al                                              [Page 9]

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 Fine-Grained Labels (FGLs). A
   transit or egress FGL TRILL switch detects FGL TRILL Data frames by
   noticing that the Inner.Label First Part is not a VL-specifiable data
   label (see Section 4.1).



5.1 Ingress Processing

   An FGL RBridge may be configured, on one or more ports, to FGL
   ingress native frames. There is no change in VL ingress processing,
   which is the default unless a port has been configured for FGL, and
   no change in Appointed Forwarder logic (see Section 5.4).

   FGL TRILL switches MUST support configurable per port mapping from
   the C-VLAN ID of a native frame, as reported by the ingress port, to
   a 24-bit fine-grained label. 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. If the resulting label
   (X.Y) is such that X is a VL-specifiable data label, the ingressed
   frame MUST be dropped.

   The FGL ingress process MUST place the priority and DEI associated
   with an ingressed native frame in upper 4 bits of the second
   Inner.Label 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 First Part. If such mapping is not
   supported then the original priority and DEI MUST be placed in the
   Inner.Label First Part.

   An FGL ingress RBridge MAY serially TRILL unicast a multi-destination
   TRILL Data frame to the relevant egress TRILL switches, if those
   egress RBridges are all FGL, after encapsulating it as a TRILL known
   unicast data frame (M=0) and SHOULD so 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 router connectivity if the native frame was a multicast
   frame.

   Use of S-tags is beyond the scope of this document but is an obvious
   extension.




D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


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.



5.2.1 Unicast Transit Processing

   There is almost no 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. Just as transit RBridges conformant to the TRILL base
   protocol standard [RFC6325] do not examine the VL of unicast TRILL
   Data frames, transit FGL RBridges do not examine the FGL of unicast
   TRILL Data frames.

   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 First Part. These bits are in the same relative position
   for VL and FGL frames so VL RBridges will do this automatically even
   though they do not fully understand FGL frames.



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 if they are all support FGL.  The distribution
   trees for FGL and VL multi-destination frames are the same and 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 based on
   whether there are any edge TRILL switches on the tree branch that are
   connected to label (X.Y). In addition, RB1 SHOULD prune multicast
   frames based on reported multicast listener and multicast router
   attachment in (X.Y). Finally, a transit FGL RBridge MAY drop any
   multi-destination frame for label (X.Y) if X is VL-specifiable (see
   Section 4.1). "MAY" is chosen in this case to minimize the checking
   burden on transit TRILL switches.

   To ensure that a transit VL RBridge does not falsely filter traffic
   for FGL (X.Y), an FGL edge RBridge attached to FGL (X.Y) MUST report
   connection to VLAN X in addition to reporting connectivity to label
   (X.Y).  Because of this, VL transit RBridges can safely apply pruning


D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


   to all TRILL Data frames, both VL and FGL, based on the reported
   VLAN-X connectivity of all downstream TRILL switches.

   To ensure that a transit VL RBridge does not falsely prune traffic
   for FGL (X.Y) base on multicast filtering, an FGL edge RBridge
   attached to label (X.Y) MUST also report for VLAN-X either (1) that
   it is attached to both IPv4 and IPv6 multicast routers or (2) its
   merged FGL (X.Y) multicast listener and router connectivity for all
   Y.



5.3 Egress Processing

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

   If X is VL-specifiable (see Section 4.1), an FGL RBridge MUST NOT
   egress a frame with FGL (X.Y) but MUST drop such a frame.

   An FGL RBridge MUST be able to configurably convert the 24-bit fine
   grained label in an FGL TRILL Data frame it is egressing to a C-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 and
   ports in the campus to obtain the desired mappings.

   The priority and DEI of the egressed native frame are taken from the
   Inner.Label Second 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 fine-grained label
      unless the TRILL switch has knowledge that the frames Inner.MacDA
      cannot be out that port.

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

   FGL RBridges MUST accept multi-destination encapsulated frames that
   are sent to them as TRILL unicast frames, that is, frames with a
   multicast or broadcast 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).

   Use of S-tags is beyond the scope of this document but is an obvious


D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


   extension.



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. However, if it is intended for
   native frames on a link in some VLAN-X to be ingressed and egressed
   with FGL, the Appointed Forwarder for VLAN-X for that link obviously
   MUST be an FGL RBridge.

   If there are FGL and VL TRILL switches connected to a link, it may be
   best if the priorities are configured so that the DRB is an FGL
   RBridge. However, there is no inherent difficulty in a VL DRB RBridge
   appointing an FGL TRILL switch connected to the link as Appointed
   Forwarder for whatever VLANs are appropriate.



5.5 Address Learning

   An FGL RBridge 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
   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 13]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


6. IS-IS Extensions

   Extensions to the TRILL use of IS-IS are required to support 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 VLANs.

   3. A sub-TLV analogous to the GMAC-ADDR sub-TLV of the Group Address
      TLV that specifies a FGL rather than a VLAN.

   See [RFC6326bis] and Section 8.2.




































D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


7. Comparison to Requirements

   Comparing TRILL fine-grained labeling (FGL), as specified in this
   document, with the requirements given in Section 2.1, we find they
   are met as follows:

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

   2. Silicon Considerations: Existing TRILL fast path silicon chips
      can, almost by definition, 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 C-
      VLAN and port to fine-grained label mapping and the encoding of
      the fine-grained label 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
      compatible with base specification (VL) RBridges [RFC6325] acting
      as transit TRILL switches and, as described in Section 5.4, there
      is no particular problem in mixing VL and FGL TRILL switches on
      the same link.

   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 15]

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 EX-TAG EtherType.



8.2 IANA Considerations

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

































D. Eastlake, et al                                             [Page 16]

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:

   1. A TRILL Data frame with FGL (X.Y) could be egressed to an end
      station in VLAN-X by a VL RBridge that is Appointed Forwarder for
      VLAN-X on one of its ports.  This is solved by prohibiting FGL
      RBridges from ingressing to FGL (X.Y) if the campus is configured
      so that VLAN-X is VL-specifiable (see Section 4.1).

   2. An end station could try to forge FGL (X.Y) frames by sending
      frames with an EX-TAG Y at the front to a VL RBridge port where
      the frame would be input as being in VLAN-X. This is solved by
      prohibiting egress from FGL (X.Y) while VLAN-X is VL-specifiable
      (see Section 4.1).



Acknowledgements

   The comments and contributions of the following are gratefully
   acknowledged:

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

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

















D. Eastlake, et al                                             [Page 17]

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-eastlake-isis-rfc6326bis-01.txt,
         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 18]

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


   Dinesh G. Dutt
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   Phone: +1-408-527-0955
   Email: ddutt@cisco.com


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

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







D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                              TRILL: Fine-Grained Labeling


Copyright, Disclaimer, and Additional IPR Provisions

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

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





















D. Eastlake, et al                                             [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/