RFC 8139

Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders

📅 published June 2017, from ietf

RFC 8139 Title Block 🎀

Okay bestie, let's start with the vibe check ✨ This is RFC 8139, called Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders. It came from the Internet Engineering Task Force (IETF) and is a Standards Track document dated June 2017. Its ISSN is 2070-1721 📚

The authors are D. Eastlake 3rd, Y. Li (Huawei), M. Umair (IP Infusion), A. Banerjee (Cisco), and F. Hu (ZTE). 🫶

Now the big drama 💀 This one obsoletes RFC 6439, and it updates RFC 6325 and RFC 7177 🔥 So if you're reading the older docs, you need this one too, no cap.

Abstract 🦋

TRILL (Transparent Interconnection of Lots of Links) is built for multi-access LAN (Local Area Network) links, where one link can have a bunch of end stations and TRILL switches plugged in at the same time 🌈 When several TRILL switches sit on the same link, the native traffic to and from those end stations gets handled by a subset of them called "Appointed Forwarders." RFC 6325 introduced this, and the goal is that native traffic in each VLAN gets handled by at most one TRILL switch 💅

This document cleans up and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177, and it obsoletes RFC 6439 ✨

Status of This Memo 🌸

This is an Internet Standards Track document.

It's 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 7841 📖

For the current status, any errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc8139 🔗

Copyright (c) 2017 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 describe 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 described in the Simplified BSD License 🫶

Table of Contents 🧚

   1. Introduction ....................................................4
      1.1. Appointed Forwarders and Active-Active .....................5
      1.2. Terminology and Abbreviations ..............................6
   2. Appointed Forwarders and Their Appointment ......................7
      2.1. The Appointment Databases and DRB Actions ..................8
      2.2. Appointment Effects of DRB Elections ......................10
           2.2.1. Processing Forwarder Appointments in Hellos ........11
           2.2.2. Frequency of Hello Appointments ....................13
           2.2.3. Appointed Forwarders Hello Limit ...................13
      2.3. Effects of Local Configuration Actions on Appointments ....14
      2.4. Overload and Appointed Forwarders .........................14
      2.5. VLAN Mapping within a Link ................................15
   3. The Inhibition Mechanism .......................................15
      3.1. Inhibited Appointed Forwarder Behavior ....................18
      3.2. Root Bridge Change Inhibition Optimizations ...............18
           3.2.1. Optimization for Change to Lower Priority ..........19
           3.2.2. Optimization for Change to Priority Only ...........19
           3.2.3. Optimizing the Detection of Completed Settling .....19
   4. Optional TRILL Hello Reduction .................................20
   5. Multiple Ports on the Same Link ................................22
   6. Port-Shutdown Messages .........................................23
      6.1. Planned Shutdown and Hellos ...............................23
      6.2. Port-Shutdown Message Structure ...........................23
      6.3. Port-Shutdown Message Transmission ........................24
      6.4. Port-Shutdown Message Reception ...........................25
      6.5. Port-Shutdown Message Security ............................25
      6.6. Port-Shutdown Configuration ...............................26
   7. FGL-VLAN Mapping Consistency Checking ..........................26
   8. Support of E-L1CS ..............................................27
      8.1. Backward Compatibility ....................................27
   9. Security Considerations ........................................28
   10. Code Points and Data Structures ...............................28
      10.1. IANA Considerations ......................................28
      10.2. AppointmentBitmap APPsub-TLV .............................29
      10.3. AppointmentList APPsub-TLV ...............................30
      10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
      10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
   11. Management Considerations .....................................33
   12. References ....................................................34
      12.1. Normative References .....................................34
      12.2. Informative References ...................................36
   Appendix A. VLAN Inhibition Example ...............................37
   Appendix B. Multi-Link VLAN Mapping Loop Example ..................38
   Appendix C. Changes to RFCs 6325, 6439, and 7177 ..................39
   Acknowledgments ...................................................40
   Authors' Addresses ................................................41

1. Introduction ✨

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol, described in [RFC6325] and [RFC7780], gives you optimal pairwise data frame forwarding with zero configuration in multi-hop networks. It works with arbitrary topologies and link technologies, stays safe even during temporary loops, and supports multipathing for both unicast and multicast traffic 🌈 It gets all this by using IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC7176] link-state routing, and by encapsulating traffic in a header that includes a hop count. The design supports VLANs, FGLs (Fine-Grained Labels) [RFC7172], and optimized distribution of multi-destination frames based on VLANs and multicast groups 💖 Devices that implement TRILL are called TRILL switches, or "RBridges" (Routing Bridges) 🦋

Section 2 of [RFC7177] talks about the environment TRILL was designed for, and how that differs from the usual Layer 3 routing world 🧠

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and TRILL switches attached. When several TRILL switches are attached to a link, the native traffic to and from end stations on that link is handled by a subset of those switches called "Appointed Forwarders," as first specified in [RFC6325]. The intent is that native traffic in each VLAN is handled by at most one switch. One TRILL switch can be the Appointed Forwarder for many VLANs 👑

This document updates and improves the Appointed Forwarder mechanism. It also frees it from a limit in the original design, which required that all appointments fit inside a single TRILL Hello Protocol Data Unit (PDU) 🎀 The fix is to require support for link-scoped FS-LSPs (Flooding Scope Link State PDUs) (Section 8), and to let you send appointment information in those LSPs. On top of that, this document adds some optional features:

  1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the TRILL switch ports on a link, as discussed in Section 7,
  2. expedite notification of ports going down so that Appointed Forwarders can be adjusted, as discussed in Section 6, and
  3. reduce or eliminate the need for "inhibition" of ports for loop safety, as discussed in Section 3.2.

This document replaces and obsoletes [RFC6439], and it brings that earlier material along with these additions 💅 The various optimizations are orthogonal and optional. Implementers can choose to provide all, some, or none of them, and TRILL switches will still be interoperable 🫶 Following the TRILL design philosophy, these optimizations need zero or minimal configuration. There are a couple of configurable parameters, though, summarized in Section 11.

As described in Appendix C, this document updates [RFC6325] by mandating support of E-L1CS FS-LSPs. It also provides backward compatibility in the presence of legacy TRILL switches that don't offer this support 🔥 It updates [RFC7177] too: as an optional optimization, receiving the Port-Shutdown message specified here can be treated as an event in the state machine specified in [RFC7177] 🌸

This document includes reference implementation details. Alternative implementations that interoperate on the wire are permitted ✨

The Appointed Forwarder mechanism is irrelevant to any link where end-station service isn't offered. That includes links configured as point-to-point IS-IS links, and any link where all TRILL switch ports are configured as trunk ports. (In TRILL, setting a port as a "trunk port" just means no end-station service will be provided. It doesn't mean all VLANs are enabled on that port 🙈)

The Appointed Forwarder mechanism has no effect on adjacency formation, on the election of the Designated RBridge (DRB) [RFC7177] for a link, on MTU matching, or on pseudonode formation. Those topics are covered in [RFC7177]. Also, Appointed Forwarder status has no effect on forwarding TRILL Data frames. It only affects how native frames to and from end stations are handled 🧚

For other parts of the TRILL base protocol, see [RFC6325], [RFC7177], and [RFC7780]. If this document conflicts with [RFC6325] or [RFC7177], this document wins 👑

1.1. Appointed Forwarders and Active-Active 🌈

As discussed in [RFC7379], TRILL active-active supports end stations connected to multiple edge TRILL switches, where those connections are separate links. Since TRILL Hellos aren't forwarded between these links, the Appointed Forwarder mechanism described here runs separately on each such link 💜

