Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 7780


Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates

Part 2 of 3, p. 18 to 36
Prev RFC Part     Next RFC Part


prevText      Top      ToC       Page 18 
5.  MTU (Maximum Transmission Unit) (Unchanged)

   MTU values in TRILL are derived from the originatingL1LSPBufferSize
   value communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS].
   The campus-wide value Sz, as described in Section 4.3.1 of [RFC6325],
   is the minimum value of originatingL1LSPBufferSize for the RBridges
   in a campus, but not less than 1470.  The MTU testing mechanism and
   limiting LSPs to Sz assure that the LSPs can be flooded by IS-IS and
   thus that IS-IS can operate properly.

Top      Up      ToC       Page 19 
   If an RBridge knows nothing about the MTU of the links or the
   originatingL1LSPBufferSize of other RBridges in a campus, the
   originatingL1LSPBufferSize for that RBridge should default to the
   minimum of the LSP size that its TRILL IS-IS software can handle and
   the minimum MTU of the ports that it might use to receive or transmit
   LSPs.  If an RBridge does have knowledge of link MTUs or other
   RBridge originatingL1LSPBufferSize, then, to avoid the necessity of
   regenerating the local LSPs using a different maximum size, the
   RBridge's originatingL1LSPBufferSize SHOULD be configured to the
   minimum of (1) the smallest value that other RBridges are, or will
   be, announcing as their originatingL1LSPBufferSize and (2) a value
   small enough that the campus will not partition due to a significant
   number of links with limited MTUs.  However, as specified in
   [RFC6325], in no case can originatingL1LSPBufferSize be less than
   1470.  In a well-configured campus, to minimize any LSP regeneration
   due to resizing, all RBridges will be configured with the same

   Section 5.1 below corrects errata in [RFC6325], and Section 5.2
   clarifies the meaning of various MTU limits for TRILL Ethernet links.

5.1.  MTU-Related Errata in RFC 6325

   Three MTU-related errata in [RFC6325] are corrected in the
   subsections below.

5.1.1.  MTU PDU Addressing

   Section 4.3.2 of [RFC6325] incorrectly states that multi-destination
   MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links
   with the All-RBridges multicast address as the Outer.MacDA [Err3004].
   As TRILL IS-IS PDUs, when multicast on an Ethernet link, these
   multi-destination MTU-probe and MTU-ack PDUs MUST be sent to the
   All-IS-IS-RBridges multicast address.

Top      Up      ToC       Page 20 
5.1.2.  MTU PDU Processing

   As discussed in [RFC6325] and (in more detail) [RFC7177], MTU-probe
   and MTU-ack PDUs MAY be unicast; however, Section 4.6 of [RFC6325]
   erroneously does not allow for this possibility [Err3003].  It is
   corrected by replacing Item 1 in Section 4.6.2 of [RFC6325] with the
   following text, to which TRILL switches MUST conform:

      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

   The reference to "Section" in the above text is to that
   section in [RFC6325].

5.1.3.  MTU Testing

   The last two sentences of Section 4.3.2 of [RFC6325] contain errors
   [Err3053].  They currently read as follows:

      If X is not greater than Sz, then RB1 sets the "failed minimum MTU
      test" flag for RB2 in RB1's Hello.  If size X succeeds, and X >
      Sz, then RB1 advertises the largest tested X for each adjacency in
      the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X
      as an attribute of the link to RB2 in RB1's LSP.

   They should read as follows:

      If X is not greater than or equal to Sz, then RB1 sets the "failed
      minimum MTU test" flag for RB2 in RB1's Hello.  If size X
      succeeds, and X >= Sz, then RB1 advertises the largest tested X
      for each adjacency in the TRILL Hellos RB1 sends on that link,
      and RB1 MAY advertise X as an attribute of the link to RB2 in
      RB1's LSP.

5.2.  Ethernet MTU Values

   originatingL1LSPBufferSize is the maximum permitted size of LSPs
   starting with and including the IS-IS 0x83 "Intradomain Routeing
   Protocol Discriminator" byte.  In Layer 3 IS-IS,
   originatingL1LSPBufferSize defaults to 1492 bytes.  (This is because,
   in its previous life as DECnet Phase V, IS-IS was encoded using the
   SNAP SAP (Subnetwork Access Protocol Service Access Point) [RFC7042]
   format, which takes 8 bytes of overhead and 1492 + 8 = 1500, the
   classic Ethernet maximum.  When standardized by ISO/IEC [IS-IS] to
   use Logical Link Control (LLC) encoding, this default could have been
   increased by a few bytes but was not.)

