RFC 7180

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

📅 published May 2014, from ietf

Part 1 of 6 🎀

Authors: D. Eastlake 3rd, M. Zhang (Huawei), A. Ghanwani (Dell), V. Manral (Ionos Corp.), and A. Banerjee (Cumulus Networks) 🫶 Category: Standards Track 🔥 Date: May 2014 📅 Updates: RFC 6325, RFC 6327, RFC 6439 💅 ISSN: 2070-1721

Abstract 🦋

okay so TRILL (Transparent Interconnection of Lots of Links) is giving least-cost pair-wise forwarding with zero configuration, in multi-hop networks with any topology and any link technology 😭. It stays safe even during temporary loops, and it supports multipathing for both unicast and multicast traffic. Honestly iconic 👑.

TRILL does this with Intermediate System to Intermediate System (IS-IS) link-state routing, and it wraps traffic in a header that includes a hop count. The TRILL base protocol came out in July 2011, and since then active development has uncovered errata in RFC 6325 plus some spots that could use clarifications or updates 🧚.

RFCs 6327 and 6439 already handle the clarifications and updates for adjacency and Appointed Forwarders 💜. This document is the rest of the tea: other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439 ✨.

Status of This Memo 📜

This is an Internet Standards Track document 🌈.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🎀.

Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7180 🌸.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💀.

Table of Contents 🍓

   1. Introduction ....................................................4
      1.1. Precedence .................................................4
      1.2. Changes That Are Not Backward Compatible ...................4
      1.3. Terminology and Acronyms ...................................5
   2. Overloaded and/or Unreachable RBridges ..........................5
      2.1. Reachability ...............................................6
      2.2. Distribution Trees .........................................6
      2.3. Overloaded Receipt of TRILL Data Frames ....................7
           2.3.1. Known Unicast Receipt ...............................7
           2.3.2. Multi-Destination Receipt ...........................7
      2.4. Overloaded Origination of TRILL Data Frames ................7
           2.4.1. Known Unicast Origination ...........................7
           2.4.2. Multi-Destination Origination .......................8
                  2.4.2.1. An Example Network .........................8
                  2.4.2.2. Indicating OOMF Support ....................9
                  2.4.2.3. Using OOMF Service .........................9
   3. Distribution Trees .............................................10
      3.1. Number of Distribution Trees ..............................10
      3.2. Clarification of Distribution Tree Updates ................10
      3.3. Multicast Pruning Based on IP Address .....................10
      3.4. Numbering of Distribution Trees ...........................11
      3.5. Link Cost Directionality ..................................11
   4. Nickname Selection .............................................11
   5. MTU (Maximum Transmission Unit) ................................13
      5.1. MTU-Related Errata in RFC 6325 ............................13
           5.1.1. MTU PDU Addressing .................................14
           5.1.2. MTU PDU Processing .................................14
           5.1.3. MTU Testing ........................................14
      5.2. Ethernet MTU Values .......................................15
   6. Port Modes .....................................................15
   7. The CFI/DEI Bit ................................................16
   8. Graceful Restart ...............................................17
   9. Updates to RFC 6327 ............................................17
   10. Updates on Appointed Forwarders and Inhibition ................18
      10.1. Optional TRILL Hello Reduction ...........................18
      10.2. Overload and Appointed Forwarders ........................20
   11. IANA Considerations ...........................................21
   12. Security Considerations .......................................21
   13. Acknowledgements ..............................................21
   14. References ....................................................22
      14.1. Normative References .....................................22
      14.2. Informative References ...................................23

1. Introduction ✨

okay so TRILL (Transparent Interconnection of Lots of Links) is defined in [RFC6325]. It gives optimal pair-wise data frame forwarding with no configuration, in multi-hop networks with arbitrary topology and link technology 🦋. It stays safe during temporary loops and supports multipathing for both unicast and multicast traffic 💅. TRILL does this with Intermediate System to Intermediate System (IS-IS) [IS-IS] [RFC1195] [RFC7176] link-state routing, and it encapsulates traffic with a header that includes a hop count 🧚. The design also supports VLANs (Virtual Local Area Networks) and optimizes how multi-destination frames are distributed, based on VLANs and IP-derived multicast groups 🌈.

In the years since the TRILL base protocol [RFC6325] was published, active development has revealed five errors in the specification [RFC6325], plus some cases that could use clarifications or updates 🙈.

[RFC6327] and [RFC6439] already provide clarifications on Adjacency and Appointed Forwarders 💜. This document adds the other known clarifications, corrections, and updates to [RFC6325], [RFC6327], and [RFC6439] 🎀.

1.1. Precedence 👑

