TRILL Working Group                                        Radia Perlman
INTERNET-DRAFT                                                       EMC
Updates: 6325                                            Donald Eastlake
Intended status: Proposed Standard                             Yizhou Li
                                                                  Huawei
                                                          Anoop Ghanwani
                                                                    Dell
Expires: March 23, 2018                               September 24, 2017


                RBridges: TRILL Link Data Optimizations
           <draft-perlman-trill-rbridge-data-encoding-08.txt>


Abstract

   TRILL (TRansparent Interconnection of Lots of Links) Data frames can
   be encoded so as to make more efficient use of communications links
   under certain circumstances.  This document specifies two such
   optional optimizations.  One, called Compact Format, improves the
   compactness of encoding where a TRILL link is a point-to-point
   Ethernet link.  The other, called Specific Addressing, optionally
   decreases the burden on multi-access TRILL links for multi-
   destination TRILL Data frames. This document updates RFC 6325.


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 <trill@ietf.org>.

   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.







R. Perlman, et al                                               [Page 1]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


Table of Contents

      1. Introduction............................................3
      1.1 Structure of This Document.............................3
      1.2 Terminology Used in This Document......................4

      2. TRILL Frame Formats.....................................5
      2.1 The General TRILL Frame Format.........................5
      2.2 Ethernet Link TRILL Data Frame General Encapsulation...6

      3. Compact Format for Point-to-Point Ethernet Links........8
      3.1 Conditions for Using Compact Format....................8
      3.2 RBridge Originated and Terminated Native Frames.......10
      3.3 Compact TRILL Data Reception and Transmission.........10
      3.3.1 Compact TRILL Data Frame Reception..................10
      3.3.2 Compact TRILL Data Frame Transmission...............12
      3.4 Announcing Support for Compact Format.................12

      4. Specific Addressing....................................13
      4.1 Current Multi-Destination Addressing..................13
      4.2 Specific Addressing Specification.....................13
      4.3 Announcing Support for Specific Addressing............13

      5. Interaction Between The Optimizations..................15
      6. IANA Considerations....................................16

      7. Security Considerations................................17
      7.1 Compact Format Security Considerations................17
      7.2 Specific Addressing Security Considerations...........17
      7.3 Results of Frame Misinterpretation....................17

      8. References.............................................19
      8.1 Normative References..................................19
      8.2 Informative References................................20

      Authors' Addresses........................................21
















R. Perlman, et al                                               [Page 2]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


1. Introduction

   TRILL switches (also called RBridges (Routing Bridges)) are devices
   that support the IETF TRILL (TRansparent Interconnection of Lots of
   Links) protocol [RFC6325] [RFC7177] [RFC7780]. They provide
   transparent forwarding of frames in multi-hop networks with arbitrary
   topology and link technology using least cost paths for unicast
   traffic, support VLANs (Virtual Local Area Networks) and 24-bit Fine
   Grained Labels [RFC7172], and support the multipathing of both
   unicast and multi-destination traffic. They accomplish this by use of
   a hop count and IS-IS (Intermediate System to Intermediate System)
   link state routing [IS-IS] [RFC7176].

   A link between two TRILL switches in a TRILL campus can be any of a
   variety of technologies, ranging from a complex bridged LAN to PPP
   [RFC6361]. In the general case under the base TRILL protocol
   [RFC6325], a TRILL Data frame consists of an inner payload formatted
   as an Ethernet frame, preceded by a TRILL Header, and then
   encapsulated by a link envelope appropriate for the link technology.



1.1 Structure of This Document

   Section 2 discusses General Format TRILL Data frames without the
   enhancements specified in this document.

   In the case where the link is a point-to-point Ethernet link, an
   optional Compact Format is specified for TRILL Data frames that saves
   16 bytes. Section 3 specifies that format, its processing, and the
   conditions for its safe use.

   In the case where a multi-destination TRILL Data frame is being
   forwarded over a multi-access link with multiple ports connected but
   there is only one (or perhaps a few) next hop TRILL switches of
   interest, optional Specific Addressing allows the TRILL Data frame to
   be link unicast. This can substantially reduce the burden that frame
   represents if, for example, the link is a complex bridged LAN through
   which the frame might otherwise be flooded.  Section 4 specifies the
   Specific Addressing enhancement and the conditions for its safe use.

   Section 5 discusses potential interaction between these two
   enhancements. The remaining Sections after Section 5 provide IANA and
   Security Considerations, References, and the like.

   This document updates [RFC6325].