Top      Up      ToC       Page 21 
   In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes.  This
   allows 27 bytes of headroom or safety margin to accommodate legacy
   devices with the classic Ethernet maximum MTU, despite headers such
   as an Outer.VLAN.

   Assuming that the campus-wide minimum link MTU is Sz, RBridges on
   Ethernet links MUST limit most TRILL IS-IS PDUs so that PDUz (the
   length of the PDU starting just after the L2-IS-IS Ethertype and
   ending just before the Ethernet Frame Check Sequence (FCS)) does not
   exceed Sz.  The PDU exceptions are TRILL Hello PDUs, which MUST NOT
   exceed 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded by
   an amount that depends on the size being tested (which may
   exceed Sz).

   Sz does not limit TRILL Data packets.  They are only limited by the
   MTU of the devices and links that they actually pass through;
   however, links that can accommodate IS-IS PDUs up to Sz would
   accommodate, with a generous safety margin, TRILL Data packet
   payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending
   just before the FCS.

   Most modern Ethernet equipment has ample headroom for frames with
   extensive headers and is sometimes engineered to accommodate 9 KB
   jumbo frames.

6.  TRILL Port Modes (Unchanged)

   Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports
   but may not be completely clear on the effects of all combinations of
   bits in terms of allowed frame types.

Top      Up      ToC       Page 22 
   The table below explicitly indicates the effects of all possible
   combinations of the TRILL port mode bits.  "*" in one of the first
   four columns indicates that the bit can be either zero or one.  The
   remaining columns indicate allowed frame types.  The "disable bit"
   normally disables all frames; however, as an implementation choice,
   some or all low-level Layer 2 control messages can still be sent or
   received.  Examples of Layer 2 control messages are those control
   frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP
   link negotiation messages [RFC6361].

            |D| | | |        |       |       |       |       |
            |i| |A| |        |       | TRILL |       |       |
            |s| |c|T|        |Native | Data  |       |       |
            |a| |c|r|        |Ingress|       |       |       |
            |b|P|e|u|        |       |  LSP  |       |       |
            |l|2|s|n|Layer 2 |Native |  SNP  | TRILL |  P2P  |
            |e|P|s|k|Control |Egress |  MTU  | Hello | Hello |
            |0|0|0|0|  Yes   |  Yes  |  Yes  |  Yes  |  No   |
            |0|0|0|1|  Yes   |  No   |  Yes  |  Yes  |  No   |
            |0|0|1|0|  Yes   |  Yes  |  No   |  Yes  |  No   |
            |0|0|1|1|  Yes   |  No   |  No   |  Yes  |  No   |
            |0|1|0|*|  Yes   |  No   |  Yes  |  No   |  Yes  |
            |0|1|1|*|  Yes   |  No   |  No   |  No   |  Yes  |
            |1|*|*|*|Optional|  No   |  No   |  No   |  No   |

   The formal name of the "access bit" above is the "TRILL traffic
   disable bit".  The formal name of the "trunk bit" is the "end-station
   service disable bit" [RFC6325].

7.  The CFI/DEI Bit (Unchanged)

   In May 2011, the IEEE promulgated IEEE Std 802.1Q-2011, which changed
   the meaning of the bit between the priority and VLAN ID bits in the
   payload of C-VLAN tags.  Previously, this bit was called the CFI
   (Canonical Format Indicator) bit [802] and had a special meaning in
   connection with IEEE 802.5 (Token Ring) frames.  After 802.1Q-2011
   and in subsequent versions of 802.1Q -- the most current of which is