If this document conflicts with any of [RFC6325], [RFC6327], or [RFC6439], this document wins 💖. Also, Section 1.2 (Normative Content and Precedence) of [RFC6325] is updated to give a more complete precedence ordering for the sections of [RFC6325]. Sections on the left take precedence over sections to their right:

                   4 > 3 > 7 > 5 > 2 > 6 > 1

1.2. Changes That Are Not Backward Compatible 💀

The change made by Section 3.4 below is not backward compatible with [RFC6325]. We adopted it anyway, because it reduces distribution tree changes caused by topology changes 😭.

The several other changes in this document that fix errata for [RFC6325] (that's [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] [Err3508]) may not be backward compatible with earlier implementations that followed the errors in the specification 🫶.

1.3. Terminology and Acronyms 📚

This document uses the acronyms defined in [RFC6325], plus these acronyms and terms:

  • CFI - Canonical Format Indicator [802] 🍓
  • DEI - Drop Eligibility Indicator [802.1Q-2011] 🌸
  • EISS - Enhanced Internal Sublayer Service ✨
  • OOMF - Overload Originated Multi-destination Frame 🦋
  • TRILL Switch - An alternative name for an RBridge 🧚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official BCP 14 words, so read them as [RFC2119] says 🔥.

2. Overloaded and/or Unreachable RBridges 🫠

RBridges can be in overload, which the [IS-IS] overload flag in their LSPs (Link State PDUs) shows. This means either (1) they can't hold the entire link-state database, so they don't have a view of the whole topology, or (2) they've been configured with the overload bit set. Networks should be engineered to avoid actual link-state overload, but it might still happen in various situations. For example, a large campus with one or more low-end TRILL Switches 🏫.

It's a common operational practice to set the overload bit in an [IS-IS] router (such as an RBridge) while doing maintenance that might affect its ability to forward frames correctly. Usually this keeps the router reachable for maintenance traffic, but transit traffic won't be routed through it 🛠️. (Also, in some cases TRILL lets you set the overload bit in the pseudonode of a link to stop TRILL Data traffic on an access link. See Section 4.9.1 of [RFC6325].) 💅

[IS-IS] and TRILL make a reasonable effort to do what they can even when some RBridges/routers are in overload 🙌. They do pretty well if a few scattered nodes are in overload. However, actual least-cost paths are no longer assured if any RBridges are in overload 😬.

For the effect of overload on the appointment of forwarders, see Section 10.2 🎀.

In this Section 2, the term "neighbor" refers only to actual RBridges and ignores pseudonodes 🦋.

2.1. Reachability ✨

Okay so, frames don't get least-cost routed through an overloaded TRILL Switch 💅 but they're totally allowed to start or end at one 🫶. Also, frames won't be least-cost routed over links with cost 2**24 - 1 [RFC5305]. Those links are reserved for traffic-engineered frames, and how those work is beyond the scope of this document 🦋

So, a chunk of the campus can end up unreachable for least-cost routed TRILL Data 😭 That happens when every path to it runs through a link with cost 2**24 - 1 or through an overloaded RBridge. For example, RB1 is not reachable by TRILL Data if all of its neighbors connect to RB1 with links of cost 2**24 - 1. These RBridges are called "data unreachable" 💀

The link-state database at an RBridge RB1 can also hold info about TRILL Switches that IS-IS link-state flooding can't reach because of link or RBridge failures. When failures split the campus, the TRILL Switches next to the failure, on the same side as RB1, will update their LSPs to show they've lost connectivity, and RB1 will get those updates. So RB1 knows about the partition 🧚 Nodes on the far side are both IS-IS unreachable and data unreachable. The tricky part is that LSPs RB1 is holding for TRILL Switches on the far side won't get updated, and they might hang around until they time out. That could be tens of minutes or longer ⏳ (The default in [IS-IS] is twenty minutes.)

2.2. Distribution Trees 🌸

An RBridge in overload can't be trusted to calculate distribution trees correctly, or to do the RPFC (Reverse-Path Forwarding Check) correctly 🙈 So it can't be trusted to forward multi-destination TRILL Data frames either. It can only show up as a leaf node in a TRILL multi-destination distribution tree. And if all of an RBridge's immediate neighbors are overloaded, it gets left out of every tree in the campus and can't be reached by multi-destination frames at all 😭

When an RBridge figures out which nicknames to use as roots for the distribution trees it calculates, it MUST ignore all nicknames held by TRILL Switches that are in overload or are data unreachable 🚫 When calculating RPFCs for multi-destination frames, an RBridge RB1 MAY, to avoid calculating unnecessary RPF check state, ignore any trees that can't reach RB1, even if other RBridges list those trees as trees other TRILL Switches might use. (But see Section 3. 👀)

2.3. Overloaded Receipt of TRILL Data Frames 📨

Here's how an overloaded RBridge RB2 handles receiving TRILL Data frames, broken down in the subsections below. In every case, the normal Hop Count decrement happens, and the TRILL Data frame gets discarded if the result is less than one or if the egress nickname is illegal 🎀

2.3.1. Known Unicast Receipt 💌

RB2 usually won't receive unicast TRILL Data frames unless it's the egress. When that happens, it decapsulates and delivers the frames normally ✨ But if RB2 gets a unicast TRILL Data frame where it isn't the egress, maybe because a neighbor doesn't know yet that RB2 is in overload, RB2 MUST NOT discard the frame just because the egress is an unknown nickname. That's because RB2 might not know about all the nicknames, thanks to its overloaded condition 🥺 If any neighbor other than the one the frame came from is not overloaded, RB2 MUST attempt to forward the frame to one of those neighbors. If there's no such neighbor, the frame gets discarded 🗑️

2.3.2. Multi-Destination Receipt 📣

If an RB2 in overload gets a multi-destination TRILL Data frame, RB2 MUST NOT apply an RPFC, because with overload it might not do it correctly 🙅‍♀️ RB2 decapsulates and delivers the frame locally where it's the Appointed Forwarder for the frame's VLAN, subject to any multicast pruning. But as we said above, RB2 can only be the leaf of a distribution tree, so it MUST NOT forward a multi-destination TRILL Data frame (except as an egressed native frame where RB2 is Appointed Forwarder) 🌈

2.4. Overloaded Origination of TRILL Data Frames 🚀

Overloaded origination of unicast frames with a known egress, and of multi-destination frames, get covered in the subsections below.

2.4.1. Known Unicast Origination 🦄

When an overloaded RBridge RB2 ingresses or creates a known destination unicast TRILL Data frame, it delivers it locally if the destination Media Access Control (MAC) is local. Otherwise, RB2 unicasts it to any neighbor TRILL Switch that isn't overloaded. It MAY use whatever routing info it has to help pick that neighbor 🧭

2.4.2. Multi-Destination Origination 🎉

When an overloaded RBridge RB2 ingresses or creates a multi-destination TRILL Data frame, it's a lot more complicated than a known unicast frame. Buckle up 🎢

2.4.2.1. An Example Network 🗺️

Let's look at an example. For simplicity, the network below doesn't show end stations or any bridges 🙈 There's one distribution tree, with RB4 as its root, shown with double lines. Only RBridge RB2 is overloaded.

         +-----+    +-----+     +-----+     +-----+
         | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
         +-----+    +--+--+     +-++--+     +--+--|
                       |          ||           |
                   +---+---+      ||           |
            +------+RB2(ov)|======++           |
            |      +-------+      ||           |
            |                     ||           |
         +--+--+     +-----+  ++==++=++     +--+--+
         | RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 |
         +-----+     +-----+  ++=====++     +-----+

Since RB2 is overloaded, it doesn't know what the distribution tree or trees are for the network. So there's no way it can give normal TRILL Data encapsulation for multi-destination native frames 😭 Instead, RB2 tunnels the frame to a neighbor that isn't overloaded, as long as that neighbor has signaled that it's willing to offer this service. RBridges say so in their Hellos, as described below. This service is called OOMF (Overload Originated Multi-destination Frame) service 💖

  • The multi-destination frame MUST NOT be locally distributed in native form at RB2 before tunneling to a neighbor, because that would make the frame get delivered twice 🙃 For example, say RB2 locally distributed a multicast native frame and then tunneled it to RB5. RB2 would get a copy of the frame when RB3 transmitted it as a TRILL Data frame on the multi-access RB2-RB3-RB4 link. RB2 generally couldn't tell it was a frame it had tunneled for distribution, so it would decapsulate it and locally distribute it a second time 💀
  • On the other hand, if none of RB2's neighbors offer RB2 the OOMF service, RB2 can't tunnel the frame to a neighbor. In this case, RB2 MUST locally distribute the frame where it's the Appointed Forwarder for the frame's VLAN, and optionally subject to multicast pruning 🫡

2.4.2.2. Indicating OOMF Support 📢

RB3 says it's willing to offer the OOMF service to RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos. It does this by setting a bit tied to RB2's SNPA (Subnetwork Point of Attachment, also known as the MAC address) on the link. (See Section 11. 📖) Overloaded RBridge RB2 can only distribute multi-destination TRILL Data frames to the campus if a neighbor of RB2 that isn't in overload offers RB2 the OOMF service. If RB2 doesn't have OOMF service available, it can still receive multi-destination frames from non-overloaded neighbors. And if RB2 originates or ingresses such a frame, it distributes it locally in native form 🌸

2.4.2.3. Using OOMF Service 🦋

If RB2 sees the OOMF (Overload Originated Multi-destination Frame) service advertised for it by any of its neighbors, on any link it connects to, it picks one of those neighbors using a means beyond the scope of this document 🎯 Say RB2 picks RB3 to handle the multi-destination frames it originates. RB2 MUST advertise in its LSP that it might use any of the distribution trees RB3 advertises, so the RPFC works in the rest of the campus. So even though it's overloaded, RB2 MUST retain this information from RB3's LSPs, which it'll receive because it's directly connected to RB3 🔗

RB2 then encapsulates these frames as TRILL Data frames to RB3 like this: M bit = 0, Hop Count = 2, ingress nickname = a nickname held by RB2, and, since RB2 can't tell which distribution tree RB3 will use, egress nickname = a special nickname that indicates an OOMF frame (see Section 11 🧾). RB2 then unicasts this TRILL Data frame to RB3. (Implementation of Item 4 in Section 4 below gives reasonable assurance that, even though RB2 is overloaded, the ingress nickname it uses will be unique within at least the part of the campus that's IS-IS reachable from RB2 ✨)

