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
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
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
The reference to "Section 126.96.36.199" 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
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
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
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  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
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
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
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
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
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
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
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
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
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
(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].
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.
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
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
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
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
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.