RFC 6439

Routing Bridges (RBridges): Appointed Forwarders

📅 published November 2011, from ietf

RFC 6439: Routing Bridges (RBridges): Appointed Forwarders ✨

  • Who wrote it: R. Perlman (Intel Labs), D. Eastlake 3rd, Y. Li (Huawei Technologies), A. Banerjee (Cisco Systems), and F. Hu (ZTE Corporation) 🫶
  • Category: Standards Track 🎀
  • Date: November 2011 📅
  • Updates: RFC 6325 🔥
  • Obsoletes: nothing listed in its title block 🙈
  • ISSN: 2070-1721 💜

Abstract

okay so TRILL (TRansparent Interconnection of Lots of Links) is the protocol that gives you least cost pair-wise data forwarding with zero configuration in multi-hop networks with arbitrary topology 🌈 it also keeps forwarding safe even during temporary loops, and it supports multipathing for both unicast and multicast traffic. it's giving main character energy 💅 TRILL does this with IS-IS (Intermediate System to Intermediate System) link state routing, and it wraps traffic in a header that carries a hop count. devices that run TRILL are called "RBridges" (Routing Bridges) ✨

TRILL works with multi-access LAN (Local Area Network) links, which can have lots of end stations and RBridges plugged in 🦋 when several RBridges sit on the same link, the native traffic going to and from those end stations gets handled by a subset of them, called "Appointed Forwarders" 🧚 the goal is that native traffic in each VLAN (Virtual LAN) gets handled by at most one RBridge, so nobody's stepping on anybody's toes 💖 this document exists to improve the documentation of the Appointed Forwarder mechanism, so it updates RFC 6325 📚

Status of This Memo

this is an Internet Standards Track document 🌸

it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it got 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 ✨

for the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6439 🫶

Copyright (c) 2011 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 they stood on the date of publication. please read these carefully, because they spell out your rights and restrictions 🙈 and if you pull Code Components out of this document, they must include the Simplified BSD License text 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 ....................................................2
      1.1. Terminology and Acronyms ...................................3
   2. Appointed Forwarders and Their Appointment ......................4
      2.1. Appointment Effects of DRB Elections .......................5
      2.2. Appointment and Removal by the DRB .........................5
           2.2.1. Processing Forwarder Appointments ...................6
           2.2.2. Frequency of Appointments ...........................7
           2.2.3. Appointed Forwarders Limit ..........................8
      2.3. Local Configuration Action Appointment Effects .............8
      2.4. VLAN Mapping within a Link .................................9
   3. The Inhibition Mechanism ........................................9
   4. Inhibited Appointed Forwarder Behavior .........................11
   5. Multiple Ports on the Same Link ................................12
   6. Security Considerations ........................................12
   7. Acknowledgements ...............................................13
   8. References .....................................................13
      8.1. Normative References ......................................13
      8.2. Informative References ....................................13
   Appendix. VLAN Inhibition Example .................................14

1. Introduction 🌷

okay so TRILL [RFC6325] is the protocol that gives you optimal pair-wise data frame forwarding with no configuration in multi-hop networks with arbitrary topology 💖 it stays safe during temporary loops and supports multipathing for both unicast and multicast traffic. it's iconic, honestly 👑 TRILL does this by running IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC1195] link state routing and by encapsulating traffic in a header that includes a hop count. the design also supports VLANs (Virtual Local Area Networks) and optimizes how multi-destination frames get distributed, based on VLANs and IP-derived multicast groups ✨ devices that run TRILL are called "RBridges" (Routing Bridges) 🧚

Section 2 of [RFC6327] explains the environment TRILL was built for, and how that environment is different from the usual Layer 3 routing world 🦋

TRILL works with multi-access LAN (Local Area Network) links, which can have multiple end stations and RBridges attached 🌈 when multiple RBridges hang off one link, the native traffic to and from the end stations on that link is handled by a subset of them called "Appointed Forwarders" 💅 the intent is that native traffic in each VLAN gets handled by at most one RBridge. an RBridge can be the Appointed Forwarder for lots of VLANs at once, which is very much a multitasking queen moment 👑

this document exists to improve the documentation of the Appointed Forwarder mechanism, so it updates RFC 6325 📚 it includes reference implementation details. alternative implementations that interoperate on the wire are permitted 🫶

the Appointed Forwarder mechanism doesn't matter on any link where end station service isn't offered 🙈 that includes links set up as point-to-point IS-IS links, and any link where every RBridge port is configured as a trunk port. (in TRILL, setting a port as a "trunk port" just means no end station service will be provided. it does not mean that all VLANs are enabled on that port 💀)