When RB3 gets a frame like this, it does the following 🧚

  • changes the Egress Nickname field to designate a distribution tree that RB3 normally uses,
  • sets the M bit to one,
  • changes the Hop Count to the value it would normally use if it were the ingress, and
  • forwards the frame on that tree.

RB3 MAY rate limit how many frames it provides this service for, by discarding some of the frames from RB2 💅 Even a limited amount of bandwidth for OOMFs from RB3, maybe through the slow path, can be super important for getting services at RB2, or at end stations connected to RB2, off the ground. Things like DHCP and ARP/ND (Address Resolution Protocol / Neighbor Discovery) are examples 🙌 (Everyone sometimes needs a little OOMF, pronounced "oomph," to get off the ground. 💜)

3. Distribution Trees 🌳

Two corrections, one clarification, and two updates related to distribution trees show up in the subsections below. See also Section 2.2 👀

3.1. Number of Distribution Trees 🔢

In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052] 🙅‍♀️ It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)".

3.2. Clarification of Distribution Tree Updates 🔄

When a link-state database change causes a change in the distribution tree or trees, there are a few possibilities 🤔 If a tree root stays a tree root but the tree changes, then local forwarding and RPFC entries for that tree should be updated as soon as practical. Similarly, if a new nickname becomes a tree root, forwarding and RPFC entries for the new tree should be installed as soon as practical ✨ But if a nickname stops being a tree root and there's enough room in local tables, the forwarding and RPFC entries for the former tree MAY be kept. That way, any multi-destination TRILL Data frames already in flight on that tree have a better chance of getting delivered 🦢