(Part 1 of 9. Part 2 picks up with Section 1.2, so stay tuned, bestie! 🦋)

1.2. Terminology and Abbreviations ✨

okay so before we dive in, this doc uses the abbreviations and terms from [RFC6325] 💅, some of which get repeated below for convenience, plus a few extra ones listed here. let's get into it 🦋

Data Label mapping: The mapping from VLAN ID to FGL and from FGL to VLAN ID.

DRB: Designated RBridge. The RBridge on a link elected as specified in [RFC7177] to handle certain decisions and tasks for that link, including forwarder appointment as specified herein.

E-L1CS: Extended Level 1 Circuit Scope (Section 8).

FGL: Fine-Grained Label [RFC7172].

FS-LSP: Flooding Scope Link State PDU (Section 8).

Link: The means by which adjacent TRILL switches are connected. A TRILL link may be various technologies and, in the common case of Ethernet, can be a "bridged LAN" -- that is to say, some combination of Ethernet links with zero or more bridges, hubs, repeaters, or the like.

LSDB: Link State Database.

PDU: Protocol Data Unit.

RBridge: An alternative name for a TRILL switch.

TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.

TRILL switch: A device implementing the TRILL protocol. An alternative name for an RBridge.

Trunk port: A TRILL switch port configured with the "end-station service disable" bit on, as described in Section 4.9.1 of [RFC6325].

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀

2. Appointed Forwarders and Their Appointment 👑

The Appointed Forwarder on a link for VLAN-x is the TRILL switch (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 the link. The DRB may, if it wishes, act as Appointed Forwarder for any VLAN, and it may appoint other TRILL switches that have ports on the link as Appointed Forwarder for one or more VLANs. 🌸

By definition, the DRB considers the other ports on the link to be the ports with which a DRB port has adjacency on that link [RFC7177]. If the DRB loses adjacency to a TRILL switch that it has appointed as forwarder and the native traffic that was being handled by that Appointed Forwarder is still to be ingressed and egressed, it SHOULD immediately appoint another forwarder or itself become the forwarder for that traffic. 😭

It is important that there not be two Appointed Forwarders on a link that are ingressing and egressing native frames for the same VLAN at the same time. Should this occur, it could form a loop where frames are not protected by a TRILL Hop Count for part of the loop. (Such a condition can even occur 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.5.) While TRILL tries to avoid such situations, for loop safety there is also an "inhibition" mechanism (see Section 3) that can cause a TRILL switch that is an Appointed Forwarder not to ingress or egress native frames. Appointed Forwarder status and port "inhibition" have no effect on the reception, transmission, or forwarding of TRILL Data or TRILL IS-IS frames. Appointed Forwarder status and inhibition only affect the handling of native frames. 💀

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

There are six mechanisms by which an RBridge can be appointed or unappointed as Appointed Forwarder: ✨

  1. assumption of appointment, when the DRB decides to act as Appointed Forwarder for a VLAN,
  2. E-L1CS appointment, as a result of appointments sent by the DRB in E-L1CS FS-LSPs,
  3. Hello appointment, as a result of appointments sent by the DRB in TRILL Hellos,
  4. as a result of the DRB elections [RFC7177] as discussed in Section 2.2,
  5. as a result of a Port-Shutdown message as discussed in Section 6, and
  6. as a result of a local configuration action as discussed in Section 2.3.

Mechanisms 2 and 3 are covered in Section 2.1. 🦋

2.1. The Appointment Databases and DRB Actions 🍓

The DRB MAY appoint other RBridges on the link as Appointed Forwarders through two mechanisms, "A" and "B", as described below. 💜

Each RBridge maintains two databases of appointment information: (1) its E-L1CS LSDB, which shows appointments that each RBridge on the link would make using mechanism A if that RBridge were the DRB, and (2) its Hello appointment database, which shows the appointments most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment database is more transient and is completely reset by each Hello received from the DRB that contains any appointments; this database is also cleared under other circumstances, as described below. An RBridge considers itself to be the Appointed Forwarder for VLAN-x if this is indicated by either its Hello appointment database or its E-L1CS LSDB entries from the DRB. 🌈

The two mechanisms by which the DRB can appoint other RBridges on a link as Appointed Forwarders are as follows:

(A) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176], AppointmentBitmap APPsub-TLVs (Section 10.2), or AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it sends on a link. Appointments sent using this method will not be seen by legacy RBridges that do not support E-L1CS (Section 8).

(B) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176] in a TRILL Hello it sends on the Designated VLAN out of the port that won the DRB election. When the DRB sends any appointments in a TRILL Hello, it must send all appointments it is sending in Hellos for that link in that Hello. Any previous appointment it has sent in a Hello that is not included is implicitly revoked. 🫶

To avoid the size limitations of the Hello PDU, it is RECOMMENDED that the E-L1CS FS-LSP method be used to distribute forwarder appointments and that all RBridges on a link use this method to advertise the appointments they would make if they were the DRB. However, if some RBridges on a link do not support E-L1CS FS-LSPs, then Hello appointments must be used for the DRB to appoint such legacy RBridges as Appointed Forwarders. 🔥

Although the DRB does not need to announce the VLANs for which it has chosen to act as Appointed Forwarder by sending appointments for itself, if the DRB wishes to revoke all appointments made in Hellos for RBridges other than itself on the link, it can do so by sending a TRILL Hello with just an appointment for itself for some VLAN. 🙈

How the DRB decides what other RBridges on the link, if any, to appoint as forwarder for some VLAN or VLANs is beyond the scope of this document. 🎀

Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as they may result in transient lack of end-station service. 🌸

Should the network manager have misconfigured the enabled VLANs and Appointed Forwarders, resulting in two RBridges believing they are Appointed Forwarders for the same VLAN, the scenario described in item 4 in Section 3 will cause one or more of the RBridges to be inhibited for that VLAN, thus avoiding persistent loops. 👑

When forwarder appointments are being encoded for transmission, different patterns of VLANs are most efficiently encoded in different ways. The following table gives advice regarding the most efficient encoding for a given pattern: 💅

                            sub-TLV and Reference
   Pattern of VLAN IDs          |enclosing TLV(s) and Reference
   -------------------      ------------------------------------

   Blocks of consecutive VLANs
                            Appointed Forwarders sub-TLV [RFC7176]
                                |Router CAPABILITY TLV [RFC7981]
                                |or MT-Capability TLV [RFC6329]

   Scattered VLANs within a small range
                            AppointmentBitmap APPsub-TLV (Section 10.2)
                                |TRILL GENINFO TLV [RFC7357]

   Scattered VLANs over a large range
                            AppointmentList APPsub-TLV (Section 10.3)
                                |TRILL GENINFO TLV [RFC7357]

2.2. Appointment Effects of DRB Elections ⭐

When a TRILL switch port on a link wins the DRB election, there are four possible cases: 🧚

  1. A TRILL switch believes that it was the DRB and remains the DRB: there is no change in Appointed Forwarder status. This also applies in the corner case where a TRILL switch has more than one port on a link, one of which was previously the DRB election winner but has just lost the DRB election to a different port of the same TRILL switch on the same link (possibly due to management configuration of port priorities). In this case, there also is no change in which TRILL switch is the DRB. 🦋
  2. A TRILL switch believes that it was not the DRB but has now won the DRB election and 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 is not 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). It ignores any previous forwarder appointment information it received from other TRILL switches on the link. 🍓
  3. A TRILL switch was not the DRB and does not become the DRB, but it observes that the port winning the DRB election has changed: the TRILL switch loses all Hello appointments. In addition, there are two subcases: 💜

