RFC 9183

Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)

📅 published February 2022, from ietf

📮 The Paperwork Tea First

Okay bestie, let's get the header info sorted 💅 This is RFC 9183, titled "Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)" 🎀 It's a Standards Track doc from February 2022, with ISSN 2070-1721 ✨

The authors are M. Zhang (Independent), D. Eastlake 3rd (Futurewei), R. Perlman (EMC), M. Cullen (Painless Security), and H. Zhai (JIT) 🫶 There's no Obsoletes or Updates line in the header, so this one doesn't list anything it replaces or changes 🌸

Abstract ✨

A big issue in multilevel TRILL is figuring out how to manage RBridge nicknames 🧚 In this doc, area border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 have to get unique nicknames, but RBridges in different Level 1 areas can end up with the same nicknames 💜

Status of This Memo 📝

This is an Internet Standards Track document 🔥

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 👑 It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 🌈

Info about the current status of this doc, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9183 ✨

Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🍓

Table of Contents 🗺️

1.  Introduction
2.  Acronyms and Terminology
3.  Nickname Handling on Border RBridges
  3.1.  Actions on Unicast Packets
  3.2.  Actions on Multi-destination Packets
4.  Per-Flow Load Balancing
  4.1.  L2-to-L1 Ingress Nickname Replacement
  4.2.  L1-to-L2 Egress Nickname Replacement
5.  Protocol Extensions for Discovery
  5.1.  Discovery of Border RBridges in L1
  5.2.  Discovery of Border RBridge Sets in L2
6.  One Border RBridge Connects Multiple Areas
7.  E-L1FS/E-L2FS Backwards Compatibility
8.  Manageability Considerations
9.  Security Considerations
10. IANA Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Appendix A.  Level Transition Clarification
Authors' Addresses

1. Introduction 🌷

TRILL (Transparent Interconnection of Lots of Links) [RFC6325] [RFC7780] multilevel techniques are designed to fix TRILL scalability issues 💅

"Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)" [RFC8243] is an educational doc that explains multilevel TRILL and lists possible concerns. It doesn't specify a protocol 📚 As [RFC8243] describes, there have been two proposed approaches. The first one, called the "unique nickname" approach, gives unique nicknames to all the TRILL switches in the multilevel campus. It does this either by having the Level 1/Level 2 border TRILL switches advertise which nicknames aren't available for assignment in the area, or by splitting the 16-bit nickname into an "area" field and a "nickname inside the area" field 🎀 [RFC8397] is the Standards Track doc that specifies a "unique nickname" flavor of TRILL multilevel 🦋 The other approach, which [RFC8243] calls the "aggregated nickname" approach, assigns nicknames to the areas and lets nicknames get reused inside different areas. The border TRILL switches rewrite the nickname fields when packets enter or leave an area 🧚 [RFC8243] makes the case that, while unique nickname multilevel solutions are simpler, aggregated nickname solutions scale better 💜

The approach in this Standards Track doc is kind of similar to the "aggregated nickname" approach in [RFC8243], but with one really important difference ✨ Here, the nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No extra nicknames get assigned to represent L1 areas as such. Instead, multiple border RBridges are allowed, and each L1 area is denoted by the set of all nicknames of that area's border RBridges 🌈 For this approach, nicknames in the L2 area MUST be unique, but nicknames inside an L1 area can be reused in other L1 areas that also use this approach 🫶 Using this doc's approach in one L1 area doesn't stop other approaches from being used in other L1 areas in the same TRILL campus. For example, the unique nickname approach from [RFC8397] is fine to use alongside it 🍓 The TRILL packet format is unchanged by this doc, but data plane processing changes at Border RBridges. Efficient high-volume data flow at Border RBridges might need a forwarding hardware change 🔥

2. Acronyms and Terminology 📖

  • Area Border RBridge: A border RBridge between a Level 1 area and Level 2 🌸
  • Data Label: VLAN or Fine-Grained Label (FGL) 🎀
  • DBRB: Designated Border RBridge 💅
  • IS-IS: Intermediate System to Intermediate System [IS-IS] 🦋
  • Level: Like IS-IS, TRILL has Level 1 for intra-area stuff and Level 2 for inter-area stuff 🧚 Routing info gets exchanged between Level 1 RBridges within the same Level 1 area. Level 2 RBridges can only form relationships and swap info with other Level 2 RBridges 💜

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 🔥