the Appointed Forwarder mechanism has no effect on forming adjacencies, electing the Designated RBridge (DRB) for a link, MTU matching, or pseudonode formation. those topics are covered in [RFC6327] 🎀 also, Appointed Forwarder status has no effect on forwarding TRILL Data frames. it only affects how native frames are handled ✨

for everything else about the TRILL base protocol, see [RFC6325] and [RFC6327]. this document assumes you're already familiar with both 🌸 and if this document conflicts with [RFC6325], this document prevails 💜

1.1. Terminology and Acronyms 🍓

this document uses the acronyms defined in [RFC6325] 💅

a "trunk port" is a port configured with the "end station service disable" bit on, as described in Section 4.9.1 of [RFC6325] 🦋

in this document, the term "link" means "bridged LAN," which is to say some combination of physical links with zero or more bridges, hubs, repeaters, or the like 🌈

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]. 🫶

2. Appointed Forwarders and Their Appointment 🧚

the Appointed Forwarder on a link for VLAN-x is the RBridge that ingresses native frames from the link and egresses native frames to the link in VLAN-x 💖 by default, the DRB (Designated RBridge) on a link is in charge of native traffic for all VLANs on that link. the DRB may, if it wants, act as Appointed Forwarder for any VLAN, and it may appoint other RBridges with ports on the link to be Appointed Forwarder for one or more VLANs 👑

this part matters a lot 🚨 there must not be two Appointed Forwarders on a link that are ingressing and egressing native frames for the same VLAN at the same time. if that happened, it could form a loop where frames aren't protected by a TRILL Hop Count for part of the loop 💀 (this can even happen through two Appointed Forwarders for two different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the link are configured to map frames between VLAN-x and VLAN-y, as discussed in Section 2.4.) TRILL does try to avoid these situations, but for loop safety there's also an "inhibition" mechanism (see Section 3) that can stop an RBridge that is an Appointed Forwarder from ingressing or egressing native frames 🔥

as discussed in Section 5, an RBridge may have multiple ports on a link 🌸 as discussed in [RFC6327], if there are multiple ports with the same Media Access Control (MAC) address on a link, all but one will be suspended 🙈 the case of multiple ports on a link for one RBridge, the case of multiple ports with the same MAC address on a link, and combinations of these cases are all fully accommodated 🫶 still, multiple ports on a link for one RBridge is expected to be a rare condition, and duplicate MAC addresses are not recommended by either the TRILL or IEEE 802.1 standards 🍓

Appointed Forwarder status has no effect on the forwarding of TRILL Data frames. it only affects the handling of native frames 🦋

there are three ways an RBridge can be appointed or un-appointed as Appointed Forwarder: 🌈

  • as a result of DRB elections [RFC6327], as discussed in Section 2.1
  • as a result of action by the DRB, as discussed in Section 2.2
  • as a result of a local configuration action, as discussed in Section 2.3

2.1. Appointment Effects of DRB Elections ✨

when an RBridge believes it has become the DRB on a link, by default, it can act as Appointed Forwarder for any VLANs on that link that it chooses, as long as its port isn't configured as a trunk port and has that VLAN enabled. (or at least one of its ports meets these criteria, if it has more than one port on the link.) 💅

an RBridge loses all Appointed Forwarder status when: 💔

  1. it decides that it has lost the status of being the DRB for a link; or
  2. it observes a change in the RBridge that is the DRB for the link without itself becoming the DRB.

there's a rare corner case where an RBridge has more than one port on a link, and one of those ports was previously the DRB election winner but just lost the DRB election to a different port of the same RBridge (maybe because of management configuration of port priorities) 🙈 in that case, the RBridge that is the DRB hasn't changed. so neither of the points above applies, and there's no change in Appointed Forwarder status 🎀

2.2. Appointment and Removal by the DRB ✨

okay so the DRB 👑 can appoint other RBridges on the link by putting one or more Appointed Forwarders sub-TLVs [RFC6326] into a TRILL Hello it sends on the Designated VLAN, out the port that won the DRB election. When the DRB sends any appointments in a TRILL Hello, it must send all appointments for that link in that Hello. Any previous appointment not included is implicitly revoked. 🫶

Here's the plot twist: the DRB doesn't have to announce the VLANs it's appointing itself as Appointed Forwarder for. 🙈 But if the DRB wants to wipe every appointment for RBridges other than itself on the link, it is recommended that it send a TRILL Hello with an appointment for itself for some VLAN. Lowkey a clean reset move. 🧹