a. The new winning port and the old winner are ports of different TRILL switches on the link. In this case, it switches to using the E-L1CS FS-LSP appointments for the winning TRILL switch.

b. The new winning port and the old winner are ports of the same TRILL switch, which has two (or more) ports on the link: although the Hello appointments are still discarded, since the same TRILL switch is the DRB, the E-L1CS FS-LSP appointments are unchanged. 🌈

  1. The winning port is unchanged: as in case 1, there is no change in Appointed Forwarder status. 🫶
Part 2 of 9 done, bestie! 💖 Part 3 is coming next, so stay tuned 🧚

2.2.1. Processing Forwarder Appointments in Hellos

Okay bestie, this is where the forwarder appointments actually get read out of TRILL Hellos 💅✨ Let's go!

When a non-DRB RBridge that can offer end-station service on a link gets a TRILL Hello that isn't thrown out for any of the reasons in [RFC7177], it checks the source MAC address, plus the Port ID and System ID inside the Hello, to figure out if it came from the winning DRB port 👑. If it did NOT come from that port, any forwarder appointment sub-TLVs in there get ignored, and the receiver's Appointed Forwarder status doesn't change because of that Hello. Same deal if the Hello has no forwarder appointment sub-TLVs at all: no change to the receiver's status 🫶.

BUT, if the Hello IS from the winning DRB port and it has one or more forwarder appointment sub-TLVs, the receiver sets its Hello appointment database to be the set of VLANs that have BOTH of these things going on 🎀:

o The VLAN is listed as an appointment for the receiving RBridge in the Hello, and

o The VLAN is enabled on the port where the Hello was received.

(If the appointment includes VLAN IDs 0x000 or 0xFFF, those get ignored, but any other VLAN IDs still count 🙈.) After that, it becomes Appointed Forwarder for every VLAN it's appointed for, whether that's in its Hello appointment database or in its E-L1CS FS-LSP appointment database from the DRB. Two conditions though: the VLAN has to be enabled, and the port can't be configured as a trunk or IS-IS point-to-point port 🚫.

Now the revoke part, which is lowkey important 😭: if the receiver was Appointed Forwarder for some VLANs because they were in the Hello appointment database, and those VLANs are no longer in that database, its Appointed Forwarder status for those VLANs gets revoked. For example, if none of the sub-TLVs in a Hello appoint the receiving RBridge, it loses ALL its Appointed Forwarder status on the port where the Hello came in (from Hello appointment database entries) 💀, but it keeps its Appointed Forwarder status from E-L1CS FS-LSP appointments. Main character energy for the FS-LSP route 👑.

So how does one of these sub-TLVs actually work? An appointment in an Appointed Forwarders sub-TLV is for a specific RBridge and a contiguous interval of VLAN IDs. Here's the twist though 🌈: even though it's written as a range, it really only appoints that RBridge for the VLANs in that range that are enabled on one or more of that RBridge's ports on the link. (Ports configured as trunk ports or IS-IS point-to-point ports don't count here either.)

Also, no reason to remember a valid appointment for a VLAN that didn't take effect, either because the VLAN wasn't enabled on the port where the Hello came in, or because the port was a trunk or point-to-point port 🦋. The RBridge does NOT become Appointed Forwarder for that VLAN just because it gets enabled later or the port gets reconfigured later. Gone is gone, bestie 🙅‍♀️.

Real talk: the Hello is small, so the limits on its size make E-L1CS FS-LSPs the way to go for appointments 💖. But if there are TRILL switches on the link that don't support E-L1CS FS-LSPs, then you have to use Hellos, and the rest of this section gives you a method to squeeze the most out of the limited space in there 🧚.

It should be pretty straightforward for the DRB to send, in 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 scattered all over the place (the classic example: the DRB (say RB1) wants to appoint RB2 as forwarder for all even-numbered VLANs and RB3 for all odd-numbered VLANs 🙃), then the following method MAY be used:

The network manager normally controls what VLANs are enabled on an RBridge port. Thus, 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. Thus, in the general case, two appointments would be required, although only one appointment would be required if the Designated VLAN value were extremely low or high (such as VLAN 0xFFE) or the default value (VLAN 1).

Let's make this concrete 🍓. 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 the even-numbered VLANs plus VLAN 101 on RB2's relevant port, and then the DRB sends appointments to RB2 for all VLANs from 1 through 100 and from 102 through 4,094. Ta-da 🎀.

2.2.2. Frequency of Hello Appointments

Okay so appointments made through E-L1CS FS-LSPs use the same IS-IS timing constants as LSP flooding do 🌸. The general IS-IS link-state flooding mechanism is super robust and has acknowledgments, so it automatically recovers from lost PDUs, rebooted TRILL switches, and things like that 🫶.

For Hello appointments, the DRB doesn't have to put the Hello forwarder appointments in EVERY TRILL Hello it sends on the Designated VLAN for a link 💅. But here's the loop-safety thing: every RBridge is required to indicate, in every TRILL Hello it sends in VLAN-x on a link, whether it's an Appointed Forwarder for VLAN-x on that link (see item 4 in Section 3, but also see Section 4) 🔥. It's also RECOMMENDED that the DRB has enabled all the VLANs where end-station service will be offered on the link, plus the Designated VLAN ✨. That way, the DRB generally hears from other RBridges on the link about which VLANs they think they're the Appointed Forwarder for. If that matches the appointments the DRB wants to make, it's not required to resend its forwarder appointments 🙌. Still, for robustness (especially with VLAN misconfigurations in a bridged LAN link 🙈), it's 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 💖.

2.2.3. Appointed Forwarders Hello Limit

The Hello mechanism for DRB forwarder appointments and the limited length of TRILL Hellos put a cap on how many RBridges on a link can be Appointed Forwarders when E-L1CS FS-LSP appointments can't be used because of legacy RBridges 🥺. For a conservative estimate, assume no more than 1,000 bytes are available in a TRILL Hello for those appointments. Also assume you want various RBridges on a link appointed as forwarder for arbitrary non-intersecting sets of VLANs 🦋. Using the technique at the end of Section 2.2.1 would generally need two appointments, or 12 bytes, per RBridge. Add in the sub-TLV and TLV overhead, and appointments for 83 RBridges fit in under 1,000 bytes. Including the DRB, that means a link with 84 or more RBridges attached is the limit 🧮. Links with more than a handful of RBridges are expected to be rare anyway, and those limits are easily avoided by using E-L1CS FS-LSP appointments 👑.

2.3. Effects of Local Configuration Actions on Appointments

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 🌈. 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 🚫.

Causing a port to stop being configured as a trunk or point-to-point port, or enabling VLAN-x on a port, does NOT automatically make the RBridge an Appointed Forwarder for the link that port is on 🙅‍♀️. What those actions DO do is let the port's RBridge become Appointed Forwarder by choice (if it's the DRB) or, if it isn't the DRB on the link, by appointment shown in the Hello appointment database or the E-L1CS FS-LSP appointment database ✨.

2.4. Overload and Appointed Forwarders

A TRILL switch in link-state overload [RFC7780] will, in general, do a poorer job of forwarding frames than a TRILL switch not in overload, because the one not in overload has full knowledge of the campus topology 😭. For example, as [RFC7780] explains, an overloaded TRILL switch may not be able to distribute multi-destination TRILL Data packets at all 💀.