Familiarity with [RFC6325] is assumed in this document 🙈

3. Nickname Handling on Border RBridges 🦋

This section gives an illustrative example and a description of border learning for border RBridge nicknames ✨

        Area {2,20}             Level 2             Area {3,30}
+-------------------+     +-----------------+     +--------------+
|                   |     |                 |     |              |
| S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D |
|     27            |     |      39         |     |     44       |
|                 ----RB20---             ----RB30---            |
+-------------------+     +-----------------+     +--------------+

          Figure 1: An Example Topology for TRILL Multilevel

In Figure 1, RB2, RB20, RB3, and RB30 are area border TRILL switches (RBridges) 🌷 Their nicknames are 2, 20, 3, and 30, respectively, and they're used as TRILL switch identifiers in their areas [RFC6325] 🧚 Area border RBridges use the set of border nicknames to denote the L1 area they're attached to. For example, RB2 and RB20 use nicknames {2,20} to denote the L1 area on the left 💖

A source S is attached to RB27, and a destination D is attached to RB44. RB27 has a nickname (say, 27), and RB44 has a nickname (say, 44). (In fact, they could even have the same nickname, since the TRILL switch nickname won't be visible outside these Level 1 areas 🙈)

3.1. Actions on Unicast Packets 💌

Let's say S transmits a frame to destination D, and D's location has already been learned by the relevant TRILL switches. These relevant switches have learned the following:

  1. RB27 has learned that D is connected to nickname 3.
  2. RB3 has learned that D is attached to nickname 44.

Here's the sequence of events that will happen 🎬

  1. S transmits an Ethernet frame with source MAC = S and destination MAC = D.
  2. RB27 encapsulates it with a TRILL header with ingress RBridge = 27 and egress RBridge = 3, producing a TRILL Data packet 🎀
  3. RB2 and RB20 have announced in the Level 1 IS-IS area designated {2,20} that they're attached to the nicknames of all the border RBridges in the Level 2 area, including RB3 and RB30. So IS-IS routes the packet to RB2 (or to RB20, if RB20 is on the least-cost route from RB27 to RB3) 🦋
  4. RB2, when moving the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, swapping 27 for 2. Inside Level 2, the ingress RBridge field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. (The egress nickname MAY be replaced with any area nickname selected from {3,30}, such as 30. See Section 4 for the details of the selection method. Here, suppose the egress nickname stays 3.) Also, RB2 learns that S is attached to nickname 27 in area {2,20} so it can handle return traffic 🧚 RB2 SHOULD synchronize with RB20 using the End Station Address Distribution Information (ESADI) protocol [RFC7357] to share that MAC = S is attached to nickname 27 💜
  5. The packet gets forwarded through Level 2 to RB3, which has advertised its L2 nickname as 3 in Level 2 🌈
  6. RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44), based on looking up D. (The ingress nickname MAY be replaced with any area nickname selected from {2,20}. See Section 4 for the details of the selection method. Here, suppose the ingress nickname stays 2.) So inside the destination area, the ingress nickname will be 2 and the egress nickname will be 44 ✨
  7. RB44, when decapsulating, learns that S is attached to nickname 2, which is one of the area nicknames of the ingress 🫶

3.2. Actions on Multi-destination Packets ✨

okay so distribution trees for flooding multi-destination packets get calculated separately inside each L1 area and also in L2 🌸 when one of these packets hits a border, it has to get transitioned either from L1 to L2 or from L2 to L1. every border RBridge is eligible for the Level transition, BUT only one of them per packet gets to be the Designated Border RBridge (DBRB) and do the transition. the other non-DBRBs MUST drop the copies they received 🙅‍♀️ by default, the border RBridge with the smallest nickname (read as an unsigned integer) becomes the DBRB. all border RBridges in an area MUST agree on how they figure out the DBRB locally. you can use a different mechanism, but that's out of scope for this doc, and one such mechanism shows up in Section 4 for load balancing 💅