The DRB MUST NOT send any appointments on a link unless its DRB inhibition timer (see Section 3) for that link is expired. ⏰ No jumping the gun!

How the DRB decides which other RBridges on the link get appointed as forwarder for which VLANs is beyond the scope of this document. That's a them problem 💅, not a this-document problem.

2.2.1. Processing Forwarder Appointments 🦋

So when a non-DRB RBridge that can offer end station service on a link gets a TRILL Hello that isn't discarded for one of the reasons given in [RFC6327], it checks the source MAC address and the Port ID and System ID in the Hello to figure out if it came from the winning DRB port. If it didn't, any Appointed Forwarder sub-TLVs in the Hello get ignored, and the receiving RBridge's Appointed Forwarder status stays exactly the same. Also, if there are no Appointed Forwarder sub-TLVs in the TRILL Hello, the receiver's Appointed Forwarder status doesn't change either. 🌸

BUT if the TRILL Hello is from the winning DRB port and includes one or more Appointed Forwarder sub-TLVs, the receiving RBridge becomes appointed for the VLANs that are both listed for it in the Hello and enabled on the receiving port. (If the appointment includes VLAN IDs 0x000 or 0xFFF, those get ignored, but any other VLAN IDs still count. 🎀) If the receiver was Appointed Forwarder for any other VLANs, that status for those other VLANs gets revoked. For example, if none of these sub-TLVs in a Hello appoints the receiving RBridge, then it loses all Appointed Forwarder status and is no longer Appointed Forwarder for any VLAN on the port where the Hello came in. Bye bye status 😭

Now the handling. An appointment in an Appointed Forwarder sub-TLV is for one specific RBridge and a contiguous interval of VLAN IDs. But (as mentioned above) it only actually makes that RBridge forwarder for the VLAN(s) in that range that are enabled on one or more of the RBridge's ports on the link, ignoring any ports configured as trunk ports or as IS-IS point-to-point ports. If the RBridge was Appointed Forwarder for any extra VLANs beyond the ones it was being appointed for, it loses Appointed Forwarder status for those extras. Main character energy: only the VLANs it's actually been picked for stick around. ✨

There's no reason for an RBridge to remember a valid appointment for a VLAN that was ineffective, either because the VLAN wasn't enabled on the port where the message arrived, or because that port was a trunk or point-to-point port. It does not become Appointed Forwarder for such a VLAN just because that VLAN gets enabled later or the port gets reconfigured later. No retroactive vibes allowed 🙅‍♀️

Okay, here's the tricky part. It should be straightforward for the DRB to send, within one Hello, appointments for several dozen VLAN IDs or several dozen blocks of contiguous VLAN IDs. But if the VLANs the DRB wants to appoint are inconveniently scattered (the proverbial case where DRB RB1 wants to appoint RB2 as forwarder for all even-numbered VLANs and RB3 for all odd-numbered VLANs), the following method may be used. The network manager normally controls which VLANs are enabled on an RBridge port. So the network manager can appoint an RBridge as forwarder for an arbitrary set of scattered VLANs by enabling only those VLANs on the relevant port (or ports), and then having the DRB send an appointment that appears to appoint the target RBridge as forwarder for all VLANs. 🧠 However, for proper operation and inter-RBridge communication, the Designated VLAN for a link SHOULD be enabled on all RBridge ports on that link, and it may not be desired to appoint the RBridge as forwarder for the Designated VLAN. So in the general case it would take two appointments, though it would still only take one if the Designated VLAN were an extreme low or high value, such as VLAN 0xFFE or the default VLAN 1. 🍓

Here's a worked example: say the DRB wants RB2 to be Appointed Forwarder for all even-numbered VLANs, and the Designated VLAN for the link is VLAN 101. The network manager could enable all even-numbered VLANs plus VLAN 101 on RB2's relevant port and then, to get the desired effect, have the DRB send appointments to RB2 appointing it forwarder for all VLANs from 1 through 100 and from 102 through 4,094. Big brain move 🧚

Now, if the network manager misconfigures the enabled VLANs and Appointed Forwarders so that two RBridges believe they're both Appointed Forwarders for the same VLAN, then item 4 in Section 3 will cause one or more of those RBridges to be inhibited for that VLAN. Consequences, bestie 💀

2.2.2. Frequency of Appointments 💜