3.3. Multicast Pruning Based on IP Address 🌸

okay so the TRILL base spec [RFC6325] already gives you pruning of multi-destination frame distribution trees based on where the IP multicast routers and listeners are, and it even recommends doing it 🫶 but here's the catch: multicast listening gets identified by derived MAC addresses, the way the Group MAC Address sub-TLV [RFC7176] communicates them 🧚

TRILL Switches MAY communicate multicast listeners and prune distribution trees based on the actual IPv4 or IPv6 multicast addresses involved ✨ The extra Group Address sub-TLVs in [RFC7176] are there to carry that info. A TRILL Switch that can only prune based on derived MAC addresses SHOULD calculate those derived MAC addresses from the multicast listener IPv4/IPv6 address information it gets, and then use them 💅

3.4. Numbering of Distribution Trees 🦋

so Section 4.5.1 of [RFC6325] says that when you build distribution tree number j, a node (RBridge) N with multiple possible parents gets attached to possible parent number j mod p. The catch is that trees start counting at 1 but parents start counting at 0 🙈 So with two trees and two possible parents, tree 1 picks parent 1, and tree 2 picks parent 0. the math is giving chaos, bestie 💀

this gets changed so the selected parent MUST be (j-1) mod p. Now, in that same example, tree 1 picks parent 0 and tree 2 picks parent 1, which is so much cleaner 🎀 BUT this change is not backward compatible with [RFC6325] 😭 if all the RBridges in a campus don't work out distribution trees the same way, then for most topologies the RPFC will drop a lot of multi-destination frames before they've actually been delivered. not a vibe!

ok this one is lowkey important. Distribution tree construction, like the rest of TRILL's least-cost stuff, still works even when link costs are asymmetric. So the cost of the hop from RB1 to RB2 can be different from the cost of the hop from RB2 to RB1 🦋 BUT it's essential that all RBridges calculate the same distribution trees, which means they all have to use either the cost away from the tree root or the cost towards the tree root. no mixing 🙅‍♀️

Now, the text in Section 4.5.1 of [RFC6325] is incorrect, and [Err3508] caught it 👑 The original says:

   In other words, the set of potential parents for N, for the tree
   rooted at R, consists of those that give equally minimal cost
   paths from N to R and ...