so [RFC6325] sorts multi-destination packets into three types: unknown-unicast packets (unicast with unknown destination MAC addresses), multicast packets, and broadcast packets 🦋 let's say D's location hasn't been learned by RB27, or the frame RB27 got is broadcast or multicast. what happens inside a Level 1 area (same as in TRILL today) is that RB27 forwards it as multi-destination, sets its M bit to 1, picks an L1 tree, and the packet gets flooded on that tree (subject to potential pruning) 🌊

when the copies reach the area border RBridges, the non-DBRBs MUST drop the packet, and the DBRB (say, RB2) is the one that does the Level transition. for an unknown-unicast packet, if the DBRB has learned the destination MAC address, it SHOULD convert the packet to unicast and set its M bit to 0. if it hasn't, the packet just keeps getting flooded as a multicast packet on the distribution tree. the DBRB picks the new distribution tree by swapping the egress nickname for the new tree root RBridge nickname from the area the packet is entering. here's the play-by-play 🎀

  1. RB2, transitioning the packet from Level 1 to Level 2, swaps the ingress TRILL switch nickname for its own nickname, so 27 becomes 2. RB2 also MUST replace the egress RBridge nickname with an L2 tree root RBridge nickname (say, 39). to make sure return traffic can find its way back, RB2 records that S is attached to nickname 27, and it SHOULD use the ESADI protocol [RFC7357] to sync this attachment info with the other border RBridges (say, RB20) in the area 🧚
  2. RB20 gets the packet flooded on the L2 tree by RB2. this part matters: RB20 does NOT transition this packet back to L1 the way it normally would for a multicast packet coming from another remote L1 area 🙈 it should look at the ingress nickname of the packet. if that nickname turns out to be a border RBridge nickname of the area {2,20}, RB2 must not forward the packet into this area.
  3. the multi-destination packet gets flooded on the Level 2 tree so it reaches all border routers for all L1 areas, including both RB3 and RB30 🌈 say RB3 is the selected DBRB. then the non-DBRB RB30 drops the packet 💀
  4. RB3, forwarding into area {3,30}, swaps the egress nickname in the TRILL header for the root RBridge nickname of a distribution tree of L1 area {3,30}, say 30. (here, the ingress nickname MAY be replaced with a different area nickname picked from {2,20}, which is the set of border RBridges to the ingress area, as specified in Section 4.) now say RB27 has learned where D is (attached to nickname 3), but RB3 doesn't know, because that info fell out of cache, RB3 restarted, or some other reason. in that case, RB3 must turn the packet into a multi-destination packet and flood it on a distribution tree in L1 area {3,30} 🍓
  5. RB30 gets the packet flooded on the L1 tree by RB3. it's important that RB30 does NOT transition this packet back to L2 😤 RB30 should also check the ingress nickname of the packet. if that nickname is an L2 Border RBridge Nickname, RB30 must not transition the packet back to L2.
  6. the multicast listener RB44, once it decapsulates the packet, learns that S is attached to nickname 2, which is one of the area nicknames of the ingress 👑

see also Appendix A 🫶

4. Per-Flow Load Balancing ✨

okay this part is about load balancing 💖 area border RBridges do ingress/egress nickname replacement whenever they transition TRILL Data packets between Level 1 and Level 2. the egress nickname gets replaced again when the packet goes from Level 2 back to Level 1. this nickname swapping is what makes per-flow load balancing possible, and the subsections below spell it out 🦋 in general you need the mechanism in Section 4.1, or the one in Section 4.2, or both, to load-balance traffic across L2 paths 🔥

4.1. L2-to-L1 Ingress Nickname Replacement

when a TRILL Data packet from another L1 area arrives at an area border RBridge, this RBridge MAY pick one area nickname of the ingress area to replace the ingress nickname of the packet 🌸 that way, the returning TRILL Data packet can be forwarded to this picked nickname, which helps spread return unicast traffic across multiple paths. the pick is just a pseudorandom algorithm, the same one discussed in Section 5.3 of [RFC7357] ✨ with this random ingress nickname replacement, the border RBridge actually gets per-flow load balancing for returning traffic. so cute 💅