Top      Up      ToC       Page 23 
   [802.1Q-2014] -- this bit is now the DEI (Drop Eligibility Indicator)
   bit.  (The corresponding bit in S-VLAN/B-VLAN tags has always been a
   DEI bit.)

   The TRILL base protocol specification [RFC6325] assumed, in effect,
   that the link by which end stations are connected to TRILL switches
   and the restricted virtual link provided by the TRILL Data packet are
   IEEE 802.3 Ethernet links on which the CFI bit is always zero.
   Should an end station be attached by some other type of link, such as
   a Token Ring link, [RFC6325] implicitly assumed that such frames
   would be canonicalized to 802.3 frames before being ingressed, and
   similarly, on egress, such frames would be converted from 802.3 to
   the appropriate frame type for the link.  Thus, [RFC6325] required
   that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in
   Section 4.1.1 of [RFC6325], always be zero.

   However, for TRILL switches with ports conforming to the change
   incorporated in the IEEE 802.1Q-2011 standard, the bit in the
   Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by
   the port interface on ingressing a native frame.  Similarly, this bit
   MUST be provided to the port when transiting or egressing a TRILL
   Data packet.  As with the 3-bit Priority field, the DEI bit to use in
   forwarding a transit packet MUST be taken from the Inner.VLAN.  The
   exact effect on the Outer.VLAN DEI and priority bits, and whether or
   not an Outer.VLAN appears at all on the wire for output frames, may
   depend on output port configuration.

   TRILL campuses with a mixture of ports, some compliant with versions
   of 802.1Q from IEEE Std 802.1Q-2011 onward and some compliant with
   pre-802.1Q-2011 standards, especially if they have actual Token Ring
   links, may operate incorrectly and may corrupt data, just as a
   bridged LAN with such mixed ports and links would.

8.  Other IS-IS Considerations (Changed)

   This section covers Extended Level 1 Flooding Scope (E-L1FS) support,
   control packet priorities, unknown PDUs, the Nickname Flags
   APPsub-TLV, graceful restart, and the Purge Originator
   Identification TLV.

Top      Up      ToC       Page 24 
8.1.  E-L1FS Support (New)

   TRILL switches MUST support E-L1FS PDUs [RFC7356] and MUST include a
   Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send
   indicating support for this scope and any other FS-LSP scopes that
   they support.  This support increases the number of fragments
   available for link-state information by over two orders of magnitude.
   (See Section 9 for further information on support of the Scope
   Flooding Support TLV.)

   In addition, TRILL switches MUST advertise their support of E-L1FS
   flooding in a TRILL-VER sub-TLV Capability Flag (see [RFC7176] and
   Section 12.2).  This flag is used by a TRILL switch, say RB1, to
   determine support for E-L1FS by some remote RBx.  The alternative of
   simply looking for an E-L1FS FS-LSP originated by RBx fails because
   (1) RBx might support E-L1FS flooding but is not originating any
   E-L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs
   there might, due to legacy TRILL switches in the campus, be no path
   between RBx and RB1 through TRILL switches supporting E-L1FS
   flooding.  If that were the case, no E-L1FS FS-LSP originated by RBx
   could get to RB1.

   E-L1FS will commonly be used to flood TRILL GENINFO TLVs and enclosed
   TRILL APPsub-TLVs [RFC7357].  For robustness, E-L1FS fragment zero
   MUST NOT exceed 1470 bytes in length; however, if such a fragment is
   received that is larger, it is processed normally.  It is anticipated
   that in the future some particularly important TRILL APPsub-TLVs will
   be specified as being flooded in E-L1FS fragment zero.  TRILL GENINFO
   TLVs MUST NOT be sent in LSPs; however, if one is received in an LSP,
   it is processed normally.

8.1.1.  Backward Compatibility

   A TRILL campus might contain TRILL switches supporting E-L1FS
   flooding and legacy TRILL switches that do not support E-L1FS or
   perhaps do not support any [RFC7356] scopes.

   A TRILL switch conformant to this document can always tell which
   adjacent TRILL switches support E-L1FS flooding from the adjacency
   table entries on its ports (see Section 9).  In addition, such a
   TRILL switch can tell which remote TRILL switches in a campus support
   E-L1FS by the presence of a TRILL version sub-TLV in that TRILL
   switch's LSP with the E-L1FS support bit set in the Capabilities
   field; this capability bit is ignored for adjacent TRILL switches for
   which only the adjacency table entry is consulted to determine E-L1FS

Top      Up      ToC       Page 25 
   TRILL specifications making use of E-L1FS MUST specify how situations
   involving a mixed TRILL campus of TRILL switches will be handled.

