RFC 7780
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
Pages: 57
Proposed Standard
Obsoletes: 7180
Updates: 6325 7177 7179
Updated by: 8249
Proposed Standard
Obsoletes: 7180
Updates: 6325 7177 7179
Updated by: 8249
Part 2 of 3 – Pages 18 to 36
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.
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.
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.)
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.
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
[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.
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.
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.
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.
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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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.
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].
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.
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 TLV10. 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
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.
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.
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.
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
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)