but it should actually say "from R to N":

   In other words, the set of potential parents for N, for the tree
   rooted at R, consists of those that give equally minimal cost
   paths from R to N and ...

4. Nickname Selection 💖

Nickname selection is covered by Section 3.7.3 of [RFC6325] ✨ but there are a few things you need to know, so let's go:

  1. okay so the second sentence in the second bullet item in Section 3.7.3 of [RFC6325] on page 25 is erroneous [Err3002] 😭 It gets corrected like this:
    • the occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
    • the occurrence of "IS-IS System ID" is replaced with "seven-byte IS-IS ID (LAN ID)".

and the fixed sentence in [RFC6325] reads like this:

   If RB1 chooses nickname x, and RB1 discovers, through receipt
   of an LSP for RB2 at any later time, that RB2 has also chosen
   x, then the RBridge or pseudonode with the numerically higher
   priority keeps the nickname, or if there is a tie in priority,
   the RBridge with the numerically higher seven-byte IS-IS ID
   (LAN ID) keeps the nickname, and the other RBridge MUST select
   a new nickname.
  1. when you're checking the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL Switches MUST be ignored 🙈 BUT nicknames held by IS-IS reachable TRILL Switches MUST NOT be ignored, even if they're data unreachable. the vibe is "don't skip the ones that are actually around" 🫶
  2. an RBridge might need to pick a new nickname, either at the start because it doesn't have one, or because of a conflict 💅 When it does, it MUST consider as available all nicknames that don't show up in its link-state database, or that seem to be held by IS-IS unreachable TRILL Switches. However, it SHOULD give preference to nicknames that don't appear to be held by any TRILL Switch in the campus (reachable or unreachable). that way there are fewer conflicts if the IS-IS unreachable ones become reachable later 🧚
  3. even after an RBridge has a nickname that doesn't seem to have any conflicting claimant, it MUST keep watching for conflicts 👀 It does this by checking the LSP PDUs it receives that should update its link-state database, looking for any of its nicknames being held with higher priority by some other TRILL Switch that's IS-IS reachable from it. if it finds one, it MUST select a new nickname, even when it's in the overloaded state. (fun fact: it's possible to receive an LSP that should update the link-state database but doesn't, because of overload 🌸)
  4. in the very unlikely case that an RBridge can't get a nickname because all valid RBridge nicknames (0x0001 through 0xFFBF inclusive) are in use with higher priority by IS-IS reachable TRILL Switches, it can't act as an ingress, egress, or tree root 😭 but it can still function as a transit TRILL Switch ✨ Even though it can't be a tree root, this RBridge still gets included in distribution trees computed for the campus, unless all its neighbors are overloaded. It also wouldn't be possible to send a unicast RBridge Channel message specifically to it [RFC7178]. however, it will still receive unicast Channel messages that a neighbor sends to the Any-RBridge egress nickname, and it'll receive the appropriate multi-destination Channel messages 🦋

5. MTU (Maximum Transmission Unit) 🍓

okay MTU values in TRILL key off the originatingL1LSPBufferSize value, which is communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS] 🌈 The campus-wide value Sz (described in Section 4.3.1 of [RFC6325]) is the minimum originatingL1LSPBufferSize for the RBridges in a campus, but never less than 1470 🫶 The MTU testing mechanism plus limiting LSPs to Sz is what makes sure the LSPs can get flooded by IS-IS, so IS-IS can keep operating properly 💖

if you don't know anything about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, then an RBridge's originatingL1LSPBufferSize should default to the smaller of two things: the LSP size its TRILL IS-IS software can handle, and the minimum MTU of the ports it might use to receive or transmit LSPs 🧚 If an RBridge does know about link MTUs or other RBridges' originatingL1LSPBufferSize, then, so it doesn't have to regenerate its local LSPs with a different maximum size, its originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) the smallest value other RBridges are or will be announcing as their originatingL1LSPBufferSize, and (2) a value small enough that the campus won't partition because of a big number of links with limited MTU 👑 Still, as [RFC6325] provides, originatingL1LSPBufferSize can never be less than 1470 🙅‍♀️ In a well-configured campus, it's desirable for all RBridges to be configured with the same originatingL1LSPBufferSize, so there's less LSP regeneration from re-sizing ✨

Section 5.1 below corrects errata in [RFC6325], and Section 5.2 clarifies what the various MTU limits mean for TRILL Ethernet links 🎀

Three MTU-related errata in [RFC6325] get fixed in the subsections below 🔥

5.1.1. MTU PDU Addressing 🌸