8.1.2.  E-L1FS Use for Existing (Sub-)TLVs

   In a campus where all TRILL switches support E-L1FS, all TRILL
   sub-TLVs listed in Section 2.3 of [RFC7176], except the TRILL version
   sub-TLV, MAY be advertised by inclusion in Router Capability or
   MT-Capability TLVs in E-L1FS FS-LSPs [RFC7356].  (The TRILL version
   sub-TLV still MUST appear in an LSP fragment zero.)

   In a mixed campus where some TRILL switches support E-L1FS and some
   do not, then only the following four sub-TLVs of those listed in
   Section 2.3 of [RFC7176] can appear in E-L1FS, and then only under
   the conditions discussed below.  In the following list, each sub-TLV
   is preceded by an abbreviated acronym used only in this section of
   this document:

      IV: Interested VLANs and Spanning Tree Roots sub-TLV
      VG: VLAN Group sub-TLV
      IL: Interested Labels and Spanning Tree Roots sub-TLV
      LG: Label Group sub-TLV

   An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an
   E-L1FS FS-LSP (and should instead be advertised in an LSP) unless the
   following conditions are met:

   - E-L1FS is supported by all of the TRILL switches that are data
     reachable from RB1 and are interested in the VLANs mentioned in the
     IV or VG sub-TLV, and

   - there is E-L1FS connectivity between all such TRILL switches in the
     campus interested in the VLANs mentioned in the IV or VG sub-TLV
     (connectivity involving only intermediate TRILL switches that also
     support E-L1FS).

   Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS
   LSPs by any TRILL switch that has enough room in its LSPs.

   The conditions for using E-L1FS for the IL and LG sub-TLVs are the
   same as for IV and VG, but with Fine-Grained Labels [RFC7172]
   substituted for VLANs.

      Note, for example, that the above would permit a contiguous subset
      of the campus that supported Fine-Grained Labels and E-L1FS to use
      E-L1FS to advertise IL and LG sub-TLVs, even if the remainder of
      the campus did not support Fine-Grained Labels or E-L1FS.

Top      Up      ToC       Page 26 
8.2.  Control Packet Priorities (New)

   When deciding what packet to send out a port, control packets used to
   establish and maintain adjacency between TRILL switches SHOULD be
   treated as being in the highest-priority category.  This includes
   TRILL IS-IS Hello and MTU PDUs, and possibly other adjacency
   [RFC7177] or link-technology-specific packets.  Other control and
   data packets SHOULD be given lower priority so that a flood of such
   other packets cannot lead to loss of, or inability to establish,
   adjacency.  Loss of adjacency causes a topology transient that can
   result in reduced throughput; reordering; increased probability of
   loss of data; and, in the worst case, network partition if the
   adjacency is a cut point.

   Other important control packets should be given second-highest
   priority.  Lower priorities should be given to data or less important
   control packets.

   Based on the above, control packets can be ordered into priority
   categories as shown below, based on the relative criticality of these
   types of messages, where the most critical control packets relate to
   the core routing between TRILL switches and the less critical control
   packets are closer to "application" information.  (There may be
   additional control packets, not specifically listed in any category
   below, that SHOULD be handled as being in the most nearly analogous
   category.)  Although few implementations will actually treat these
   four categories with different priority, an implementation MAY choose
   to prioritize more critical messages over less critical.  However, an
   implementation SHOULD NOT send control packets in a lower-priority
   category with a priority above those in a higher-priority category
   because, under sufficiently congested conditions, this could block
   control packets in a higher-priority category, resulting in network

      Category   Description
      --------  --------------

      4.        Hello, MTU-probe, MTU-ack, and other packets critical
                to establishing and maintaining adjacency.  (Normally
                sent with highest priority, which is priority 7.)

      3.        LSPs, CSNPs/PSNPs, and other important control packets.

      2.        Circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.

      1.        Non-circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.

Top      Up      ToC       Page 27 
8.3.  Unknown PDUs (New)

   TRILL switches MUST silently discard [IS-IS] PDUs they receive with
   PDU numbers they do not understand, just as they ignore TLVs and
   sub-TLVs they receive that have unknown Types and sub-Types; however,
   they SHOULD maintain a counter of how many such PDUs have been
   received, on a per-PDU-number basis.  (This is not burdensome, as the
   PDU number is only a 5-bit field.)

      Note: The set of valid [IS-IS] PDUs was stable for so long that
         some IS-IS implementations may treat PDUs with unknown PDU
         numbers as a serious error and, for example, an indication that
         other valid PDUs from the sender are not to be trusted or that
         they should drop adjacency to the sender if it was adjacent.
         However, the MTU-probe and MTU-ack PDUs were added by
         [RFC7176], and now [RFC7356] has added three more new PDUs.
         Although the authors of this document are not aware of any
         Internet-Drafts calling for further PDUs, the eventual addition
         of further new PDUs should not be surprising.

