Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7780

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

Pages: 57
Proposed Standard
Obsoletes:  7180
Updates:  632571777179
Updated by:  8249
Part 2 of 3 – Pages 18 to 36
First   Prev   Next

Top   ToC   RFC7780 - Page 18   prevText

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   ToC   RFC7780 - 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
   originatingL1LSPBufferSize.

   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   ToC   RFC7780 - 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 Section 4.6.2.1. The reference to "Section 4.6.2.1" 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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 support.
Top   ToC   RFC7780 - 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   ToC   RFC7780 - 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 disruption. Priority 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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
         purpose.

      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   ToC   RFC7780 - 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
   support.

   (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 maintenance.

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   ToC   RFC7780 - 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 follows: 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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   ToC   RFC7780 - Page 33
10.2.1.1. 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).
10.2.1.2. 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.
10.2.1.3. 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   ToC   RFC7780 - 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
      normally.

   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.

10.2.1.4. 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   ToC   RFC7780 - 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   ToC   RFC7780 - 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 page on part 3)

Next Section