Section 4.3.2 of [RFC6325] incorrectly says 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] 😭 When they're multicast on an Ethernet link as TRILL IS-IS PDUs, they 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 in [RFC6327], MTU-probe and MTU-ack PDUs MAY be unicast. however, Section 4.6 of [RFC6325] erroneously doesn't allow for that possibility [Err3003] 🙈 The fix is to replace Item numbered "1" in Section 4.6.2 of [RFC6325] with the following quoted text, which TRILL Switches MUST conform to:

"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 that quote points to that section in [RFC6325] 🧚

5.1.3. MTU Testing 💖

the last two sentences of Section 4.3.2 of [RFC6325] have errors [Err3053] 😭 They currently read:

   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.

and they should read:

   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 that start with the 0x83 Intradomain Routeing Protocol Discriminator byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 bytes. (This is because, back in its previous life as DECnet Phase V, IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol Service Access Point) format [RFC7042], which takes 8 bytes of overhead, and 1492 + 8 = 1500, the classic Ethernet maximum. When it was standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) encoding, this default could have been bumped up by a few bytes, but it wasn't 🙃)

In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes 💅 That leaves 27 bytes of headroom, or safety margin, so legacy devices with the classic Ethernet maximum MTU can handle things like an Outer.VLAN without a problem ✨

Assuming 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 exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded depending on the size being tested (which may exceed Sz) 🌸

Sz doesn't limit TRILL Data frames! They're only limited by the MTU of the devices and links they actually pass through 🔥 Links that can handle IS-IS PDUs up to Sz would handle, with a generous safety margin, TRILL Data frame payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS. Most modern Ethernet equipment has loads of headroom for frames with extensive headers, and it's often engineered to handle 9K byte jumbo frames 🧚

6. Port Modes 🦋

Okay so Section 4.9.1 of [RFC6325] gives RBridge ports four mode bits, but it's kinda vague about what happens when you mix them together. 🙈 This section fixes that by spelling out the effect of every combination. 💅

In the table, a * in one of the first four columns means that bit can be zero or one. The remaining columns show which frame types are allowed. The Disable bit normally turns off all frames. As an implementation choice, though, some or all of the low-level Layer 2 control frames (see [RFC6325], Section 1.4) can still be sent or received. ✨

            +-+-+-+-+--------+-------+-----+-----+-----+
            |D| | | |        |       |     |     |     |
            |i| |A| |        |       |TRILL|     |     |
            |s| |c|T|        |       |Data |     |     |
            |a| |c|r|        |       |     |     |     |
            |b|P|e|u|        |native | LSP |     |     |
            |l|2|s|n|Layer 2 |ingress| 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  |
            +-+-+-+-+--------+-------+-----+-----+-----+

Quick side note on names 🍓: the "access bit" is formally the "TRILL traffic disable bit", and the "trunk bit" is formally the "end-station service disable bit" [RFC6325]. Same bits, fancier names. 💜

7. The CFI/DEI Bit 🎀

Okay, this one is a whole plot twist 😭. In May 2011, the IEEE dropped [802.1Q-2011], which changes what the bit between the priority and VLAN ID bits in the payload of C-VLAN tags means. Before that, it was called the CFI (Canonical Format Indicator) bit [802] and had a special job with IEEE 802.5 (Token Ring) frames. Now, under [802.1Q-2011], it's a DEI (Drop Eligibility Indicator) bit, which is like the bit in S-VLAN/B-VLAN tags that has always been a DEI bit. 🌈

The TRILL base protocol specification [RFC6325] basically assumed that the link connecting end stations to TRILL Switches, and the restricted virtual link provided by the TRILL Data frame, were IEEE 802.3 Ethernet links where the CFI bit is always zero. 🙌 If an end station was attached by some other kind of link, like a Token Ring link, [RFC6325] implicitly assumed those frames would be canonicalized to 802.3 frames before ingress. On egress, they'd be converted from 802.3 back to the right frame type for the link. So [RFC6325] required that the CFI bit in the Inner.VLAN, shown as the "C" bit in Section 4.1.1 of [RFC6325], always be zero. 💅

Now here's the glow-up ✨. For TRILL Switches with ports that follow the change 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 EISS (Enhanced Internal Sublayer Service) interface when a native frame is ingressed. Similarly, this bit MUST be provided to the EISS when transiting or egressing a TRILL Data frame. Just like the 3-bit Priority field, the DEI bit used when forwarding a transit frame MUST be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI and priority bits, and on whether an Outer.VLAN shows up on the wire for output frames at all, may depend on output port configuration. 🫶

⚠️ Heads up, bestie: TRILL campuses that mix ports compliant with [802.1Q-2011] and ports compliant with pre-802.1Q-2011 standards, especially if they have actual Token Ring links, may operate incorrectly and may corrupt data. That's the same thing that would happen to a bridged LAN with those mixed ports and links. 😭🔥