R. Perlman, et al                                               [Page 3]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


1.2 Terminology Used in This Document

   The terminology and acronyms defined in [RFC6325] are used herein
   with the same meaning. In particular, the terms "campus", "native
   frame", "link", etc., are as defined [RFC6325].

   "Point-to-point", as used herein, means a link which appears to be an
   isolated channel between exactly two TRILL switch ports. Such a link
   may not include customer bridges but may include hubs/repeaters, Two
   Port MAC Relays, Provider Bridges, Provider Back Bone Bridges
   [802.1Q], or other technology, provided that technology is configured
   to provide a transparent point-to-point path between the end point
   RBridge ports.

   References herein to "VLAN Tag" or the like are to customer VLANs (C-
   Tags, Ethertype 0x8100). Use of S-Tags, also known as Service Tags,
   or stacked VLAN or other tags is beyond the scope of this document
   but is an obvious extension.

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






























R. Perlman, et al                                               [Page 4]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


2. TRILL Frame Formats

   The subsections below provide a description of the general format of
   TRILL Data frames. It then narrows in to describe the format of TRILL
   Data frames on Ethernet links.



2.1 The General TRILL Frame Format

   The general "on-the-wire" form of TRILL frames is illustrated below.

   The Link Headers and Trailers in the formats below depend on the
   specific link technology. The Link Header contains one or more fields
   that distinguish TRILL Data from TRILL IS-IS. For example, over
   Ethernet, the TRILL Data Link Header ends with the TRILL Ethertype
   while the TRILL IS-IS frame Link Header ends with the L2-IS-IS
   Ethertype; on the other hand, over PPP, there are no Ethertypes but
   PPP protocol codes perform that function [RFC6361].

   A TRILL Data frame in transit between two neighboring RBridges is as
   shown below:

       +---------------+----------+----------------+---------------+
       | TRILL Data    |  TRILL   |    Payload     | TRILL Data    |
       | Link  Header  |  Header  |  Native Frame  | Link Trailer  |
       +---------------+----------+----------------+---------------+

                   Figure 1. Format of TRILL Data Frames

   In the above diagram, the Payload Native Frame is in a restricted
   Ethernet frame format with a VLAN or FGL [RFC7172] label but with no
   trailing Frame Check Sequence (FCS). The payload frame format is
   shown below, assuming the payload starts with an Ethertype (it might
   alternatively be LLC [802-2014] encoded or some other format):

        +-----------+------------+--------+-----------+------------
        | MAC Dest. | MAC Source | Label  | Ethertype |         ...
        +-----------+------------+--------+-----------+------------

                   Figure 2. Format of the Payload Frame

      The encapsulated payload has the following fields in sequence:

   o  A 6-byte destination MAC address (Inner.MacDA)

   o  A 6-byte source MAC address (Inner.MacSA)

   o  An Inner.Label giving the VLAN ID or FGL [RFC7172], Priority, and
      DEI (Drop Eligibility Indicator) [RFC7780] of the payload (use of


R. Perlman, et al                                               [Page 5]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


      an S-tag or stacked tags is beyond the scope of this document but
      is an obvious extension)

   o  The payload frame's content (which usually starts with an
      Ethertype, such as the Ethertype for IPv4 or IPv6)

   TRILL IS-IS frames are also sent between neighboring RBridges and
   must be distinguished from TRILL Data frames. TRILL IS-IS frames are
   formatted as follows and cannot use the Compact Format specified
   herein:

              +--------------+---------------+--------------+
              | TRILL IS-IS  |  TRILL IS-IS  | TRILL IS-IS  |
              | Link Header  |    Payload    | Link Trailer |
              +--------------+---------------+--------------+

                        Figure 3. TRILL IS-IS Frame