all area border RBridges for an L1 area MUST agree on the same pseudorandom algorithm 🤝 the source MAC address, ingress area nicknames, egress area nicknames, and the Data Label of the received TRILL Data packet are all candidate inputs to that algorithm. BUT the destination MAC address SHOULD be left out of the input 🙃 otherwise the egress RBridge could watch one source MAC address flip-flopping between multiple ingress RBridges, and nobody wants that drama 😭

4.2. L1-to-L2 Egress Nickname Replacement

when a unicast TRILL Data packet that started in an L1 area arrives at an area border RBridge of that L1 area, that RBridge MAY pick one area nickname of the egress area to replace the egress nickname of the packet 🧚 by default, it SHOULD choose the egress area border RBridge with the least cost route to reach it. if there are multiple equal cost egress area border RBridges, it uses the pseudorandom algorithm from Section 5.3 of [RFC7357] to pick one 🎀 that algorithm MAY be extended to choose among a stable set of egress area border RBridges that also includes non-least-cost alternatives, if you want more load spreading. the catch is that you'll sometimes end up using a non-least-cost Level 2 route to forward the TRILL Data packet to the egress area 🫠

5. Protocol Extensions for Discovery ✨

these topology change scenarios trigger the discovery processes defined in Sections 5.1 and 5.2 🌈

  • a new node comes up, or recovers from a previous failure 🌱
  • a node goes down 📉
  • a link or node fails and causes a partition of an L1/L2 area 💔
  • a link or node whose failure caused that partitioning gets repaired 🩹

5.1. Discovery of Border RBridges in L1

okay so the Level 1 Border RBridge APPsub-TLV goes inside E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV 🎀 by listening for this APPsub-TLV, an area border RBridge finds all the other area border RBridges in its area 👀 here's the layout:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = L1-BORDER-RBRIDGE      | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length                        | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sender Nickname               | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: Level 1 Border RBridge (TRILL APPsub-TLV type 256) 🧸
  • Length: 2 🧸
  • Sender Nickname: the nickname the originating IS will use as the L1 Border RBridge Nickname. this field is useful because the originating IS might own multiple nicknames 💜

5.2. Discovery of Border RBridge Sets in L2

this APPsub-TLV goes inside an E-L2FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV 🌸 by listening to it in L2, an area border RBridge discovers every group of L1 border RBridges, and each group identifies one area 🦋

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = L1-BORDER-RB-GROUP     | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length                        | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | L1 Border RBridge Nickname 1  | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | L1 Border RBridge Nickname k  | (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type 257) 🍓
  • Length: 2 * k. if the length isn't a multiple of 2, the APPsub-TLV is corrupt and MUST be ignored 🚫
  • L1 Border RBridge Nickname: the nickname that an area border RBridge uses as its L1 Border RBridge Nickname. the L1-BORDER-RB-GROUP TLV generated by an area border RBridge MUST include all L1 Border RBridge Nicknames of the area. it's RECOMMENDED that these k nicknames are ordered in ascending order, treating the 2-octet nickname as an unsigned integer 🌟

when an L1 area gets partitioned [RFC8243], the border RBridges rediscover each other in both L1 and L2 by exchanging LSPs 🧩 in L2, the set of border RBridge nicknames for the splitting area is going to change. any border RBridges that detect that change MUST flush the reachability information associated with any RBridge nickname from that changing set 🫶

6. One Border RBridge Connects Multiple Areas 🌸

Okay so it's totally possible for one border RBridge (say, RB1) to connect multiple L1 areas 👀. RB1 SHOULD use a single area nickname for itself across all of these areas, which keeps nickname consumption low and cuts down on how many nicknames get advertised in L2 ✨. Still, a border RBridge like this might end up holding multiple nicknames anyway. For example, it might be the root of multiple L1 or multiple L2 distribution trees 🌳.

Nicknames used inside one of these L1 areas can be reused in other areas, which is a whole vibe. It's super important that packets headed for those duplicated nicknames actually land in the right area 🎯. These areas are linked up to form a layer 2 network, so duplicated {MAC, Data Label} pairs across them SHOULD NOT occur (see Section 4.2.6 of [RFC6325] for tie breaking rules).