8.4.  Nickname Flags APPsub-TLV (New)

   An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV
   [RFC7357] is specified below.

                           1 1 1 1 1 1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      | Type = NickFlags (6)          |   (2 bytes)
      | Length = 4*K                  |   (2 bytes)
      |   NICKFLAG RECORD 1               (4 bytes)                   |
      |   NICKFLAG RECORD K               (4 bytes)                   |

      where each NICKFLAG RECORD has the following format:

        0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
      |   Nickname                                    |
      |IN|      RESV                                  |

Top      Up      ToC       Page 28 
      o  Type: NickFlags TRILL APPsub-TLV, set to 6 (NICKFLAGS).

      o  Length: 4 times the number of NICKFLAG RECORDS present.

      o  Nickname: A 16-bit TRILL nickname held by the advertising TRILL
         switch ([RFC6325] and Section 4).

      o  IN: Ingress.  If this flag is one, it indicates that the
         advertising TRILL switch may use the nickname in the NICKFLAG
         RECORD as the Ingress Nickname of TRILL Headers it creates.  If
         the flag is zero, that nickname will not be used for that

      o  RESV: Reserved for additional flags to be specified in the
         future.  MUST be sent as zero and ignored on receipt.

   The entire NickFlags APPsub-TLV is ignored if the Length is not a
   multiple of 4.  A NICKFLAG RECORD is ignored if the nickname it lists
   is not a nickname owned by the TRILL switch advertising the enclosing
   NickFlags APPsub-TLV.

   If a TRILL switch intends to use a nickname in the Ingress Nickname
   field of TRILL Headers it constructs, it can advertise this through
   E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry
   with the IN flag set.  If it owns only one nickname, there is no
   reason to do this because, if a TRILL switch advertises no NickFlags
   APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed
   that the TRILL switch might use any or all nicknames it owns as the
   Ingress Nickname in TRILL Headers it constructs.  If a TRILL switch
   advertises any NickFlags APPsub-TLV entries with the IN flag set,
   then it MUST NOT use any other nickname(s) it owns as the Ingress
   Nickname in TRILL Headers it constructs.

   Every reasonable effort should be made to be sure that Nickname
   sub-TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync.  If all
   TRILL switches in a campus support E-L1FS, so that Nickname sub-TLVs
   can be advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and
   any NickFlags APPsub-TLVs for any particular nickname SHOULD be
   advertised in the same fragment.  If they are not in the same
   fragment, then, to the extent practical, all fragments involving
   those sub-TLVs for the same nickname should be propagated as an
   atomic action.  If a TRILL switch sees multiple NickFlags APPsub-TLV
   entries for the same nickname, it assumes that that nickname might be
   used as the ingress in a TRILL Header if any of the NickFlags
   APPsub-TLV entries have the IN bit set.

Top      Up      ToC       Page 29 
   It is possible that a NickFlags APPsub-TLV would not be propagated
   throughout the TRILL campus due to legacy TRILL switches not
   supporting E-L1FS.  In that case, Nickname sub-TLVs MUST be
   advertised in LSPs, and TRILL switches not receiving NickFlags
   APPsub-TLVs having entries with the IN flag set will simply assume
   that the source TRILL switch might use any of its nicknames as the
   ingress in constructing TRILL Headers.  Thus, the use of this
   optional APPsub-TLV is backward compatible with legacy lack of E-L1FS

   (Additional flags are assigned from those labeled RESV above and
   specified in [TRILL-L3-GW] and [Centralized-Replication].)

8.5.  Graceful Restart (Unchanged)

   TRILL switches SHOULD support the features specified in [RFC5306],
   which describes a mechanism for a restarting IS-IS router to signal
   to its neighbors that it is restarting, allowing them to reestablish
   their adjacencies without cycling through the down state, while still
   correctly initiating link-state database synchronization.  If this
   feature is not supported, it may increase the number of topology
   transients caused by a TRILL switch rebooting due to errors or

8.6.  Purge Originator Identification (New)

   To ease debugging of any purge-related problems, TRILL switches
   SHOULD include the Purge Originator Identification TLV [RFC6232] in
   all purge PDUs in TRILL IS-IS.  This includes Flooding Scope LSPs
   [RFC7356] and ESADI LSPs [RFC7357].