It is not necessary for the DRB to include the forwarder appointments in every TRILL Hello it sends on the Designated VLAN for a link. For loop safety, every RBridge is required to indicate, in every TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed Forwarder for VLAN-x for that link (see item 4 in Section 3). It is also RECOMMENDED that the DRB have all VLANs for which end station service will be offered on the link enabled, as well as the Designated VLAN. That way the DRB will generally be informed by other RBridges on the link of which VLANs they believe they're Appointed Forwarder for. ✨ If that matches the appointments the DRB wants to make, it is not required to re-send its forwarder appointments. However, for robustness (especially in cases like VLAN misconfigurations in a bridged LAN link), it is RECOMMENDED that the DRB send its forwarder appointments on the Designated VLAN at least once per its Holding Time on the port that won the DRB election. Checking in, but make it consistent 🫶

2.2.3. Appointed Forwarders Limit 🌈

The mechanism of DRB forwarder appointment and the limited length of TRILL Hellos put a limit on how many RBridges on a link can be Appointed Forwarders. 📏 To get a conservative estimate, assume no more than 1000 bytes are available in a TRILL Hello for such appointments. Now assume you want to appoint various RBridges on a link as forwarders for arbitrary non-intersecting sets of VLANs. Using the technique discussed above would generally take two appointments, or 12 bytes, per RBridge. With allowance for sub-TLV and TLV overhead, appointments for 83 RBridges would fit in under 1000 bytes. Including the DRB, that means a link with 84 or more RBridges attached. Links with more than a handful of RBridges attached are expected to be rare. Good news for everyone's sanity 🙌

Note: If the Designated VLAN were an extreme low or high value, such as VLAN 1 (the default, and maybe a common value in practice), only 6 bytes per RBridge would be required. That would permit twice as many different Appointed Forwarder RBridges as the general analysis above indicates or, alternatively, take only half as much space to appoint the same number of Appointed Forwarders. 🍰

Unnecessary changes in Appointed Forwarders SHOULD NOT be made, since they may result in a transient lack of end station service. 🥺 And large numbers of Appointed Forwarders on a link (in excess of 65) are NOT RECOMMENDED because establishing and maintaining them gets way too complicated. Keep the squad small 💅

2.3. Local Configuration Action Appointment Effects 🎀

Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder status that RBridge has for VLAN-x, unless VLAN-x is enabled on some other port that the RBridge has connected to the same link. And configuring a port as a trunk port or point-to-point port revokes any Appointed Forwarder status that depends on enabled VLANs at that port. Local config drama, but make it make sense 🧩

Here's the nuance: causing a port to stop being configured as a trunk or point-to-point port, or enabling VLAN-x on a port, does not, by itself, make the RBridge an Appointed Forwarder for the link that port is on. 🙅‍♀️ However, those actions can let the port's RBridge become Appointed Forwarder by choice (if it's the DRB) or by appointment (if it's not the DRB on the link). Opportunity knocks, but nobody's automatically invited in 🚪

TRILL Hellos include a field that's set to the VLAN they were sent in. If they arrive on a different VLAN, then VLAN mapping is happening within the link. (VLAN mapping within a link between RBridges shouldn't be mixed up with VLAN mapping inside an RBridge [VLANMAP].) VLAN mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for those VLANs are different. And if this kind of mapping within a link were allowed and happened on two or more links so that there was a cycle of VLAN mappings, a broadcast frame, for example, would loop forever. 🌀😭 Not it!

To prevent this potential problem: if the DRB on a link detects VLAN mapping (by receiving a Hello in VLAN-x that was sent on VLAN-y), it MUST make or revoke appointments so as to assure that the same RBridge (possibly the DRB) is the Appointed Forwarder on the link for both VLAN-x and VLAN-y. Same forwarder for both VLANs, every time. No split custody, no loops, periodt 💖

3. The Inhibition Mechanism 🦋

Okay bestie, so every RBridge keeps a bunch of timers for every link where it can offer end station service (aka every link where it can act as an Appointed Forwarder) 🫶. They're all counted in seconds, and you get:

  • a DRB inhibition timer,
  • a root change inhibition timer, and
  • up to 4,094 VLAN inhibition timers, one for each legal VLAN ID 💅.

The DRB and root change inhibition timers MUST be implemented. ✨

Losing native traffic to inhibition is the worst 😭, so the move is to basically have a VLAN inhibition timer for every VLAN the RBridge will ever offer end station service on that link, and this SHOULD be done. (Check the Appendix for an example that shows why VLAN inhibition timers are such a big deal 🙈.) But if your implementation can't handle a full set, you can merge the VLAN inhibition timers for more than one VLAN into a single timer, as long as you're careful 🧠. Just know that an RBridge MUST NOT merge the VLAN inhibition timers together for two VLANs if it's the Appointer Forwarder for one and not the other, because that can lead to unnecessary indefinitely prolonged inhibition 💀.