Now picture a TRILL Data packet arriving at the area border nickname of RB1 😳. For a unicast packet, RB1 can look up the {MAC, Data Label} entry in its MAC table to find the right destination area (i.e., the outgoing interface) and the egress RBridge's nickname. For a multicast packet, each attached L1 area is handled one at a time: either RB1 is not the DBRB and won't transition the packet, or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows these rules:

  • If this packet originated from an area outside the connected areas, RB1 replicates this packet and floods it on the proper Level 1 trees of all the areas in which it acts as the DBRB.
  • If the packet originated from one of the connected areas, RB1 replicates the packet it receives from the Level 1 tree and floods it on the other proper Level 1 trees of all the areas in which it acts as the DBRB, except the originating area (i.e., the area connected to the incoming interface). RB1 might also receive a replication of the packet from the Level 2 tree. That replication MUST be dropped by RB1. It can spot these packets because their ingress nickname is the nickname of one of the border RBridges of an L1 area for which the receiving border RBridge is DBRB. 🙅‍♀️

7. E-L1FS/E-L2FS Backwards Compatibility 🎀

All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780], no exceptions bestie 💅. The Extended TLVs defined in Section 5 are meant to be used in Extended Level 1/2 Flooding Scope (E-L1FS/E-L2FS) Protocol Data Units (PDUs) 📦. Area border RBridges MUST support both E-L1FS and E-L2FS. RBridges that don't support both E-L1FS or E-L2FS cannot serve as area border RBridges, but they can still show up in an L1 area as non-area-border RBridges 🦋.

8. Manageability Considerations 🧚

Here's the tea ☕. If an L1 Border RBridge Nickname is configured at an RBridge, and that RBridge has both L1 and L2 adjacencies, then the multilevel feature from this document is turned on for that RBridge. It normally uses an L2 nickname in both L1 and L2. As explained below, though, such an RBridge may have to fall back to multilevel unique nickname behavior [RFC8397], in which case it uses this L1 nickname instead 🔄. On the flip side, unique nickname multilevel as specified in [RFC8397] is enabled just by having L1 and L2 adjacencies, with no L1 Border RBridge Nickname configured. RBridges that only support unique nickname multilevel do not support configuring an L2 Border RBridge Nickname. RBridges that only support the single-level TRILL base protocol specified in [RFC6325] do not support L2 adjacencies at all 🙈.

RBridges that support, and are configured to use, single nickname multilevel as specified in this document MUST support unique nickname multilevel [RFC8397]. If there are multiple border RBridges between an L1 area and L2, and one or more of them only support or are only configured for unique nickname multilevel [RFC8397], then any of those border RBridges that are configured to use single nickname multilevel MUST fall back to behaving as a unique nickname border RBridge for that L1 area 😬. Overlapping sets of RBridges can be the border RBridges for different L1 areas, so an RBridge supporting single nickname MUST be able to simultaneously support single nickname for some of its L1 areas and unique nickname for others 🧩. For example, RB1 and RB2 might be border RBridges for L1 area A1 using single nickname, while RB2 and RB3 are border RBridges for area A2. If RB3 only supports unique nicknames, then RB2 must fall back to unique nickname for area A2 but continue to support single nickname for area A1. Operators SHOULD be notified when this fallback occurs 📣. The presence of border RBridges using unique nickname multilevel can be detected, because they advertise in L1 the blocks of nicknames available within that L1 area.

In both the unique nickname approach specified in [RFC8397] and the single nickname aggregated approach specified in this document, an RBridge that has L1 and L2 adjacencies uses the same nickname in L1 and L2. If an RBridge is configured with an L1 Border RBridge Nickname for any a Level 1 area, it uses this nickname across the Level 2 area. That L1 Border RBridge Nickname cannot be used in any other Level 1 area, except other Level 1 areas for which the same RBridge is a border RBridge with this L1 Border RBridge Nickname configured 🍓.

On top of the manageability considerations above, the manageability specifications in [RFC6325] still apply ✨.

Border RBridges replace the ingress and/or egress nickname when a TRILL Data packet traverses a TRILL L2 area 🔁. A TRILL Operations, Administration, and Maintenance (OAM) message will be forwarded through the multilevel single nickname TRILL campus using a MAC address belonging to the destination RBridge [RFC7455] 💜.

9. Security Considerations 🔐