Top      Up      ToC       Page 30 
9.  Updates to RFC 7177 (Adjacency) (Changed)

   To support the E-L1FS flooding scope [RFC7356] mandated by
   Section 8.1 and backward compatibility with legacy RBridges not
   supporting E-L1FS flooding, this document updates [RFC7177] as

   1. The list in the second paragraph of Section 3.1 of [RFC7177] is
      updated by adding the following item:

      o  The Scope Flooding Support TLV.

      In addition, the sentence immediately after that list is updated
      by this document to read as follows:

         Of course, (a) the priority, (b) the Desired Designated VLAN,
         (c) the Scope Flooding Support TLV, and whether or not the
         (d) PORT-TRILL-VER sub-TLV and/or (e) BFD-Enabled TLV are
         included, and their value if included, could change on
         occasion.  However, if these change, the new value(s) must
         similarly be used in all TRILL Hellos on the LAN port,
         regardless of VLAN.

   2. This document adds another bullet item to the end of Section 3.2
      of [RFC7177], as follows:

      o  The value from the Scope Flooding Support TLV, or a null string
         if none was included.

   3. Near the bottom of Section 3.3 of [RFC7177], this document adds
      the following bullet item:

      o  The variable-length value part of the Scope Flooding Support
         TLV in the Hello, or a null string if that TLV does not occur
         in the Hello.

   4. At the beginning of Section 4 of [RFC7177], this document adds a
      bullet item to the list, as follows:

      o  The variable-length value part of the Scope Flooding Support
         TLV used in TRILL Hellos sent on the port.

Top      Up      ToC       Page 31 
   5. This document adds a line to Table 4 ("TRILL Hello Contents") in
      Section 8.1 of [RFC7177], as follows:

         LAN  P2P  Number  Content Item
         ---  ---  ------  ---------------------------

          M    M     1      Scope Flooding Support TLV

10.  TRILL Header Update (New)

   The TRILL Header has been updated from its original specification in
   [RFC6325] by [RFC7455] and [RFC7179] and is further updated by this
   document.  The TRILL Header is now as shown in the figure below
   (which is followed by references for all of the fields).  Those
   fields for which the reference is only to [RFC6325] are unchanged
   from that RFC.

                                   | V |A|C|M| RESV  |F| Hop Count |
   |   Egress Nickname             |   Ingress Nickname            |
   :   Optional Flags Word                                         :

   In calculating a TRILL Data packet hash as part of equal-cost
   multipath selection, a TRILL switch MUST ignore the value of the
   "A" and "C" bits.

   In [RFC6325] and [RFC7179], there is a TRILL Header Extension Length
   field called "Op-Length", which is hereby changed to consist of the
   RESV field and "F" bit shown above.

   o  V (Version): 2-bit unsigned integer.  See Section 3.2
      of [RFC6325].

   o  A (Alert): 1 bit.  See [RFC7455].

   o  C (Color): 1 bit.  See Section 10.1.

   o  M (Multi-destination): 1 bit.  See Section 3.4 of [RFC6325].

   o  RESV: 4 bits.  These bits are reserved and MUST be sent as zero.
      Due to the previous use of these bits as specified in [RFC6325],
      most TRILL "fast path" hardware implementations trap and do not
      forward TRILL Data packets with these bits non-zero.  A TRILL

Top      Up      ToC       Page 32 
      switch receiving a TRILL Data packet with any of these bits
      non-zero MUST discard the packet unless the non-zero bit or bits
      have some future use specified that the TRILL switch understands.

   o  F: 1 bit.  If this field is non-zero, then the optional flags word
      described in Section 10.2 is present.  If it is zero, the
      flags word is not present.

   o  Hop Count: 6 bits.  See Section 3.6 of [RFC6325] and
      Section 10.2.1 below.

   o  Egress Nickname: See Section 3.7.1 of [RFC6325].

   o  Ingress Nickname: See Section 3.7.2 of [RFC6325].

   o  Optional Flags Word: See [RFC7179] and Section 10.2.

10.1.  Color Bit

   The Color bit provides an optional way by which ingress TRILL
   switches MAY mark TRILL Data packets for implementation-specific
   purposes.  Transit TRILL switches MUST NOT change this bit.  Transit
   and egress TRILL switches MAY use the Color bit for implementation-
   dependent traffic labeling, or for statistical analysis or other
   types of traffic study or analysis.

10.2.  Flags Word Changes (Update to RFC 7179)

   When the "F" bit in the TRILL Header is non-zero, the first 32 bits
   after the Ingress Nickname field provide additional flags.  These
   bits are as specified in [RFC7179], except as changed by the
   subsections below, in which the Extended Hop Count and Extended Color
   fields are described.  See Section 10.3 for a diagram and summary of
   these fields.