Even if you only have two VLAN inhibition timers (one for VLANs where the RBridge is the Appointed Forwarder, and one for all the other VLANs), it's still safe 🫶, just with more native frame loss than you'd otherwise get. At least two VLAN inhibition timers MUST be implemented. And when one VLAN inhibition timer stands in for several VLANs, any update or test that would've been done to a timer for any of those VLANs gets done to the merged timer instead 🎀.

These timers get set like this:

  1. On booting or management reset, each port gets its own set of timers, even if two or more of those ports are on the same link, because the RBridge hasn't had a chance to learn that yet 🌸. All inhibition timers are set to expired except the DRB inhibition timer, which gets set according to item 2 below. The DRB inhibition timer is handled differently because each port will initially think it's the DRB 🙃.
  2. When an RBridge decides it has become the DRB on a link (including when it's first booted or reset by management), it sets the DRB inhibition timer to the Holding Time of its port on that link that won the DRB election 👑.
  3. When an RBridge decides it has lost DRB status on a link, it sets the DRB inhibition timer to expired 💔.

Note: In the rare corner case where one port of an RBridge won the DRB election but later lost it to a different port of the same RBridge on that link (maybe because of management configuration of port priority), neither 2 nor 3 above applies, and the DRB timer doesn't change 🤷‍♀️.

  1. When an RBridge RB1 receives a TRILL Hello asserting that the sender is the Appointed Forwarder, and that Hello either (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated inside the Hello, then RB1 sets its VLAN-x inhibition timer for the link to the maximum of that timer's existing value and the Holding Time in the received Hello 🦋. An RBridge MUST maintain VLAN inhibition timers for a link it connects to if it can offer end station service on that link, even if it isn't currently the Appointed Forwarder for any VLAN on that link 🧚.
  2. When an RBridge RB1 enables VLAN-x on a port connecting to a link, and VLAN-x wasn't previously enabled on any of RB1's ports on that link, it sets its VLAN inhibition timer for VLAN-x for that link to its Holding Time for that port 🍓. This happens even if the port is configured as a trunk or point-to-point port, as long as there's some chance it might later be configured not to be one 👀.
  3. When an RBridge detects a change in the common spanning tree root bridge on a port, it sets its root change inhibition timer for the link to an amount of time that defaults to 30 seconds and is configurable to any value from 30 down to zero seconds ⏰. This condition won't happen unless the RBridge is receiving Bridge PDUs (BPDUs) on the port from an attached bridged LAN. It's safe to configure this inhibition time to the settling time of an attached bridged LAN. For example, if it's known that Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running throughout the attached bridged LAN, it should be safe to configure this inhibition time to 7 seconds, or, if the attached bridges have been configured with a minimum Bridge Hello Timer, safe to configure it to 4 seconds 💜. Here's the tea ☕: while an RBridge can figure out what version of spanning tree is running on the physical link between it and any directly connected bridge (by looking at the BPDUs it receives), it can't tell if inter-bridge links beyond those directly connected bridges are running classic Spanning Tree Protocol (STP). That might mean the root change inhibition timer needs to be set to 30 seconds for safety 😬.
  4. When an RBridge decides that one of its ports (or a set of its ports) P1 is on the same link as another of its ports (or set of its ports) P2, the inhibition timers get merged into a single set of inhibition timers by using the maximum value of the corresponding timers 🫂.
  5. When an RBridge decides that a set of its ports it had been treating as being on the same link are no longer on the same link, those ports will necessarily be on two or more links (one link per port, in the limit). This is handled by cloning a copy of the timers for each of the two or more links the RBridge has decided these ports connect to 🌈.

4. Inhibited Appointed Forwarder Behavior 🚫

An Appointed Forwarder for a link is inhibited for VLAN-x if any of these are true:

  1. its DRB inhibition timer for that link is not expired, or
  2. its root change inhibition timer for that link is not expired, or
  3. its VLAN inhibition timer for that link for VLAN-x is not expired.

If a VLAN-x Appointed Forwarder for a link is inhibited and receives a TRILL Data frame whose encapsulated frame is in VLAN-x and would normally be egressed to that link, it decapsulates the native frame as usual. However, it does not output it to, or queue it for, that link. Although, if appropriate (for example, if the frame is multi-destination), it may output it to or queue it for other links 🧃.

If a VLAN-x Appointed Forwarder for a link is inhibited and receives a native frame in VLAN-x that would normally be ingressed from that link, the native frame is ignored, except for address learning 👀.

An RBridge with one or more unexpired inhibition timers (possibly including an unexpired inhibition timer for VLAN-x) is still required to indicate in TRILL Hellos it sends on VLAN-x whether or not it's the Appointed Forwarder for VLAN-x for the port it sends the Hello on 📣.

Inhibition has no effect on the receipt or forwarding of TRILL Data frames 💖. Phew, the data plane is all good, bestie 🫶.

An RBridge may have multiple ports on the same link. Some of these ports may be suspended due to MAC address duplication, as described in [RFC6327]. Suspended ports never ingress or egress native frames 🚷.

If an RBridge has one or more non-suspended ports on a link, and those ports offer end station service (that is, those ports aren't configured as point-to-point or trunk ports), then that RBridge is eligible to be an Appointed Forwarder for that link. It can become the Appointed Forwarder either by its own choice, because it's the DRB, or by appointment from the DRB, as described in Sections 2.1 and 2.2 ✨.

If an RBridge that's the Appointed Forwarder for VLAN-x on a link has multiple non-suspended ports on that link, it may load share the job of ingressing and egressing VLAN-x native frames across those ports however it likes, as long as there's no case where a frame it egresses onto the link from one port can be ingressed on another of its ports, creating a loop 🔁. If the RBridge is the Appointed Forwarder for multiple VLANs, a straightforward thing to do would be to partition those VLANs among the ports it has on the link 🍰.

6. Security Considerations 🔐

This memo provides improved documentation of the TRILL Appointed Forwarder mechanism. It does not change the security considerations of the TRILL base protocol. See Section 6 of [RFC6325].

⚠️ Bestie, the security considerations of the base protocol still apply in full. This memo doesn't change them, so go read Section 6 of [RFC6325] before you do anything else 💀.

7. Acknowledgements 🫶

The authors of [RFC6325] and [RFC6327], those listed in the Acknowledgements section of [RFC6325] and [RFC6327], and Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand are hereby thanked for their contributions 👑💕.

8. References 📚

Normative and Informative references for this document are listed below.

8.1. Normative References

  • [802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, May 2011.
  • [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 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.
  • [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
  • [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
  • [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.

8.2. Informative References

  • [VLANMAP] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", Work in Progress, October 2011.

Appendix. VLAN Inhibition Example ✨

okay so the per-VLAN inhibition timers (or the equivalent) are needed to be loop safe 🔁 in case of misconfigured bridges on a link. that's the whole reason they exist, bestie 💅

Here's a simple example 🎀. Assume RB1 and RB2 are the only RBridges on the link, RB1 is higher priority to be the DRB, and they both want VLAN 1 (the default) to be the Designated VLAN. BUT there's a bridge between them configured so that RB1 can see all the frames sent by RB2, while none of RB1's frames can get through to RB2. 😭

Both of them will think they're the DRB 👑. RB1 does because it's higher priority, even though it sees the Hellos from RB2. RB2 does because it doesn't see the Hellos from RB1, so it thinks it's the highest priority. main character delusion, iykyk 💀

Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3, while RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There's no problem with VLANs 2 and 4 🦋, but if you don't do something about it, you could have a loop involving VLAN 3 🌀. RB1 will see the Hellos RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 will be inhibited on VLAN 3. RB2 doesn't see the Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and handle VLAN 3 native traffic.

But this situation may change 🙃. RB2 might crash, the bridge might crash, RB2 might be reconfigured so it no longer tried to act as Appointed Forwarder for VLAN 3, or other issues may occur.

So RB1 has to maintain a VLAN 3 inhibition timer ⏲️. If it sees no Hellos from any other RBridge on the link claiming to be Appointed Forwarder for VLAN 3 in a long enough time, then RB1 becomes uninhibited for that VLAN on the port in question and can handle end station traffic in VLAN 3 🫶✨

Authors' Addresses 🌸

Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054 USA

Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu


Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA

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


Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China

Phone: +86-25-56622310
EMail: liyizhou@huawei.com


Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA

Phone: +1-408-333-7149
EMail: ayabaner@cisco.com


Fangwei Hu
ZTE Corporation
889 Bibo Road
Shanghai 201203
China

Phone: +86-21-68896273
EMail: hu.fangwei@zte.com.cn
📦 where this page comes from