8. Graceful Restart 🧚

TRILL Switches SHOULD support the features specified in [RFC5306]. That RFC describes a way for a restarting IS-IS router to tell its neighbors it's restarting, so they can re-establish their adjacencies without going through the down state, while still correctly starting link-state database synchronization. It's giving "I'll be right back" energy, but make it networking. 🌸

9. Updates to RFC 6327 🌸

Okay so [RFC6327] lets two TRILL Switches have multiple states for a potential adjacency between them. It makes clear that only an adjacency in the "Report" state gets reported in LSPs. LSP synchronization (LSP and Subnetwork Point (SNP) transmission and receipt), however, happens if and only if there is at least one adjacency on the link in either the "2-Way" or "Report" state. 🦋

To support the PORT-TRILL-VER sub-TLV specified in [RFC7176], the following updates are made to [RFC6327]:

  1. The first sentence of the last paragraph in [RFC6327] Section 3.1 changes. It goes from this:
All TRILL LAN Hellos issued by an RBridge on a particular port
MUST have the same source MAC address, priority, desired
Designated VLAN, and Port ID, regardless of the VLAN in which
the Hello is sent.

to this:

All TRILL LAN Hellos issued by an RBridge on a particular port
MUST have the same source MAC address, priority, desired
Designated VLAN, Port ID, and PORT-TRILL-VER sub-TLV [RFC7176]
if included, regardless of the VLAN in which the Hello is
sent.
  1. An extra bullet gets added to the end of Section 3.2 of [RFC6327]:
o  The five bytes of PORT-TRILL-VER sub-TLV data received in the
   most recent TRILL Hello from the neighbor RBridge.
  1. In Section 3.3 of [RFC6327], near the bottom of page 12, this bullet gets added:
o  The five bytes of PORT-TRILL-VER sub-TLV data are set from
   that sub-TLV in the Hello or set to zero if that sub-TLV does
   not occur in the Hello.
  1. At the beginning of Section 4 of [RFC6327], this bullet gets added to the list:
o  The five bytes of PORT-TRILL-VER sub-TLV data used in TRILL
   Hellos sent on the port.

10. Updates on Appointed Forwarders and Inhibition ✨

Last but not least 💖. An optional method of Hello reduction is specified in Section 10.1 below, and a recommendation on forwarder appointments when things get overloaded is given in Section 10.2. 👑

10.1. Optional TRILL Hello Reduction

okay so bestie, if a network manager is super confident they know how the bridges, ports, and everything else on a link are configured, they might be able to send fewer TRILL Hellos on that link 🦋. Like, if every RBridge on the link sees every Hello no matter the VLAN constraints, the Hellos could go out on fewer VLANs. BUT adjacencies get established in the Designated VLAN, so an RBridge MUST always attempt to send Hellos in the Designated VLAN 💅. Hello reduction makes TRILL less robust when VLAN connectivity drops, like partitioned VLANs, lots of VLANs disabled on ports, or people disagreeing about the Designated VLAN 😭. As long as all RBridge ports on the link are set up for the same desired Designated VLAN, can see each other's frames in that VLAN, and use the mechanisms below to update VLAN inhibition timers, it's safe 🫶.