2.2 Ethernet Link TRILL Data Frame General Encapsulation

   If the link between neighbor RBridges is Ethernet, then the general
   TRILL Data frame format has the following link encapsulation:

   Link Header: a 6-byte outer MAC destination address (Outer.MacDA)
         followed by a 6-byte outer MAC source address (Outer.MacSA)
         followed by an optional 4-byte outer VLAN tag Ethertype and
         value (Outer.VLAN), and finally the 2-byte TRILL Ethertype
         (0x22F3). Additional tags could be included after the outer MAC
         addresses and before the TRILL Ethertype such a MACSEC
         [802.1AE].

         Under the TRILL standard before this document, the Outer.MacDA
         was required to be the unicast MAC address of the destination
         RBridge port, if the TRILL Data frame was a unicast frame to a
         known destination, and was required to be the All-RBridges
         multicast address, if the TRILL Data frame was a multi-
         destination frame.

            +-----------+------------+- - - - - +-----------+
            | MAC Dest. | MAC Source | VLAN Tag | TRILL     |
            |   Address |    Address |  if Req. | Ethertype |
            +-----------+------------+ - - - - -+-----------+

         Figure 4. TRILL Data Link Header on an Ethernet Link


   Link Trailer: the 32-bit IEEE [802.3] Frame Check Sequence (FCS).



R. Perlman, et al                                               [Page 6]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


   In the General Format for Ethernet links, the Outer.VLAN can be
   omitted when it is not required by VLAN sensitive equipment in the
   link.

















































R. Perlman, et al                                               [Page 7]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


3. Compact Format for Point-to-Point Ethernet Links

   TRILL Data frames may optionally be sent using a Compact Format that
   compresses the headers involved if the link is a point-to-point
   Ethernet link, Compact Format can be enabled by both RBridges on the
   link if other conditions met as listed below.

   The Compact Format is simple: the Outer.MacDA, Outer.MacSA, and
   Outer.VLAN are replaced by the Inner.MacDA, Inner.MacSA, and Inner
   Label and the Inner fields are deleted. This saves 6 + 6 + 4 or 16
   bytes. To avoid confusion, Compact Format MUST NOT be used if the
   Inner.MacDA is a multi-cast address assigned to TRILL
   (01-80-C2-00-00-40 through 01-80-C2-00-00-4F).

   Compact Format is not applicable to TRILL IS-IS frames because there
   is no inner Ethernet header. (And, of course, Compact Format is not
   applicable to native frames or Layer 2 Ethernet control frames since
   those frames are not TRILL frames.)

     +---------------------+--------+-----------+---------+---------+
     | Ethernet Header     | TRILL  | Content   | Content | Link    |
     | Header from Payload | Header | Ethertype | ...     | Trailer |
     +---------------------+--------+-----------+---------+---------+

                 Figure 5. Compact Format TRILL Data Frame

   Compact Format is generally intended for use on point-to-point
   Ethernet links between RBridges, a common arrangement in many LANs.
   However, if there are any transparent devices in the apparent point-
   to-point link, such as Provider Bridges or Provider Backbone Bridges,
   then the use of the Compact Format will increase the MAC address
   learning table stress on such Provider Bridges or Provider Edge Back
   Bone bridges.