10.2.1.  Extended Hop Count

   The TRILL base protocol [RFC6325] specifies the Hop Count field in
   the header, to avoid packets persisting in the network due to looping
   or the like.  However, the Hop Count field size (6 bits) limits the
   maximum hops a TRILL Data packet can traverse to 64.  Optionally,
   TRILL switches can use a field composed of bits 14 through 16 in the
   flags word, as specified below, to extend this field to 9 bits.  This
   increases the maximum Hop Count to 512.  Except in rare
   circumstances, reliable use of Hop Counts in excess of 64 requires
   support of this optional capability at all TRILL switches along the
   path of a TRILL Data packet.

Top      Up      ToC       Page 33  Advertising Support

   It may be that not all the TRILL switches support the Extended Hop
   Count mechanism in a TRILL campus and in that campus more than
   64 hops are required either for the distribution tree calculated path
   or for the unicast calculated path plus a reasonable allowance for
   alternate pathing.  As such, it is required that TRILL switches
   advertise their support by setting bit 14 in the TRILL Version
   Sub-TLV Capabilities and Header Flags Supported field [RFC7176];
   bits 15 and 16 of that field are now specified as Unassigned (see
   Section 12.2.5).  Ingress Behavior

   If an ingress TRILL switch determines that it should set the
   Hop Count for a TRILL Data packet to 63 or less, then behavior is as
   specified in the TRILL base protocol [RFC6325].  If the optional
   TRILL Header flags word is present, bits 14, 15, and 16 and the
   critical reserved bit of the critical summary bits are zero.

   If the Hop Count for a TRILL Data packet should be set to some value
   greater than 63 but less than 512 and all TRILL switches that the
   packet is reasonably likely to encounter support Extended Hop Count,
   then the resulting TRILL Header has the flags word extension present,
   the high-order 3 bits of the desired Hop Count are stored in the
   Extended Hop Count field in the flags word, the low-order 5 bits are
   stored in the Hop Count field in the first word of the TRILL Header,
   and bit two (the critical reserved bit of the critical summary bits)
   in the flags word is set to one.

   For known unicast traffic (TRILL Header "M" bit zero), an ingress
   TRILL switch discards the frame if it determines that the least-cost
   path to the egress is (1) more than 64 hops and not all TRILL
   switches on that path support the Extended Hop Count feature or
   (2) more than 512 hops.

   For multi-destination traffic, when a TRILL switch determines that
   one or more tree paths from the ingress are more than 64 hops and not
   all TRILL switches in the campus support the Extended Hop Count
   feature, the encapsulation uses a total Hop Count of 63 to obtain at
   least partial distribution of the traffic.  Transit Behavior

   A transit TRILL switch supporting Extended Hop Count behaves like a
   base protocol [RFC6325] TRILL switch in decrementing the Hop Count,
   except that it considers the Hop Count to be a 9-bit field where the
   Extended Hop Count field constitutes the high-order 3 bits.

Top      Up      ToC       Page 34 
   To be more precise: a TRILL switch supporting Extended Hop Count
   takes the first of the following actions that is applicable:

   1. If both the Hop Count and Extended Hop Count fields are zero, the
      packet is discarded.

   2. If the Hop Count is non-zero, it is decremented.  As long as the
      Extended Hop Count is non-zero, no special action is taken.  If
      the result of this decrement is zero, the packet is processed

   3. If the Hop Count is zero, it is set to the maximum value of 63,
      and the Extended Hop Count is decremented.  If this results in the
      Extended Hop Count being zero, the critical reserved bit in the
      critical summary bits is set to zero.  Egress Behavior

   No special behavior is required when egressing a TRILL Data packet
   that uses the Extended Hop Count.  The flags word, if present, is
   removed along with the rest of the TRILL Header during decapsulation.

10.2.2.  Extended Color Field

   Flags word bits 27 and 28 are specified to be a 2-bit Extended Color
   field (see Section 10.3).  These bits are in the non-critical
   ingress-to-egress region of the flags word.

   The Extended Color field provides an optional way by which ingress
   TRILL switches MAY mark TRILL Data packets for implementation-
   specific purposes.  Transit TRILL switches MUST NOT change these
   bits.  Transit and egress TRILL switches MAY use the Extended Color
   bits for implementation-dependent traffic labeling, or for
   statistical analysis or other types of traffic study or analysis.

   Per Section 2.3.1 of [RFC7176], support for these bits is indicated
   by the same bits (27 and 28) in the Capabilities and Header Flags
   Supported field of the TRILL version sub-TLV.  If these bits are zero
   in those capabilities, Extended Color is not supported.  A TRILL
   switch that does not support Extended Color will ignore the
   corresponding bits in any TRILL Header flags word it receives as part
   of a TRILL Data packet and will set those bits to zero in any TRILL
   Header flags word it creates.  A TRILL switch that sets or senses the
   Extended Color field on transmitting or receiving TRILL Data packets
   MUST set the corresponding 2-bit field in the TRILL version sub-TLV
   to a non-zero value.  Any difference in the meaning of the three
   possible non-zero values of this 2-bit capability field (0b01, 0b10,
   or 0b11) is implementation dependent.