So the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder, and if an Appointed Forwarder becomes overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge to another RBridge on the link that isn't overloaded, if one is available 🫶.

Now a counter-example 🙈: it would be best to appoint an RBridge in overload as Appointed Forwarder if RB1 was in overload but all the end stations in the campus in VLAN-x were on links attached to RB1. In that case, RB1 would never have to route VLAN-x end-station traffic as TRILL Data packets, since it would always be forwarding them locally as native frames. So RB1 SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed Forwarder on any such links, even if RB1 is in overload 🍓.

There's also the case where it's unavoidable to appoint an RBridge in overload as Appointed Forwarder, because ALL the RBridges on the link are in overload 😩.

None of these cases breaks the IS-IS standard's rule against routing through an overloaded node. Being an Appointed Forwarder is about the ingress and egress of native frames, and has nothing to do with IS-IS routing of TRILL Data packets through a TRILL switch 🦋.

Overload doesn't affect DRB election, but a TRILL switch in overload MAY reduce its own priority to be the DRB 🧚.

2.5. VLAN Mapping within a Link

TRILL Hellos include a field that's set to the VLAN they were sent in, when they're sent on a link technology like Ethernet that has outer VLAN labeling 🎀. (For link technologies like PPP that don't have outer VLAN labeling, this Hello field gets ignored 🙂.) If a TRILL Hello arrives on a different VLAN than the one it was sent on, then VLAN mapping is happening within the link 👀. VLAN mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for those VLANs are different. If that kind of mapping within a link were allowed and happened on two or more links so there was a cycle of VLAN mappings, a multi-destination frame would loop forever 😱. Such a frame would be "immortal" 💀. For a specific example, see Appendix B 📖.

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 that the same TRILL switch (possibly the DRB) is the Appointed Forwarder on the link for both VLAN-x and VLAN-y 👑💅.

3. The Inhibition Mechanism ✨

okay bestie, this is where the timers come in and honestly they're giving drama 💅 A TRILL switch has, for every link where it can offer end-station service (aka every link where it can act as an Appointed Forwarder), these timers, all counted in seconds:

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

The DRB and root bridge change inhibition timers MUST be implemented. Non-negotiable, no cap 🔥

Now the VLAN timers. Losing native traffic because of inhibition gets way smaller if you logically give each VLAN its own inhibition timer, for every VLAN the RBridge will ever offer end-station service on that link. This SHOULD be done 🌸 (Appendix A has an example of a problem that VLAN inhibition timers fix, go peek at it 👀) But real life is messy, and if the hardware can't handle a full set, you can merge the VLAN timers for more than one VLAN into one timer, carefully 🧚 Just know the one rule: an RBridge MUST NOT merge the VLAN inhibition timers for two VLANs if it's the Appointed Forwarder for one of them but not the other, because that can cause unnecessary, indefinitely prolonged inhibition 💀 Even if you only get two VLAN inhibition timers, you can still be safe: one for the VLANs where the RBridge is the Appointed Forwarder, and one for everything else. So at least two VLAN inhibition timers MUST be implemented 🫶 When a timer stands in for several VLANs, any update or test that would've hit one of those VLANs' timers hits the merged timer instead.

Here's how the timers get set:

  1. On boot or a management reset, each port gets its own set of timers, even if several ports are on the same link, because the TRILL switch hasn't had a chance to figure out yet that they share a link 🤷‍♀️ Every inhibition timer starts as "expired", except the DRB inhibition timer, which is set according to item 2 below. The DRB timer is special because every port initially thinks it's the DRB, lol 😭
  2. When a TRILL switch 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 a TRILL switch decides it has lost DRB status on a link, it sets the DRB inhibition timer to "expired" 👋
Note: In the corner case where one port of a TRILL switch won the DRB election but later lost it to a different port of the same TRILL switch on that link (maybe because of management configured port priorities), neither item 2 nor item 3 applies, and the DRB timer doesn't change. Plot twist, but it's fine 🙈
  1. When a TRILL switch RB1 receives a TRILL Hello saying 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, RB1 sets its VLAN-x inhibition timer for the link to whichever is longer: (1) that timer's existing value or (2) the Holding Time in the received Hello 🦋 And a TRILL switch MUST maintain VLAN inhibition timers covering any link it connects to if it can offer end-station service there, even if it isn't currently the Appointed Forwarder for any VLAN on that link. No skipping!! 💖
  2. When a TRILL switch RB1 enables VLAN-x on a port connected to a link, and VLAN-x wasn't enabled on any of RB1's ports on that link before, RB1 sets its VLAN inhibition timer for VLAN-x on that link to the 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 as something else 🌈 Remember, inhibition has zero effect on TRILL Data or IS-IS packets. It only affects native frames. Iconic behavior, honestly 👑
  3. When a TRILL switch detects a change in the common spanning tree root bridge on a port, it sets the root bridge change inhibition timer for the link to a value that defaults to 30 seconds and can be configured anywhere from 30 down to 0 seconds ⭐ This only happens if the TRILL switch is receiving Bridge PDUs (BPDUs) on that port from an attached bridged LAN. If no BPDUs are coming in, this timer never gets set 🙃 It's safe to configure this inhibition time to match the settling time of the attached bridged LAN. For example, if the Rapid Spanning Tree Protocol (RSTP) [802.1Q] is running through the whole attached bridged LAN, it's safe to set this to 7 seconds. Or, if the attached bridges have a minimum Bridge Hello Timer configured, it's safe to set it to 4 seconds 🍓 More optimizations are in Section 3.2 btw.
  4. When a TRILL switch 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 one set. The merged timers start at the longest value of the matching 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 must be on two or more links (up to one per port). To handle this, it clones a copy of the timers for each of those links 🎀

3.1. Inhibited Appointed Forwarder Behavior 🎀

Inhibition has no effect on receiving or forwarding TRILL Data packets or TRILL IS-IS packets. It only affects ingressing and egressing native frames 💅

An Appointed Forwarder for a link is inhibited for VLAN-x if:

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

If a VLAN-x Appointed Forwarder for a link is inhibited and receives a TRILL Data packet whose encapsulated frame would normally be egressed to that link in VLAN-x, it decapsulates the native frame as usual. But it does NOT output it to that link or queue it for that link. If it makes sense (say the frame is multi-destination), it may still output 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 gets ignored, except for address learning 🙈

A TRILL switch with one or more unexpired inhibition timers (possibly including one covering VLAN-x) is still required to indicate in the TRILL Hellos it sends on VLAN-x whether or not it's the Appointed Forwarder for VLAN-x on the port where it sends the Hello. Always show your work, bestie 📝

3.2. Root Bridge Change Inhibition Optimizations 🌸

The subsections below specify three optimizations that can shorten the inhibition time of an RBridge port in certain situations, when the root Bridge ID [802.1Q] received on that port changes. That means less transient interruption in end-station service caused by inhibition 🧚 TRILL switches MAY implement these optimizations. In the first two, inhibition can be skipped entirely in some situations. Heads up though: these optimizations are a bit heuristic. If several changes happen in a bridged LAN at the same time (or close to it), the optimizations make transient looping more likely ⚠️

3.2.1. Optimization for Change to Lower Priority 🍑

Assume the root Bridge ID received on an RBridge port changes to a new root Bridge ID with lower priority and a different root Bridge MAC address, due to a single change in the bridged LAN. There are two possible reasons for this:

  1. The bridged LAN the port is connected to has partitioned into two or more parts (because of link failure or something else), and the port is connected to a part that doesn't contain the original root bridge.
  2. The original root bridge has been reconfigured to a lower priority, and a new root has taken over.

Both of these are safe conditions that don't need inhibition. Slay 👑

3.2.2. Optimization for Change to Priority Only 💖

Assume the root Bridge ID changes due to a single change in the bridged LAN, but only the explicit priority part changes. That means the 48-bit MAC address portion of the root Bridge ID stays the same, and the root bridge has just been reconfigured to a different priority. So it's the same bridge as root, and no topology change is indicated. Therefore it's safe to ignore this kind of root Bridge ID change and not invoke the inhibition mechanism 🌈

3.2.3. Optimizing the Detection of Completed Settling ✨

okay so the scary case 😭 is when bridged LANs that used to be separate TRILL links in the same campus get merged. Those links may have had different Appointed Forwarders on them for the same VLAN, so without inhibition, loops involving those VLANs could happen after the merger. yikes 💀

Only native frames that get egressed and ingressed by RBridges are a potential problem. TRILL Data packets are either:

  1. individually addressed (TRILL Header M bit = 0) and will just be ignored if they get delivered to any incorrect TRILL switch ports, or
  2. multicast (TRILL Header M bit = 1), in which case the Reverse Path Forwarding Check discards any copies delivered to incorrect TRILL switch ports 🗑️

So there's no need for inhibition to touch the sending or receiving of TRILL Data packets, and inhibition doesn't do that. 🙅‍♀️

Root bridge change inhibition is only needed until TRILL Hellos have been exchanged on the merged bridged LAN 🫶 Hellos show Appointed Forwarder status, and in general, once Hellos have been exchanged, the new merged bridged LAN link will (if necessary) be made TRILL loop safe by VLAN inhibition. That means root bridge change inhibition is no longer needed, bestie. 🌸

TRILL switches are required to advertise in their link state the IDs of the root Bridge IDs they can see. If an RBridge port sees a change in root Bridge ID from Root1 to Root2, it is safe to end root bridge change inhibition on that port as soon as Hellos have been received on the port from all RBridges that can see Root1 or Root2, except any such RBridge that is no longer reachable. main character energy 👑

Here's the detailed version. When RB1 notices a change from Root1 to Root2 at one of its ports, it attaches a list to that port. The list holds every reachable RBridge (other than itself) that said in its LSPs that it could see either Root1 or Root2. Then RB1 removes from that list any RBridge that becomes unreachable from RB1, or any RBridge it has received a Hello from on that port. If the root Bridge ID changes again before the list is empty, say to Root7, then the RBridges reporting in their LSPs that they can see Root7 get added to the list. Root bridge change inhibition can be ended for the port as soon as either the timeout is reached or the list of RBridges is empty. ⏰

If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in effect at an RBridge port and say no inhibition is needed, then this mechanism isn't needed either. 💅

4. Optional TRILL Hello Reduction

If a network manager is really confident that they know the configuration of bridges, ports, and the like within an Ethernet link, they might be able to cut down the number of TRILL Hellos sent on that link by sending Hellos in fewer VLANs. For example, that works if all TRILL switches on the link will see all Hellos without VLAN constraints. 🧚 But adjacencies get established in the Designated VLAN, so an RBridge MUST always attempt to send Hellos in the Designated VLAN. no exceptions, periodt 💜

Hello reduction makes TRILL less robust when VLAN connectivity inside a link drops, like with partitioned VLANs, VLANs disabled on ports, or disagreement over the Designated VLAN 🙈 Still, as long as all RBridge ports on the link are configured for the same Desired Designated VLAN [RFC6325], can see each other's frames in that VLAN, and use the mechanisms below to update VLAN inhibition timers, things stay safe. ✨ (These concerns don't come up on links between RBridges configured as point to point. On those links, each RBridge only sends point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames in what it believes to be the Designated VLAN of the link (although it may send them untagged), and no native frame end-station service is provided. So for those links, there's no reason to send Hellos in any VLAN other than the Designated VLAN. 💖)

The configurable set of "Announcing VLANs", described in Section 4.4.3 of [RFC6325], gives the TRILL base protocol a way to reduce TRILL Hellos. 🦋

To keep loops safe when frames get lost now and then, or when RBridges or links fail, or new RBridges come up on a link (and so on), the inhibition mechanism in Section 3 is still required 🔒 Strictly following Section 3, a VLAN inhibition timer can only be set by receiving a Hello sent or received in that VLAN. So sending fewer TRILL Hellos on fewer VLANs safely needs extra mechanisms to set the VLAN inhibition timers at an RBridge. There are two of these, and they expand on the mechanisms in Section 3. Support for both is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (Section 5.4 of [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 its adjacencies on that link (excluding those in the Down state [RFC7177]) indicate support for these mechanisms and the mechanisms are 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 self-appointment Appointed Forwarders sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hellos sent by RB2. This tells everyone the sender believes it is Appointed Forwarder for those VLANs. 🎀 For each of an RBridge's VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV, the RBridge sets that timer to either (1) its current value or (2) the Holding Time of the Hello containing the sub-TLV, whichever is longer. This is backward compatible, meaning these sub-TLVs have no effect on any legacy receiving RBridge that doesn't implement this mechanism, unless RB2 (the sender) is the DRB sending Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link. 👑
  2. An RBridge MAY use the 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 for which RB2 is Appointed Forwarder. Each such timer gets updated to (1) its current value or (2) the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV, whichever is longer. RBridges that don't implement this will see the sub-TLV as unknown and 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 appear, the Hello isn't required to indicate all forwarder appointments.

There are two encodings here so VLAN listing stays efficient. Big blocks of contiguous VLANs are more efficiently encoded with the Appointed Forwarders sub-TLV, while scattered VLANs are more efficiently encoded 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 Appointed Forwarder for the VLAN the Hello is sent in. 💅

If the above mechanisms are used on a link, then each RBridge on the link MUST send Hellos in one or more VLANs with such VLANs Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s). The AF bit has to be set appropriately, so that no VLAN inhibition timer will improperly expire unless three or more Hellos are lost. For example, an RBridge could announce all the VLANs it believes it is Appointed Forwarder for in a Hello sent on the Designated VLAN three times per Holding Time. ⏳

A TRILL switch may have multiple ports on the same link. Some of these ports may be suspended because of MAC address duplication, as described in [RFC7177]. Suspended ports never ingress or egress native frames 🚫

If a TRILL switch has one or more non-suspended ports on a link, and those ports offer end-station service (meaning those ports aren't configured as point-to-point or trunk ports), then that TRILL switch is eligible to be an Appointed Forwarder for that link. It can become Appointed Forwarder in the ways discussed in Section 2. 🌈

If a TRILL switch that is 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. The one rule: there can't be any 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 TRILL switch is Appointed Forwarder for multiple VLANs, a straightforward approach is to split those VLANs among the ports it has on the link. 🍓

6. Port-Shutdown Messages

A TRILL switch may notice that one of its ports has failed, or it may be about to shut that port down. If the port is on a link along with ports of other TRILL switches, those TRILL switches won't notice the shutdown or failure using TRILL base protocol mechanisms until they fail to receive a number of Hellos from that port. That can take many seconds 😩 Network topology (adjacencies) and forwarder appointments can react much faster to a port shutdown or failure through explicit notification. As discussed below, this notification SHOULD be provided through the Port-Shutdown message. ⚡

6.1. Planned Shutdown and Hellos

A TRILL switch that is shutting down one of its ports (say P1) soon SHOULD reduce its Holding Time on that port. That way, the shutdown gets noticed more quickly by adjacent RBridges that might not support the Port-Shutdown message. 🦋

6.2. Port-Shutdown Message Structure ✨

okay so the Port-Shutdown message is an RBridge Channel message [RFC7178] using RBridge Channel Protocol number 0x006 🎀. Its Channel-specific payload is a list of Port IDs (see Section 4.4.2 of [RFC6325]) for the port or ports that have failed or are being shut down 🔌. You can tell other switches you support it just by advertising its RBridge Channel Protocol in the RBridge Channel Protocols sub-TLV [RFC7176] 💅.

      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
   TRILL Header:                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     | V |A|C|M| RESV  |F| Hop Count |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Egress Nickname         |       Ingress Nickname        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Special Inner.MacDA = All-Egress-RBridges             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Special Inner.MacDA (cont.)  |         Inner.MacSA           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Inner.MacSA (cont.)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    VLAN Tag Ethertype=0x8100  | Priority=7, DEI=0, VLAN ID=1  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   RBridge Channel Header:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Flags        | ERR=0 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Information specific to the Port-Shutdown Channel Protocol:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID 1                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID 2                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID K                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3. Port-Shutdown Message Transmission 📮

For robustness, a TRILL switch sends a configurable number of copies of Port-Shutdown messages, spaced out by a configurable time interval 🧚. The default is two copies, but you can configure one or three instead, and the default interval is 20 milliseconds (see Section 6.6). Like any "adjacency critical" message, the Port-Shutdown message SHOULD be sent with the highest priority, which is priority 7 👑, and SHOULD NOT be marked as "drop eligible" 🙅‍♀️.

If RB2 detects that port P1 on it has failed, the Port-Shutdown message announcing this is sequentially unicast through the rest of the TRILL campus to all RBridges (1) that P1 had an adjacency with and (2) that are advertising support for the Port-Shutdown RBridge Channel Protocol 🦋.

If a port shutdown is planned within 1 second, the TRILL switch stops sending Hellos out of the port being shut down 🛑. Then it either (1) sends the Port-Shutdown message to RBridge ports on the link that advertise support for the Port-Shutdown RBridge Channel Protocol, or (2) broadcasts the Port-Shutdown message announcing this event through the port, as follows:

  • The Outer.MacDA is the All-RBridges multicast address.
  • If an outer VLAN tag is present, it specifies the Designated VLAN for the link, SHOULD specify priority 7, and SHOULD NOT specify "drop eligible".
  • In the TRILL Header, the egress nickname is All-RBridges, and the M bit in the TRILL Header is set to 0.
  • In the RBridge Channel Header, the MH and NA bits are zero.

Also, there's no need for a special message when port P1 comes back up or when a shutdown gets "canceled" 🌈. Switches just start sending Hellos out of port P1 again, and that's the whole signal ✨.

6.4. Port-Shutdown Message Reception 🫶

When a TRILL switch RB1 receives a Port-Shutdown message, it checks whether the ingress nickname points to a TRILL switch RB2 that RB1 has one or more adjacencies with 🔍. If it does, RB1 drops the adjacencies that go to RB2 ports whose Port IDs are listed in the message 💔. There could be more than one, if RB2 had several ports on the link going down at once 🍓.

If RB1 is the DRB and this wipes out every adjacency on the link between the DRB and RB2, then for all VLANs that RB2 was handling ingress and egress for, the DRB either starts acting as Appointed Forwarder itself, or appoints some new TRILL switch it has an adjacency with as Appointed Forwarder 👑😭.

6.5. Port-Shutdown Message Security 🔐

Port-Shutdown messages can be secured using the RBridge Channel Header Extension security feature [RFC7978] 🛡️.

6.6. Port-Shutdown Configuration ⚙️

There are two Port-Shutdown configuration parameters, listed below. Section 6.3 explains how to use them 💜.

   Parameter            Default                 Range
   ---------------   ----------------   ---------------------
   PShutdownRepeat     2                 1-3
   PShutdownDelay     20 milliseconds    0-1,000 milliseconds

7. FGL-VLAN Mapping Consistency Checking 🌸

okay so TRILL switches support 24-bit Fine-Grained Labels as specified in [RFC7172] 🏷️. Basically, a VLAN ID in native traffic between an edge TRILL switch and an end station gets mapped to or from an FGL, carried as an Inner.Label in TRILL Data packets ✨. Since the Appointed Forwarder for a VLAN is the one ingressing and egressing that native traffic, the mapping configured at the Appointed Forwarder is the mapping that actually gets used 💅.

Here's the catch 🙈: the Appointed Forwarder for VLAN-x on a link can change for reasons discussed elsewhere in this document. So all TRILL switches on a link that are configured with an FGL-VLAN mapping SHOULD have the same mapping 🫶. Otherwise, traffic might unpredictably jump from one FGL to another whenever the Appointed Forwarder changes 😱. TRILL switches SHOULD advertise their mapping on the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs (Sections 10.4 and 10.5), so that consistency checking can be automated 🤖.

A TRILL switch SHOULD compare the FGL-VLAN mappings it sees other TRILL switches advertising on a link with its own, and alert the network operator if they don't match 👀. "Inconsistent" means that (1) one TRILL switch maps FGL-z to VLAN-x while another maps FGL-z to VLAN-y, or (2) one TRILL switch maps VLAN-x to FGL-w while another maps VLAN-x to FGL-z, all on the same link 💀.

Depending on how the network is managed, a transient inconsistency may not be a big deal 🌤️. So the network operator SHOULD NOT be alerted unless the inconsistency persists for a period of time. That period defaults to the TRILL switch's Holding Time, and it's configurable anywhere from 0 seconds to 216 - 1 seconds 🕰️. The value 216 - 1 is special: it means the alerts are disabled 🔕.

8. Support of E-L1CS 🦋

All TRILL switches MUST support the E-L1CS flooding scope [RFC7356], Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs [IS-IS] 👑. Any TRILL switch on a link can tell if another switch on that link is a legacy implementation without E-L1CS support, because, as stated in [RFC7780], all TRILL switches MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send 🔍. Supporting E-L1CS boosts how much information each TRILL switch can sync on the link, compared with what Hellos can carry, by several orders of magnitude 🚀.

For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs (Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356]) MUST NOT exceed 1,470 bytes in length 📏. However, if one arrives that's longer than 1,470 bytes, it still gets processed normally 🙌.

Like any type of IS-IS LSP, FS-LSPs are identified by the System ID of the originating router (TRILL switch) and the fragment number 🪪. There's no port identifier in the header of an E-L1CS PDU 🙈. So a TRILL switch RB1 with more than one non-suspended port on a link (Section 5) that transmits such a PDU MAY transmit it out of any one or more of those ports 🎀. RB1 will generally receive such a PDU that other TRILL switches send on all of RB1's ports on the link 📬. And with multiple ports on the link, it will also receive any such PDU that it sends on the ports other than the one it transmitted on 🔁.

8.1. Backward Compatibility 🕰️

Future TRILL specifications that use E-L1CS MUST specify how situations are handled when one or more TRILL switches attached to a TRILL link support E-L1CS and one or more don't 🧩.

9. Security Considerations 🔒

This document provides improved documentation of the TRILL Appointed Forwarder mechanism 📖. It does not change the security considerations of the TRILL base protocol, which are described in Section 6 of [RFC6325] 💜.

The Port-Shutdown messages specified in Section 6 are sent using the RBridge Channel facility [RFC7178] 📨. Such messages SHOULD be secured using the RBridge Channel Header Extension [RFC7978] 🔐. If they aren't adequately secured, they're a potential denial-of-service vector 😱💀.

The E-L1CS FS-LSPs added by Section 8 are a type of IS-IS PDU [RFC7356] 🧾. That means they can be secured by adding Authentication TLVs [RFC5310], the same way you'd secure Hellos or other IS-IS PDUs 🫶.

10. Code Points and Data Structures 🎀

This section covers the IANA considerations for this document, and specifies the structures of the AppointmentBitmap, AppointmentList, VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs ✨. These APPsub-TLVs appear within a TRILL GENINFO TLV [RFC7357] in E-L1CS FS-LSPs [RFC7356] 🌈.

10.1. IANA Considerations 📋

IANA has assigned four new APPsub-TLV type codes from the range below 255, and entered them in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows 💅:

   Type   Name                 Reference
   ----   -----------------    ---------
   17     AppointmentBitmap    [RFC8139]
   18     AppointmentList      [RFC8139]
   19     FGL-VLAN-Bitmap      [RFC8139]
   20     FGL-VLAN-Pairs       [RFC8139]

IANA has also assigned a new RBridge Channel Protocol number from the range assigned by Standards Action [RFC5226], and updated the "RBridge Channel Protocols" registry as follows 🦋:

    Protocol  Description     Reference
    --------  --------------  ---------
     0x006    Port-Shutdown   [RFC8139]

Last but not least, IANA has updated the reference for the "Hello reduction support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry so it points to this document 🫶🔥.

10.2. AppointmentBitmap APPsub-TLV ✨

Okay bestie, the AppointmentBitmap APPsub-TLV is the efficient way for a TRILL switch to say which other TRILL switches it's appointing as forwarders for which VLAN IDs 💅. It's only the move when the VLAN IDs are pretty compact, meaning they don't stretch across a huge numeric range. And the appointment only counts when the switch doing the appointing is the DRB 👑.

                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Type                    |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Length                  |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Appointee Nickname      |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | RESV  |   Starting VLAN ID    |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Bit Map ...                      (variable)
         +-+-+-+-+-+-+-+-...
  • Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV 17.
  • Length: 4 + size of bit map in bytes. If Length is less than 4, the APPsub-TLV is corrupt and MUST be ignored. 🚫
  • Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder. 🎀
  • RESV: 4 bits that MUST be sent as zero and ignored on receipt.
  • Starting VLAN ID: The smallest VLAN ID that the bits in the Bit Map line up with. 🌸
  • Bit Map: A bit map of the VLANs for which the TRILL switch with Appointee Nickname is appointed as the forwarder. The size of the bit map is length minus 4. If the size of the bit map is zero, no appointments are made.

Each bit in the Bit Map matches up with a VLAN ID. Bit 0 is for the VLAN whose ID shows up in the Starting VLAN ID field. Bit 1 is for that VLAN ID plus 1 (treating VLAN IDs as unsigned integers), and it keeps going like that, with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and VLAN 0xFFF, or any bigger ID, are invalid and get ignored. 🙈

If the DRB on a link is the one originating the AppointmentBitmap APPsub-TLV, it appoints the TRILL switch whose nickname sits in the Appointee Nickname field for the VLAN IDs that have 1 bits in the Bit Map. It also revokes any Hello appointment of that TRILL switch for the VLANs that have 0 bits in the Bit Map. Main character energy, honestly 🦋.

10.3. AppointmentList APPsub-TLV 🧚

The AppointmentList APPsub-TLV is the more convenient option when a TRILL switch wants to say which TRILL switches it appoints as forwarders for which VLAN IDs. Same deal as before: the appointment only works when the switch doing it is the DRB 👑.

                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Type                    |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Length                  |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Appointee Nickname      |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | RESV  |   VLAN ID 1           |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | RESV  |   VLAN ID 2           |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | RESV  |   VLAN ID k           |   (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: APPsub-TLV type, set to AppointmentList sub-TLV 18.
  • Length: 2 + 2 * k. If Length is not an even number, the APPsub-TLV is corrupt and MUST be ignored. 🚫
  • Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder. 🎀
  • RESV: 4 bits that MUST be sent as zero and ignored on receipt.
  • VLAN ID: A 12-bit VLAN ID that the appointee is being appointed as the forwarder for. 🌸

Type and Length are 2 bytes each, because these are extended FS-LSPs. ✨

When the DRB originates this APPsub-TLV, it appoints the TRILL switch with that Appointee Nickname to be the Appointed Forwarder for the VLAN IDs on the list. Simple and iconic 💜.

10.4. FGL-VLAN-Bitmap APPsub-TLV 🌈

The FGL-VLAN-Bitmap APPsub-TLV lets a TRILL switch say which FGLs it maps to which VLAN IDs when it's egressing and ingressing native frames. That's the whole job 💖.

This coding is efficient when both of these are true:

  • the VLAN IDs are compact (meaning they don't span a large numeric range), and
  • the FGLs and VLAN IDs are paired up in a monotonically increasing fashion.
                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Type                    |                 (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Length                  |                 (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  RESV |   Starting VLAN ID    |                 (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Starting FGL                                | (3 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Bit Map ...                                   (variable)
         +-+-+-+-+-+-+-+-...
  • Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV 19.
  • Length: 5 + size of bit map in bytes. If Length is less than 5, the APPsub-TLV is corrupt and MUST be ignored. 🚫
  • RESV: 4 bits that MUST be sent as zero and ignored on receipt.
  • Starting VLAN ID: Initial VLAN ID for the mapping info, as discussed below. 🌸
  • Starting FGL: Fine-Grained Label [RFC7172].
  • Bit Map: Map of bits for VLAN-ID-to-FGL mappings. The size of the bit map is Length minus 5. If the size of the bit map is zero, no mappings are indicated.

Each bit in the Bit Map lines up with a VLAN ID and an FGL. Bit 0 is for the VLAN whose ID shows up in the Starting VLAN ID field, paired with the Fine-Grained Label in the FGL field. Bit 1 is for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as unsigned integers), and so on, with Bit N generally being Starting VLAN ID plus N and FGL plus N. 🎀

If a Bit Map bit is a 1, it tells you the advertising TRILL switch will map between that VLAN ID and FGL on ingressing native frames and egressing TRILL Data packets, as long as it's the Appointed Forwarder for that VLAN. If a Bit Map bit is a 0, there's no configured mapping of that VLAN ID to that FGL being indicated. Still, VLAN ID 0x000 and VLAN ID 0xFFF or any larger ID are invalid, and FGLs larger than 0xFFFFFF are invalid too. Any Bit Map bits that match up with an illegal VLAN ID or an illegal FGL get ignored. 🙈

10.5. FGL-VLAN-Pairs APPsub-TLV 💅

The FGL-VLAN-Pairs APPsub-TLV is another way for a TRILL switch to share a list of the FGL-to-VLAN-ID mappings it's set up to use when egressing and ingressing native frames. Think of it as the list version of the bitmap one 📝.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Type                    |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length                  |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD 1                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD 2                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |      ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD k                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      Where a Mapping RECORD has the following structure:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RESV |   VLAN ID             |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       FGL                                     | (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV 20.
  • Length: 5 * k. If Length is not a multiple of 5, the APPsub-TLV is corrupt and MUST be ignored. 🚫
  • RESV: 4 bits that MUST be sent as zero and ignored on receipt.
  • VLAN ID: 12-bit VLAN label. 🌸
  • FGL: Fine-Grained Label [RFC7172].

Each Mapping RECORD says the originating TRILL switch is set up to map between that FGL and VLAN when egressing and ingressing native frames. VLAN ID 0x000 and VLAN ID 0xFFF are invalid, so any Mapping RECORD pointing at an illegal VLAN ID gets ignored 🙈.

11. Management Considerations 🎀

This document mostly adds optional enhancements or optimizations, so it's not a configuration-heavy vibe. The only configuration parameters specified here are the number and frequency of copies of Port-Shutdown messages sent, as laid out in Section 6.6 🌸.

TRILL switch support of SNMPv3 is covered in the TRILL base protocol document [RFC6325]. MIBs have been specified in [RFC6850] and [RFC7784], but they don't include the configurable parameters specified in this document. YANG modules are expected to be specified for TRILL later on, so keep an eye out 👀🦋.

12. References 📚

12.1. Normative References ✨

okay bestie, these are the must-read docs 📚 the spec is built on top of. every single one gets listed here with all its details, no skipping 💅

12.2. Informative References 🦋

these ones are just extra reading, super helpful for the vibes but not required to get the core spec 🌸

Appendix A. VLAN Inhibition Example 🎀

okay so the per-VLAN inhibition timers (or the equivalent) are needed to stay loop safe when bridges on a link are misconfigured 🙈

for a simple example, imagine RB1 and RB2 are the only RBridges on the link 🌈 RB1 has higher priority to be the DRB, and they both want VLAN 1 (the default) to be the Designated VLAN. but here's the tea: there's a bridge between them set up so RB1 can see all the frames sent by RB2, but none of the frames from RB1 can get through to RB2 💀

both of them think they're the DRB 😭 RB1 because it's higher priority even though it sees the Hellos from RB2, and RB2 because it doesn't see the Hellos from RB1 and therefore thinks it's the highest priority. main character confusion 👑

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 end up with a loop involving VLAN 3 🔥 RB1 will see the Hellos that RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 gets inhibited on VLAN 3. RB2 doesn't see the Hellos issued by RB1 on VLAN 3, so RB2 becomes uninhibited and handles VLAN 3 native traffic 🦋

but this situation can change, bestie 😵 RB2 might crash, the bridge might crash, RB2 might be reconfigured so it no longer tries to act as Appointed Forwarder for VLAN 3, or other issues may occur. so RB1 has to maintain a VLAN 3 inhibition timer 🧚 and if it sees no Hellos from any other RBridge on the link claiming to be Appointed Forwarder for VLAN 3 for 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 ✨

this one is giving a full-on loop drama 🍓 assume RBridges RB1 and RB2 have ports P1 and P2, respectively, that are both on Link L1, and RBridges RB3 and RB4 have ports P3 and P4, respectively, that are both on Link L2. then assume P1 and P3 are Appointed Forwarders for VLAN-x, and P2 and P4 are Appointed Forwarders for VLAN-y. here's the picture 👇

          + - - - - - - - - - - - - - - - - - - - - - +
          |                                           |
          |                TRILL network              |
          |                                           |
          |  +---+   +---+             +---+   +---+  |
          + -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- +
             +---+   +---+             +---+   +---+
            P1|       P2|             P3|       P4|
              |         |               |         |
              |x        |y              |x        |y
              |   +-+   |               |   +-+   |
        L1 ---+---|M|---+--+---   L2 ---+---|M|---+---
                  +-+      |                +-+
                         +---+
                         |ES1|
                         +---+

further assume that L1 and L2 are each bridged LANs that include a device M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into VLAN-x 🫶

so if end station ES1 originated a broadcast or other multi-destination frame in VLAN-y, it would be ingressed by RB2. (the frame would also be mapped to VLAN-x and ingressed by RB1, but we're initially ignoring that 🙃) RB2 floods the resulting TRILL Data packet through the campus, and, at least in the broadcast and unknown unicast cases, it gets to RB4, where it's egressed to L2. inside L2, this broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 then floods the resulting TRILL Data packet through the campus, this time with an Inner.VLAN of VLAN-x, which means it gets egressed by RB1 into L1. inside L1, it's mapped back to VLAN-y and then ingressed by RB2, completing the loop 🌀 the packet loops indefinitely, because in native form on L1 and L2 it has no TRILL Hop Count, so an indefinitely large number of copies gets delivered to ES1 and any other end station so situated 😱 the same problem would occur even if P1 and P2 were on the same RBridge and/or P3 and P4 were on the same RBridge. actually, because the original frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there are two copies looping around in opposite directions 🙀

the use of Fine-Grained Labels [RFC7172] complicates things but doesn't essentially change the potential problem 💜

this example shows why VLAN mapping between Appointed Forwarder ports on a TRILL link is loop unsafe 🚨 when such a situation is detected, the DRB on the link changes Appointed Forwarders as necessary to assure that a single RBridge port is Appointed Forwarder for all VLANs involved in mapping. this change makes the situation loop safe 🥹✨

Appendix C. Changes to RFCs 6325, 6439, and 7177 🦋

Okay bestie, this is the final appendix and it's the "what changed?" tea ☕ Basically, this document touches a few older TRILL RFCs, so here's the full rundown 💅

This document updates [RFC6325], obsoletes [RFC6439], and updates [RFC7177].

The change to [RFC6325], the TRILL base protocol, is as follows: addition of mandatory support for E-L1CS FS-LSPs 🌸

Changes to [RFC6439], which this document obsoletes, are as follows:

  1. Specification of APPsub-TLVs and procedures to be used in E-L1CS FS-LSP forwarder appointments ✨
  2. Incorporation of updates to [RFC6439] that appeared in Section 10 of RFC 7180, which has been obsoleted by [RFC7780]. They appear primarily in Section 4 of this document 🧚
  3. Addition of an optional FGL-VLAN consistency check feature, including specification of APPsub-TLVs 🎀
  4. Deletion of references to the October 2011 version of the document "RBridges: Campus VLAN and Priority Regions" (draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by the TRILL WG 🙈
  5. Addition of the Port-Shutdown message 🦋
  6. Elimination of the requirement that the DRB not send appointments in Hellos until its DRB inhibition timer has expired. This was an unnecessary safety precaution that is pointless, given that appointments in E-L1CS FS-LSPs are immediately visible 💀
  7. Addition of three optional methods (Section 3.2) to optimize (reduce) inhibition time under various circumstances ⚡
  8. Editorial changes 🫶

Changes to [RFC7177] are as follows:

As provided in Section 6, TRILL switches SHOULD treat the reception of a Port-Shutdown RBridge Channel message from RB1 listing port P1 as if it were an event A3 as specified in [RFC7177], resulting in transition of any adjacency to P1 to the Detect state. 💜

Acknowledgments 🫶

The following are hereby thanked for their contributions to this document:

Spencer Dawkins, Shawn M. Emery, Stephen Farrell, Joel Halpern, Sue Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan Romascanu, and Mingui Zhang.

The following are thanked for their contributions to [RFC6439], the predecessor to this document:

Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand.

We also thank Radia Perlman, who coauthored [RFC6439] 🌈

Authors' Addresses 💅

Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA  01757
United States of America

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


Mohammed Umair
IP Infusion

Email: mohammed.umair2@ipinfusion.com


Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134
United States of America

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