3.1 Conditions for Using Compact Format

   Use of Compact Format is a hop-by-hop decision. In successive RBridge
   to RBridge hops, a TRILL Data frame might be sent alternately in
   Compact Format and General Format.

   There are a number of conditions, listed below, for using Compact
   Format TRILL Data frames. Most of these boil down to maximizing the
   assurance that the RBridge-to-RBridge Ethernet link over which the
   Compact Format TRILL Data frame is to be sent is really point-to-
   point. Only the General Format for TRILL Data frames is safe to use
   on an RBridge Ethernet port that is to a multi-access link even if
   the ports between which it is being sent have been configured as
   point-to-point ports. (See also the frame reception process


R. Perlman, et al                                               [Page 8]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


   variations described in Section 3.3.1.)

   o  The RBridge Ethernet port over which Compact Format TRILL Data
      frames are to be sent MUST be configured as an IS=IS point-to-
      point port (see Section 4.9.1 of [RFC6325]).

   o  The RBridge port through which the Compact Format TRILL Data frame
      is being transmitted MUST be configured to send VLAN/FGL tagged
      frames.  Otherwise the Data Label of the payload will be lost
      (unless it just happens to be the default VLAN ID of the receiving
      port).

   o  The RBridge port at the other end of the link MUST be announcing
      that it supports the Compact Format. See Section 3.4.

   o  Receipt of a native frame indicates that the link is multi-access
      and has end stations on it. These are frames that are not Layer 2
      control frames (see Section 1.4 of [RFC6325]) and have neither an
      Outer.MacDA in the block assigned to TRILL nor an outer payload
      EtherType assigned to/for TRILL (currently the TRILL, L2-IS-IS,
      and RBridge-Channel [RFC7178] EtherTypes). On receipt of such a
      frame, the port MUST stop using Compact Format TRILL Data frames
      for at least ten seconds, unless it is reset by management or
      rebooted before that.

   o  The sending RBridge MUST have exactly one adjacency in the Report
      state on the link and no other adjacencies in any state but Down
      [RFC7177]. Thus, receipt of a TRILL IS-IS Hello frame, other than
      one of the correct type (point-to-point or LAN) from the RBridge
      believed to be at the other end of the link, indicates that the
      link really isn't point-to-point or that the RBridge at the other
      end of that link is mis-behaving. In either case, the RBridge
      receiving such an unexpected Hello MUST stop using Compact Format
      TRILL Data frames on that port for at least twice the holding time
      in the unexpected Hello but not less than ten seconds, unless it
      is reset by management or rebooted before that. This is a change
      to [RFC6325] which states that an RBridge port configured as
      point-to-point ignores LAN Hellos and such a port configured as
      LAN ignores point-to-point Hellos.

   o  RBridge Ethernet ports are required to monitor ports for BPDUs
      received (Section 4.9.3 [RFC6325]). On receipt of a customer
      bridging BPDU at an RBridge port, the RBridge MUST stop using
      Compact Format on that port and revert to sending General Format
      TRILL Data frames for at least four times the Bridge Hello Time in
      the BPDU, but not less than ten seconds, unless the port or
      RBridge is reset by management or rebooted before that.

   o  It is RECOMMENDED that RBridge ports intending to use Compact
      Format also use the Link Layer Discovery Protocol (LLDP) [802.1AB]


R. Perlman, et al                                               [Page 9]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


      to provide additional assurance that the link is actually point-
      to-point. For this use, LLDP should be run to the Nearest Customer
      Bridge MAC address (01-80-C2-00-00-00). Receipt by an RBridge port
      supporting LLDP of an LLDP message indicating the presence on the
      link of a MAC Bridge, Layer 3 Router, or End Station indicates
      that the link is not point-to-point and the RBridge MUST stop
      using Compact Format on the port for at least twice the TTL in the
      received LLDP frame but not less than ten second, unless the port
      or RBridge is reset by management or rebooted before that.



3.2 RBridge Originated and Terminated Native Frames

   There can be native frames originated by or intended for consumption
   by an RBridge. Examples include SNMP over IP frames or RBridge
   Channel frames [RFC7178]. In many cases, such internal sinks and
   sources of native frames are treated as a virtual end-station
   internally attached to the RBridge. Such frames are converted to
   TRILL Data frames before being transmitted outside the originating
   RBridge.

   Because of the way that Compact Format TRILL Data frames are
   recognized, particularly the change in [RFC6325], Section 4.6.2,
   Point 3, made by Section 3.3.1 of this document, an RBridge MUST use
   a MAC address different from the address of any of its ports as the
   Inner.MacSA of frames it locally originates and as the Inner.MacDA it
   expects to see in unicast TRILL Data frames that it receives and
   decapsulates for locally processing.



3.3 Compact TRILL Data Reception and Transmission

   If an RBridge's Ethernet port has Compact Format enabled, frame
   reception and transmission are modified as described below.

   Section 4.6 of the TRILL base protocol standard [RFC6325] provides a
   specification of the processing of all possible types of received
   frames. TRILL frames are any frame starting with the TRILL or L2-IS-
   IS or RBridge-Channel Ethertype or that has an Outer.MacDA that is
   any of the block of 16 multicast addresses assigned to TRILL
   ([RFC6325] Section 7.2).