(These worries don't even come up on point-to-point links! Each RBridge there only sends point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames in what it believes is the Designated VLAN of the link, and no native frame end-station service is provided.)

The "Announcing VLANs" thing, described in Section 4.4.3 of [RFC6325], is already a built-in way the TRILL base protocol can cut down on Hellos 🌸.

To keep loop safety when frames get lost now and then, or when RBridges fail, links fail, or new RBridges pop up on a link, the inhibition mechanism in [RFC6439] is still required 🧚. Under Section 3 of [RFC6439], a VLAN inhibition timer can only be set by receiving a Hello that was sent or received in that VLAN. So sending fewer Hellos on fewer VLANs needs extra mechanisms to set the VLAN inhibition timers at an RBridge, which extends Section 3, Item 4, of [RFC6439]. Two of those mechanisms are specified below 💜. Support for both is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (see Section 9 above and [RFC7176]). It may be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the set recommended in [RFC6325] on a link, unless all of its adjacencies on that link (excluding those in the Down state [RFC6327]) support these mechanisms and the mechanisms are actually in use.

  1. An RBridge RB2 MAY include in any TRILL Hello an Appointed Forwarders sub-TLV [RFC7176] appointing itself for one or more ranges of VLANs ✨. The Appointee Nickname field(s) in the Appointed Forwarders sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hello. This tells everyone the sending RBridge thinks it's the Appointed Forwarder for those VLANs. When an RBridge gets one of these sub-TLVs, it sets each of its VLAN inhibition timers for every VLAN in the block or blocks listed to the maximum of its current value and the Holding Time of the Hello containing the sub-TLV. This is backward compatible, because these sub-TLVs have no effect on any receiving RBridge that doesn't implement this mechanism, unless RB2 is the DRB (Designated RBridge) sending Hello on the Designated VLAN. In that case, as specified in [RFC6439], RB2 MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link 👑.
  2. An RBridge MAY use the new VLANs Appointed sub-TLV [RFC7176] 🎀. When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all the VLANs that RB2 lists in that sub-TLV as VLANs where RB2 is Appointed Forwarder. Each of those timers gets updated to the maximum of its current value and the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV. RBridges that don't implement it will see this sub-TLV as unknown and just ignore it. Even if a TRILL Hello sent by the DRB on the Designated VLAN includes one or more VLANs Appointed sub-TLVs, as long as no Appointed Forwarders sub-TLVs show up, the Hello doesn't have to list all forwarder appointments 🍓.

Two different encodings are provided above for listing VLANs efficiently. Big blocks of contiguous VLANs are more efficient with the Appointed Forwarders sub-TLV, and scattered VLANs are more efficient with the VLANs Appointed sub-TLV. You can mix these encodings in the same Hello 🌈. Using these sub-TLVs doesn't change the rule that the "AF" bit in the Special VLANs and Flags sub-TLV MUST be set if the originating RBridge believes it is the Appointed Forwarder for the VLAN the Hello is sent in. And if these mechanisms are used on a link, each RBridge on the link MUST send Hellos in one or more VLANs, with VLANs Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), and the "AF" bit MUST be set appropriately. That way no VLAN inhibition timer will expire improperly unless three or more Hellos are lost 😭. For example, an RBridge could announce all the VLANs it thinks it's Appointed Forwarder for in a Hello sent on the Designated VLAN three times per Holding Time.

10.2. Overload and Appointed Forwarders

An RBridge in overload (see Section 2) will, generally speaking, do a worse job of ingressing and forwarding frames than an RBridge that's not overloaded and has full knowledge of the campus topology 🥀. For example, an overloaded RBridge may not be able to distribute multi-destination TRILL Data frames at all.

So the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder unless there's no alternative 🙈. And if an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign its VLANs to another RBridge on the link that isn't overloaded, if one is available. DRB election isn't affected by overload at all ✨.

Here's a counter-example: say all campus end stations in VLAN-x are on links attached to RB1 via ports where VLAN-x is enabled. In that case, RB1 SHOULD be made the VLAN-x Appointed Forwarder on all such links, even if RB1 is overloaded 🔥.

11. IANA Considerations ✨

The following IANA actions have been completed 🌸.

  1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame).
  2. Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL Switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service".
  3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in Section 10.1. The description of this bit is "Hello reduction support" 💖.

12. Security Considerations 🔥

This memo improves the documentation of the TRILL protocol, corrects five errata in [RFC6325], and updates [RFC6325], [RFC6327], and [RFC6439]. It does not change the security considerations of these RFCs 🛡️.

13. Acknowledgements 🫶

The contributions of the following individuals are gratefully acknowledged: Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Mike Shand, Meral Shirazipour, and Varun Varshah. Thank you all, you're literally the reason this works 💜✨.

14. References 📚

14.1. Normative References

  • [802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
  • [IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
  • [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
  • [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
  • [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
  • [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
  • [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
  • [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.

14.2. Informative References

Authors' Addresses ✨

okay bestie, here are the people who wrote this doc and how to reach them 🫶 these are the contact deets, no cap 💅

Donald Eastlake 3rd is the first author 🌸

   Donald Eastlake 3rd
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757
   USA

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

Next up is Mingui Zhang at Huawei Technologies 🦋

   Mingui Zhang
   Huawei Technologies Co., Ltd
   Huawei Building, No.156 Beiqing Rd.
   Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District,
   Beijing 100095
   P.R. China

   EMail: zhangmingui@huawei.com

Then we have Anoop Ghanwani over at Dell 🧚

   Anoop Ghanwani
   Dell
   5450 Great America Parkway
   Santa Clara, CA  95054
   USA

   EMail: anoop@alumni.duke.edu

And last but never least, Vishwas Manral at Ionos Corp. 🍓

   Vishwas Manral
   Ionos Corp.
   4100 Moorpark Ave.
   San Jose, CA  95117
   USA

   EMail: vishwas@ionosnetworks.com

Finally, Ayan Banerjee at Cumulus Networks 👑

   Ayan Banerjee
   Cumulus Networks
   1089 West Evelyn Avenue
   Sunnyvale, CA 94086
   USA

   EMail: ayabaner@gmail.com

that's the whole squad, periodt 🌈✨

📦 where this page comes from