For general TRILL Security Considerations, see [RFC6325]. Please go read that one too, it matters 🫶.

The newly defined TRILL APPsub-TLVs in Section 5 are carried in IS-IS PDUs whose authenticity can be enforced using the regular IS-IS security mechanisms [IS-IS] [RFC5310]. Malicious devices may also fake the APPsub-TLVs to attract TRILL Data packets 🦹, interfere with multilevel TRILL operation, induce excessive state in TRILL switches (or in any bridges that may be part of the TRILL campus), and so on. This is why RBridges SHOULD be configured to use the IS-IS Authentication TLV (10) in their IS-IS PDUs. That way IS-IS security [RFC5310] can authenticate those PDUs and discard them if they're forged 🚨.

Using a variation of aggregated nicknames, and the resulting possible duplication of nicknames between areas, increases the possibility of a TRILL Data packet being delivered to the wrong egress RBridge if areas are unexpectedly merged 😱. Compare this with a scheme where all nicknames in the TRILL campus are unique (except as a transient condition), such as the scheme in [RFC8397]. However, in many cases the data would be discarded at that egress RBridge anyway, because it wouldn't match a known end station Data Label / MAC address 🛡️.

10. IANA Considerations 📋

IANA has allocated two new types under the TRILL GENINFO TLV [RFC7357], taken from the range allocated by Standards Action [RFC8126], for the TRILL APPsub-TLVs defined in Section 5 🎉. The following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on the TRILL Parameters IANA web page.

             +======+====================+===========+
             | Type | Name               | Reference |
             +======+====================+===========+
             | 256  | L1-BORDER-RBRIDGE  | RFC 9183  |
             +------+--------------------+-----------+
             | 257  | L1-BORDER-RB-GROUP | RFC 9183  |
             +------+--------------------+-----------+

Table 1

11. References 📚

11.1. Normative References

11.2. Informative References

  • [IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 8473, ISO/IEC 10589:2002, Second Edition, November 2002.
  • [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
  • [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and H. Zhai, "Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 10.17487/RFC8243, September 2017, <https://www.rfc-editor.org/info/rfc8243>.

Appendix A. Level Transition Clarification ✨

okay so this one is about a sneaky edge case 👀. An L1 RBridge can be reachable only through a border RBridge that isn't a DBRB 🥺. If that non-DBRB border RBridge just... doesn't do a Level transition, how does a multicast packet even get to the L1 RBridge? 🤔

The answer is kinda iconic 💅. The DBRB does the Level transition first, then floods the packet down an L1 distribution tree, and that flood is what reaches the RBridge. Literally the DBRB carries it the whole way 🫶.

Check out the figure below. RB77 can only be reached through the border RBridge RB30, and RB3 is the DBRB 🦋. RB3 moves the multicast packet into L1 and floods it along the distribution tree rooted at RB3. The packet ends up at RB77 by going through RB30 🌸.

                   Area{3,30}
                 +--------------+          (root) RB3 o
                 |              |                      \
            -RB3 |              |                       o RB30
              |  |              |                      /
            -RB30-RB77          |                RB77 o
                 +--------------+

                 Example Topology               L1 Tree

ngl the path in this example is not the most efficient one 😭. A possible fix is to configure RB3 so that it doesn't belong to this area 🧚. That way RB30 becomes the DBRB and does the Level transition itself 💖.

Authors' Addresses 🎀

Mingui Zhang 💜

Independent
Beijing
China

Email: zhangmingui@qq.com

Donald E. Eastlake, 3rd 🌈

Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America

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

Radia Perlman 👑

EMC
2010 256th Avenue NE, #200
Bellevue, WA 98007
United States of America

Email: radia@alum.mit.edu

Margaret Cullen 🔥

Painless Security
356 Abbott Street
North Andover, MA 01845
United States of America

Phone: +1-781-405-7464
Email: margaret@painless-security.com
URI:   https://www.painless-security.com

Hongjun Zhai 🦋

Jinling Institute of Technology
99 Hongjing Avenue, Jiangning District
Nanjing
Jiangsu, 211169
China

Email: honjun.zhai@tom.com

that's the whole RFC, bestie 🌈💖 the authors did amazing work and you made it to the end 🫶✨

📦 where this page comes from