3.3.1 Compact TRILL Data Frame Reception

   Section 4.6.2 of [RFC6325] specifies the processing of received TRILL
   frames. A complete replacement for Section 4.6.2 of [RFC6325] that


R. Perlman, et al                                              [Page 10]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


   supports Compact Format and incorporates the correction in Section
   5.1.2 of [RFC7780] is provided in the quoted text below.

   Even when Compact Format is enabled, the sender is not required to
   compact all or any TRILL Data frames and a receiver MUST be prepared
   for an arbitrary mix of Compact Format and General Format TRILL Data
   frames arriving on a point-to-point link.

   NOTE: All of the Section references in the quoted text below are
   references to Sections in [RFC6325].

      "A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a
      multicast Outer.MacDA allocated to TRILL (see Section 7.2).  The
      following tests are performed sequentially, and the first that
      matches controls the handling of the frame:"

      "By default a frame is classified as General Format."

       "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either
           All-IS-IS-RBridges or the unicast MAC address of the
           receiving RBridge port, the frame is handled as described in
           Section 4.6.2.1 on TRILL Control frames."

       "2. If the Outer.MacDA is a multicast address allocated to TRILL
           other than All-RBridges then the frame is discarded."

       "3. If the Outer.MacDA is a unicast address other than the
           address of the receiving Rbridge then (3a) if Compact Format
           TRILL Data frames are disabled, the frame is discarded or
           (3b) if Compact Format TRILL Data frames are enabled, the
           frame is classified as compact."

       "4. If the Ethertype is not TRILL, the frame is discarded."

       "5. If the Version field in the TRILL Header is greater than 0,
           the frame is discarded."

       "6. If the hop count is 0, the frame is discarded."

       "7. If the Outer.MacDA is multicast and the M bit is zero the
           frame is discarded.  If the Outer.MacDA is unicast and M bit
           is one processing continues if Specific Addressing is
           enabled. If Specific Addressing is not enabled, the frame is
           discarded."

       "8. If the frame has been classified as Compact Format, skip the
           rest of this rule and go to Rule 9. By default, an RBridge
           MUST discard General Format TRILL Data frames from a
           Outer.MacSA that is not an adjacency on the port where the
           frame was received. RBridges MAY be configured per port to


R. Perlman, et al                                              [Page 11]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


           accept such frames in cases where it is known that a non-
           peering device (such as an end-station) is configured to
           originate general TRILL encapsulated data frames that can be
           safely accepted."

       "9. If a frame has been classified as a Compact Format TRILL Data
           frame but it was received untagged, that is, without an
           Outer.VLAN, discard the frame."

      "10. For all subsequent processing, including Rule 11, if the
           frame has been classified as Compact Format, all references
           to Inner.MacDA, Inner.MacSA, or Inner.VLAN are to be
           understood to actually refer to the Outer.MacDA, Outer.MacSA,
           and Outer.VLAN as the frame was received."

      "11. The Inner.MacDA is then tested. If it is the All-Egress-
           Rbridges (also known as All-ESADI-RBridges) multicast address
           and RBn implements the ESADI protocol, processing proceeds as
           in Section 4.6.2.2 for TRILL ESADI frames. If it is any other
           address or RBn does not implement ESADI, processing proceeds
           as in Section 4.6.2.3 for TRILL Data frames."



3.3.2 Compact TRILL Data Frame Transmission

   When a TRILL Data frame is being transmitted out an RBridge port, if
   the conditions listed in Section 3 above are met, the frame MAY be
   sent in Compact Format.



3.4 Announcing Support for Compact Format

   The Compact Format option is a hop-by-hop optional Ethernet link
   TRILL frame format and it is possible that an RBridge would support
   it on some ports and not others depending, for example, on port
   hardware. Therefore, if Compact Format is enabled at a port, this is
   indicated in every Hello (Section 6) it sends out that port.













R. Perlman, et al                                              [Page 12]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


4. Specific Addressing

   Specific addressing optionally enables more efficient use of some
   types of multi-access links.