Top      Up      ToC       Page 35 
10.3.  Updated Flags Word Summary

   With the changes above, the 32-bit flags word extension to the TRILL
   Header [RFC7179], which is detailed in the "TRILL Extended Header
   Flags" registry on the "Transparent Interconnection of Lots of Links
   (TRILL) Parameters" IANA web page, is now as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
   |C|C|C|       |C|N|         | Ext |       |           |Ext|     |
   |R|R|R|       |R|C|         | Hop |       |           |Clr|     |
   |H|I|R|       |C|C|         | Cnt |       |           |   |     |
   |b|t|s|       |A|A|         |     |       |           |   |     |
   |H|E|v|       |F|F|         |     |       |           |   |     |

   Bits 0, 1, and 2 are the critical summary bits, as specified in
   [RFC7179], consisting of the critical hop-by-hop, critical
   ingress-to-egress, and critical reserved bits, respectively.  The
   next two fields are specific critical and non-critical hop-by-hop
   bits -- CHbH and NCHbH, respectively -- containing the Critical and
   Non-critical Channel Alert flags as specified in [RFC7179].  The next
   field is the critical reserved bits (CRSV), which are specified
   herein to be the Extended Hop Count.  The non-critical reserved bits
   (NCRSV) and the critical ingress-to-egress bits (CItE) as specified
   in [RFC7179] follow.  Finally, there is the non-critical
   ingress-to-egress field, including bits 27 and 28, which are
   specified herein as the Extended Color field.

11.  Appointed Forwarder Status Lost Counter (New)

   Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on
   the value of the Appointed Forwarder Status Lost Counter can result
   in the splitting of Interested VLANs and Spanning Tree Roots sub-TLVs
   [RFC7176] (or the corresponding Interested Labels and Spanning Tree
   Roots sub-TLVs where a VLAN is mapped to an FGL) due to differences
   in this counter value for adjacent VLAN IDs (or 24-bit FGLs).  This
   counter is a mechanism to optimize data-plane learning by trimming
   the expiration timer for learned addresses on a per-VLAN/FGL basis
   under some circumstances.

   The requirement to increment this counter by one whenever a TRILL
   switch loses Appointed Forwarder status on a port is hereby changed
   from the mandatory provisions of [RFC6325] to the enumerated
   provisions below.  To the extent that this might cause the Appointed

Top      Up      ToC       Page 36 
   Forwarder Status Lost Counter to be increased when [RFC6325]
   indicates that it should not, this will cause data-plane address
   learning timeouts at remote TRILL switches to be reduced.  To the
   extent that this might cause the Appointed Forwarder Status Lost
   Counter to remain unchanged when [RFC6325] indicates that it should
   be increased, this will defeat a reduction in such timeouts that
   would otherwise occur.

   (1) If any of the following apply, either data-plane address learning
       is not in use or Appointed Forwarder status is irrelevant.  In
       these cases, the Appointed Forwarder Status Lost Counter MAY be
       left at zero or set to any convenient value such as the value of
       the Appointed Forwarder Status Lost Counter for an adjacent
       VLAN ID or FGL.

       (1a) The TRILL switch port has been configured with the
            "end-station service disable" bit (also known as the
            trunk bit) on.

       (1b) The TRILL switch port has been configured in IS-IS as an
            IS-IS point-to-point link.

       (1c) The TRILL switch is relying on ESADI [RFC7357] or Directory
            Assist [RFC7067] and not using data-plane learning.

   (2) In cases other than those enumerated in point 1 above, the
       Appointed Forwarder Status Lost Counter SHOULD be incremented as
       described in [RFC6325].  Such incrementing has the advantage of
       optimizing data-plane learning.  Alternatively, the value of the
       Appointed Forwarder Status Lost Counter can deviate from that
       value -- for example, to make it match the value for an adjacent
       VLAN ID (or FGL), so as to permit greater aggregation of
       Interested VLANs and Spanning Tree Roots sub-TLVs.

Next RFC Part