4.1 Current Multi-Destination Addressing

   When multiple RBridges are connected to an Ethernet link, the base
   TRILL protocol standard [RFC6325] requires that multi-destination
   TRILL Data frames be sent on the Ethernet link addressed to the All-
   RBridges multicast address.

   If the link is a multi-access link, such as a large bridged LAN, use
   of a multicast address may impose a significant burden, causing the
   frame to be flooded in the bridged LAN. In addition, all or many
   stations attached to the bridged LAN may received the frame using up
   some of their input bandwidth. Those TRILL switches that receive the
   frame but are not the next hop on the frame's distribution tree will
   discard the frame due to the Reverse Path Forwarding Check.



4.2 Specific Addressing Specification

   Multi-destination TRILL Data frames are sent on the distribution tree
   identified in the TRILL Header subject to optional pruning. The
   transmitting RBridge thus knows which next hop RBridge or RBridges on
   the link it needs to get the frame to.

   If the next hop RBridges on the multi-access link and the
   transmitting RBridge all have Specific Addressing enabled, then the
   frame MAY be link unicast to the next hop RBridge or RBridges.

   Use of Specific Addressing is a hop-by-hop optional decision.
   Successive TRILL Data frames received by an RBridge, even from the
   same sending RBridge on the same distribution tree, may be
   specifically (unicast) or multicast addressed. (The same frame is
   never sent both ways.) In successive RBridge to RBridge hops, a
   multi-destination TRILL Data frame might be sent alternately in
   specifically addressed and multicast addressed form.



4.3 Announcing Support for Specific Addressing

   The Specific Addressing option is a hop-by-hop optional format. It is
   possible that an RBridge would support it on some ports and not
   others. Therefore enablement of this option is indicated in every


R. Perlman, et al                                              [Page 13]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


   TRILL Hello (see Section 6) sent on the port.



















































R. Perlman, et al                                              [Page 14]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


5. Interaction Between The Optimizations

   Compact Format can only be used for TRILL Data frames on Ethernet
   links that are point-to-point. Compact Format works under the
   conditions specified above regardless of whether the frame is TRILL
   unicast (M=0) or TRILL multi-destination (M=1). It sets the
   Outer.MacDA, Outer.MacSA, and Outer.VLAN to the corresponding Inner
   fields and removes the Inner fields.

   Specific Addressing is only beneficial for frames that are TRILL
   multi-destination Data frames on multi-access links. Specific
   Addressing causes the frame to be link unicast by setting the
   Outer.MacDA to the unicast address of a next hop RBridge.

   Both optimizations change the Outer.MacDA from its value in the base
   TRILL protocol and thus they conflict. Specific Addressing MUST NOT
   be used on point-to-point Ethernet links. This avoids conflict.



































R. Perlman, et al                                              [Page 15]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


6. IANA Considerations

   IANA is requested to allocate two capability bits in the TRILL-PORT-
   VER sub-TLV [RFC7176] as follows:

      Bit    Description                    Reference
     ====== ============================== =================
      tbd1   Compact Ethernet enabled.      (This document)
      tbd2   Specific addressing enabled.   (This document)











































R. Perlman, et al                                              [Page 16]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


7. Security Considerations

   For general TRILL protocol security considerations, see [RFC6325].
   See other security considerations below.



7.1 Compact Format Security Considerations

   An RBridge conformant to the TRILL standard that has Compact Format
   TRILL Data not implemented or not enabled on a port will, as part of
   its normal procedures, discard any Compact Format TRILL Data frame it
   receives on that port because the EtherType of the frame would be
   TRILL but (1) if the Compact Format resulted in a unicast
   Outer.MacDA, it would not be the address of the receiving RBridge
   port, and (2) if the Compact Format resulted in a multicast or
   broadcast Outer.MacDA, it would not be the All-RBridges multicast
   address. If the RBridge port failed to discard the frame and
   erroneously handled it as being in General Format, bad things will
   usually happen as described in Section 7.3.

   With a General Format TRILL Data frame, the Data Label of the data is
   somewhat protected in the Inner Label field. With Compact Format, it
   is put in the more exposed Outer.VLAN field. If it is stripped,
   perhaps by an intervening bridge, and the frame arrives untagged, the
   rules in this document require that it be discarded to avoid changing
   the labeling of the frame to the default of the receiving RBridge
   port.



7.2 Specific Addressing Security Considerations

   It is important not to apply both Compact Format optimization and
   Specific Addressing optimization to the same frame or else the frame
   may be misinterpreted as described in Section 7.3.  For this reasons,
   use of Specific Addressing on point-to-point links, where it would
   not provide an advantage anyway, is prohibited.



7.3 Results of Frame Misinterpretation

   For frames that are misinterpreted due to circumstances described in
   Sections 7.1 and 7.2, the first six bytes of the native frame content
   will be treated as the Inner.MacDA, the next six bytes of that oontnt
   as the Inner.MacSA, and the next four bytes as the Data Label. If the
   Ethertype or the Data Label is not checked or some of the payload
   data accidentally has the value of a valid tag Ethertype, the payload
   may be delivered in the wrong VLAN violating security policy. For


R. Perlman, et al                                              [Page 17]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


   this reason, the provisions of Sections 3 of this document should be
   scrupulously enforced.


















































R. Perlman, et al                                              [Page 18]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


8. References

   Normative and informative references for this document are given
   below.



8.1 Normative References

   [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area
         networks / Station and Media Access Control Connectivity
         Discovery", IEEE Std 802.1AB-2009, 17 September 2009.

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

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

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
         March 1997, <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
         Ghanwani, "Routing Bridges (RBridges): Base Protocol
         Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
         <http://www.rfc-editor.org/info/rfc6325>.

   [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
         and D. Dutt, "Transparent Interconnection of Lots of Links
         (TRILL): Fine-Grained Labeling", RFC 7172, DOI
         10.17487/RFC7172, May 2014, <http://www.rfc-
         editor.org/info/rfc7172>.

   [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
         D., and A. Banerjee, "Transparent Interconnection of Lots of
         Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176,
         May 2014, <http://www.rfc-editor.org/info/rfc7176>.

   [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
         Ghanwani, A., and S. Gupta, "Transparent Interconnection of
         Lots of Links (TRILL): Clarifications, Corrections, and
         Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
         <http://www.rfc-editor.org/info/rfc7780>.





R. Perlman, et al                                              [Page 19]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


8.2 Informative References

   [802-2014] - IEEE 802, "IEEE Standard for Local and Metropolitan Area
         Networks / Overview and Architecture", 802-2014, 12 June 2014.

   [802.1AE] - IEEE 802, "IEEE Standard for Local and metropolitan area
         networks / Media Access Control (MAC) Security", 802.1AE-2006,
         18 August 2006.

   [802.3] - IEEE, "IEEE Standard for Information technology /
         Telecommunications and information exchange between systems /
         Local and metropolitan area networks / Specific requirements
         Part 3: Carrier sense multiple access with collision detection
         (CSMA/CD) access method and physical layer specifications",
         IEEE Std 802.3-2012, 28 December 2012.

   [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
         Interconnection of Lots of Links (TRILL) Protocol Control
         Protocol", RFC 6361, August 2011.

   [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
         and V. Manral, "Transparent Interconnection of Lots of Links
         (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014,
         <http://www.rfc-editor.org/info/rfc7177>.

   [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
         Ward, "Transparent Interconnection of Lots of Links (TRILL):
         RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May
         2014, <http://www.rfc-editor.org/info/rfc7178>.























R. Perlman, et al                                              [Page 20]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


Authors' Addresses

   Radia Perlman
   EMC
   2010 256th Avenue NE, #200
   Bellevue, WA 98007 USA

   EMail: radia@alum.mit.edu


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

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


   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012, China

   Phone: +86-25-56622310
   Email: liyizhou@huawei.com


   Anoop Ghanwani
   Dell
   350 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-571-3500
   Email: anoop@alumni.duke.edu

















R. Perlman, et al                                              [Page 21]


INTERNET-DRAFT                            TRILL: Link Data Optimizations


Copyright and IPR Provisions

   Copyright (c) 2017 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.





















R. Perlman, et al                                              [Page 22]