RFC 7781
Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
🎀 Part 1 of 7 🎀
RFC 7781: Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access ✨
Okay bestie, let's start with the basics 🫶. This is RFC 7781, a Standards Track document from the IETF that came out in February 2016. Its authors are H. Zhai (JIT), T. Senevirathne (Consultant), R. Perlman (EMC), and M. Zhang and Y. Li (Huawei Technologies). It's published under ISSN 2070-1721. It doesn't obsolete or update any other RFC, since none are listed in the header. Main character energy 👑
Abstract
Okay so the IETF TRILL (Transparent Interconnection of Lots of Links) protocol gives you flow-level multipathing for both unicast and multi-destination traffic, in networks with arbitrary topology, no cap 💅. Active-active access at the TRILL edge takes those same perks and extends them to end stations that are multiply connected to a TRILL campus, as RFC 7379 discusses 🦋. In this doc, the group of edge RBridges (Routing Bridges, aka TRILL switches) that gives active-active access to one of these end stations is treated as a single virtual RBridge. Using the virtual RBridge and its pseudo-nickname, this document specifies how TRILL active-active access works for those end stations ✨
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7781 🔗
Copyright Notice
Copyright (c) 2016 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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License 💜
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................6
2. Overview ........................................................7
3. Virtual RBridge and Its Pseudo-Nickname .........................9
4. Auto-Discovery of Member RBridges ..............................10
4.1. Discovering Member RBridge for an RBv .....................11
4.2. Selection of Pseudo-Nickname for an RBv ...................13
5. Distribution Trees and Designated Forwarder ....................14
5.1. Different Trees for Different Member RBridges .............15
5.2. Designated Forwarder for Member RBridges ..................16
5.3. Ingress Nickname Filtering ................................18
6. TRILL Traffic Processing .......................................19
6.1. Ingressing Native Frames ..................................19
6.2. Egressing TRILL Data Packets ..............................20
6.2.1. Unicast TRILL Data Packets .........................20
6.2.2. Multi-Destination TRILL Data Packets ...............21
7. MAC Information Synchronization in Edge Group ..................22
8. Member Link Failure in an RBv ..................................23
8.1. Link Protection for Unicast Frame Egressing ...............24
9. TLV Extensions for Edge RBridge Group ..........................24
9.1. PN-LAALP-Membership APPsub-TLV ............................24
9.2. PN-RBv APPsub-TLV .........................................26
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs ......................27
9.4. LAALP IDs .................................................29
10. OAM Packets ...................................................29
11. Configuration Consistency .....................................29
12. Security Considerations .......................................30
13. IANA Considerations ...........................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................33
Acknowledgments ...................................................34
Contributors ......................................................34
Authors' Addresses ................................................351. Introduction ✨
The IETF TRILL protocol [RFC6325] gives you optimal pair-wise data frame forwarding with no configuration needed, safe forwarding even during temporary loops, and support for multipathing of both unicast and multicast traffic 💖. It does this with IS-IS [IS-IS] [RFC7176] link-state routing, and by encapsulating traffic in a header that includes a Hop Count. Devices that implement TRILL are called RBridges (Routing Bridges) or TRILL switches 🍓
In the base TRILL protocol, an end node can attach to the TRILL campus through a point-to-point link or a shared link, like a bridged LAN (Local Area Network) 🌈. There might be more than one edge RBridge on a shared link, but to avoid forwarding loops, only one edge RBridge is allowed to forward end-station traffic in each VLAN (Virtual LAN) on that link. That RBridge is called the Appointed Forwarder (AF) for that VLAN on the link [RFC6325] [RFC6439]. In real deployments, though, people want more bandwidth and reliability, so an end station might connect to several edge RBridges at once, and all of its uplinks are handled through a Local Active-Active Link Protocol (LAALP [RFC7379]), like Multi-Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [802.1AX] 🔥. In that setup, traffic has to be able to enter and leave the TRILL campus through any of the RBridges for a given VLAN. Together, these RBridges form an Active-Active Edge (AAE) RBridge group 🫶
With an LAALP, traffic with the same VLAN and source Media Access Control (MAC) address but belonging to different flows will often get sent to different member RBridges of the AAE group, and then enter the TRILL campus 🦋. When an egress RBridge gets TRILL Data packets that came in through different RBridges, it keeps learning different correspondences between a {Data Label and MAC address} and a nickname, as it decapsulates the packets, if it has data-plane address learning enabled. This is known as "MAC address flip-flopping" 🙈. It makes most TRILL switches behave badly, and it sends the returning traffic to the destination over different paths, which causes persistent reordering of frames 💀. On top of that, other problems, like duplicate egressing and loopback of multi-destination frames, can also mess with an end station that's multiply connected to the member RBridges of an AAE group [RFC7379] 😭
This document deals with the AAE issues in TRILL by describing how the members of an edge RBridge group can be represented by a virtual RBridge (RBv) and given a pseudo-nickname 👑. A member RBridge of such a group uses that pseudo-nickname, instead of its own nickname, as the ingress RBridge nickname when it brings in frames received on attached LAALP links 🧚. Other methods are possible too. For example, the specification in this document and the specification in [RFC7782] could be deployed at the same time for different AAE groups in the same campus. If the method in [RFC7782] is used, edge TRILL switches need to support the capability indicated by the Capability Flags APPsub-TLV, as specified in Section 4.2 of [RFC7782]. If the method in this document is adopted, all TRILL switches need to support the Affinity sub-TLV defined in [RFC7176] and [RFC7783] 💅. For a TRILL campus that deploys both of these AAE methods, TRILL switches are required to support both methods. Still, it's nicer to only adopt one method in a TRILL campus, since that keeps the operating expense, the complexity of troubleshooting, and so on, lower ✨
The main body of this document is organized like this 📚:
- Section 2 gives an overview of the TRILL active-active access issues, and the reason a virtual RBridge (RBv) is used to resolve them.
- Section 3 describes the concept of a virtual RBridge (RBv) and its pseudo-nickname.
- Section 4 describes how edge RBridges can support an RBv automatically and get a pseudo-nickname for it.
- Section 5 discusses how to protect multi-destination traffic from disruption caused by Reverse Forwarding Path (RPF) check failure, duplication, forwarding loops, and so on.
- Section 6 covers the special processing of native frames and TRILL Data packets at member RBridges of an RBv (also called an Active-Active Edge (AAE) RBridge group).
- Section 7 describes the MAC information synchronization among the member RBridges of an RBv.
- Section 8 discusses protection against downlink failure at a member RBridge.
- Section 9 lists the necessary TRILL code points and data structures for a pseudo-nickname AAE RBridge group 🦋
1.1. Terminology and Acronyms ✨
okay so this doc borrows a bunch of acronyms and terms from [RFC6325] and [RFC7379], and then adds a few of its own 💅 here's the whole squad:
- AAE: Active-active Edge RBridge group. A group of edge RBridges to which at least one Customer Equipment (CE) node is multiply attached with an LAALP. AAE is also referred to as "edge group" or "virtual RBridge" in this document. 🦋
- Campus: A TRILL network made up of TRILL switches, links, and possibly bridges, bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus" 🎓🙅♀️
- CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment. 🖥️
- Data Label: VLAN or Fine-Grained Label (FGL).
- DF: Designated Forwarder.
- DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges. 🌸
- E-L1FS: Extended Level 1 Flooding Scope [RFC7356].
- ESADI: End-Station Address Distribution Information.
- FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label [RFC7172].
- LAALP: Local Active-Active Link Protocol [RFC7379], e.g., MC-LAG or DRNI. 🔗
- MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of Link Aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
- OE-flag: A flag used by a member RBridge of a given LAALP to tell other edge RBridges of this LAALP whether this LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as the given LAALP does. When this flag for an LAALP is 1, it means that the LAALP needs to be served by an RBv by itself and is not willing to share, that is, it should Occupy an RBv Exclusively (OE). 🙅♀️✨
- RBv: Virtual RBridge. An alias for "active-active edge RBridge group" in this document.
- vDRB: The Designated RBridge in an RBv. It is responsible for deciding the pseudo-nickname for the RBv. 👑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 📖
2. Overview 🌈
okay so the whole point is to minimize impact during failures and maximize available access bandwidth 🚀 which is why Customer Equipment (referred to as "CE" in this document) may be multiply connected to the TRILL campus via multiple edge RBridges. it's giving redundancy, bestie 💖
Figure 1 shows such a typical deployment scenario, where CE1 attaches to RB1, RB2, ... RBk and treats all of the uplinks as an LAALP bundle. RB1, RB2, ... RBk then constitute an AAE RBridge group for CE1 in this LAALP. Even if a member RBridge or an uplink fails, CE1 will still get frame forwarding service from the TRILL campus if there are still member RBridges and uplinks available in the AAE group. Furthermore, CE1 can make flow-based load balancing across the available member links of the LAALP bundle in the AAE group when it communicates with other CEs across the TRILL campus [RFC7379]. main character energy fr 🎀
----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
+-----+ | +--------+
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1-->(| | |) (| | |) <--LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
+-------+ +-------+Figure 1: Active-Active Connection to TRILL Edge RBridges
By design, an LAALP (say LAALP1) does not forward packets received on one member port to other member ports. As a result, the TRILL Hello messages sent by one member RBridge (say RB1) via a port to CE1 will not be forwarded to other member RBridges by CE1. That is to say, member RBridges will not see each other's Hellos via the LAALP. So, every member RBridge of LAALP1 thinks of itself as Appointed Forwarder for all VLANs enabled on an LAALP1 link and can ingress/egress frames simultaneously in these VLANs [RFC6439]. 🙈
The simultaneous flow-based ingressing/egressing can cause some problems. For example, simultaneous egressing of multi-destination traffic by multiple member RBridges will result in frame duplication at CE1 (see Section 3.1 of [RFC7379]). Simultaneous ingressing of frames originated by CE1 for different flows in the same VLAN with the same source MAC address will result in MAC address flip-flopping at remote egress RBridges that have data-plane address learning enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in turn cause packet reordering in reverse traffic. 💀 the drama is real
Edge RBridges learn correspondences between a {Data Label and MAC address} and nickname by default when decapsulating TRILL Data packets (see Section 4.8.1 of [RFC6325], as updated by [RFC7172]). Assuming that the default data-plane learning is enabled at edge RBridges, MAC address flip-flopping can be solved by using a virtual RBridge together with its pseudo-nickname. This document specifies a way to do so. 🧚
3. Virtual RBridge and Its Pseudo-Nickname 🦋
A virtual RBridge (RBv) represents a group of edge RBridges to which at least one CE is multiply attached using an LAALP. More precisely, it represents a group of ports on the edge RBridges providing end-station service and the service provided to the CE(s) on these ports, through which the CE(s) is multiply attached to the TRILL campus using LAALP(s). Such end-station service ports are called RBv ports; in contrast, other access ports at edge RBridges are called regular access ports in this document. RBv ports are always LAALP connecting ports, but not vice versa (see Section 4.1). For an edge RBridge, if one or more of its end-station service ports are ports of an RBv, that RBridge is a member RBridge of that RBv. ✨
For the convenience of description, a virtual RBridge is also referred to as an Active-Active Edge (AAE) group in this document. In the TRILL campus, an RBv is identified by its pseudo-nickname, which is different from any RBridge's regular nickname(s). An RBv has one and only one pseudo-nickname. Each member RBridge (say RB1, RB2 ..., RBk) of an RBv (say RBvn) advertises RBvn's pseudo-nickname using a Nickname sub-TLV in its TRILL IS-IS LSP (Link State PDU) [RFC7176] and SHOULD do so with maximum priority of use (0xFF), along with their regular nickname(s). (Maximum priority is recommended to avoid the disruption to an AAE group that would occur if the nickname were taken away by a higher-priority RBridge.) Then, from these LSPs, other RBridges outside the AAE group know that RBvn is reachable through RB1 to RBk. 📣
A member RBridge (say RBi) loses its membership in RBvn when its last port in RBvn becomes unavailable due to failure, reconfiguration, etc. RBi then removes RBvn's pseudo-nickname from its LSP and distributes the updated LSP as usual. From those updated LSPs, other RBridges know that there is no path to RBvn through RBi now. 😭
When member RBridges receive native frames on their RBv ports and decide to ingress the frames into the TRILL campus, they use that RBv's pseudo-nickname instead of their own regular nicknames as the ingress nickname to encapsulate them into TRILL Data packets. So, when these packets arrive at an egress RBridge, even if they are originated by the same end station in the same VLAN but ingressed by different member RBridges, no address flip-flopping is observed on the egress RBridge when decapsulating these packets. (When a member RBridge of an AAE group ingresses a frame from a non-RBv port, it still uses its own regular nickname as the ingress nickname.) iconic behavior, honestly 👑
Since an RBv is not a physical node and no TRILL frames are forwarded between its ports via an LAALP, pseudonode LSP(s) MUST NOT be created for an RBv. An RBv cannot act as a root when constructing distribution trees for multi-destination traffic, and its pseudo-nickname is ignored when determining the distribution tree root for the TRILL campus [RFC7783]. So, the tree root priority of the RBv's nickname MUST be set to 0, and this nickname MUST NOT be listed in the "s" nicknames (see Section 4.5 of [RFC6325]) by the RBridge holding the highest-priority tree root nickname. 🚫 no pseudonode LSPs for you, RBv 💅
NOTE: In order to reduce the consumption of nicknames, especially in a large TRILL campus with lots of RBridges and/or active-active accesses, when multiple CEs attach to exactly the same set of edge RBridges via LAALPs, those edge RBridges should be considered a single RBv with a single pseudo-nickname. 🍓 nickname budget stays healthy, bestie
4. Auto-Discovery of Member RBridges 🔥
Edge RBridges connected to a CE via an LAALP can automatically discover each other with minimal configuration through the exchange of LAALP connection information. no manual matchmaking required 💕
From the perspective of edge RBridges, a CE that connects to edge RBridges via an LAALP can be identified by the ID of the LAALP that is unique across the TRILL campus (for example, the MC-LAG or DRNI System ID [802.1AX]), which is referred to as an LAALP ID in this document. On each such edge RBridge, the access port to such a CE is associated with an LAALP ID for the CE. An LAALP is considered valid on an edge RBridge only if the RBridge still has an operational downlink to that LAALP. For such an edge RBridge, it advertises a list of LAALP IDs for its valid local LAALPs to other edge RBridges via its E-L1FS FS-LSP(s) [RFC7356] [RFC7780]. Based on the LAALP IDs advertised by other RBridges, each RBridge can know which edge RBridges could constitute an AAE group (see Section 4.1 for more details). One RBridge is then elected from the group to allocate an available nickname (the pseudo-nickname) for the group (see Section 4.2 for more details). 🫶
4.1. Discovering Member RBridge for an RBv 🎀
okay so bestie, picture Figure 2 🧚. CE1 and CE2 multiply attach to RB1, RB2, and RB3 via LAALP1 and LAALP2, respectively, and CE3 and CE4 attach to RB3 and RB4 via LAALP3 and LAALP4, respectively. Let's say LAALP3 is configured to occupy a virtual RBridge all by itself 💜.
------------------------
/ \
| TRILL Campus |
\ /
-------------------------
| | | |
+-------+ | | +----------+
| | | |
+-------+ +-------+ +-------+ +-------+
| RB1 | | RB2 | | RB3 | | RB4 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | |
| +--------|--+ | +-------|-+ | +-------|---+ |
| +----------+ | | | | | | | |
| | +-----------|-|-|-------+ | +-------+ | |
| | | | | | | | | |
LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |)
+-------+ +-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 | | CE4 |
+-------+ +-------+ +-------+ +-------+
Figure 2: Different LAALPs to TRILL CampusRB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership APPsub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS FS-LSPs, respectively. RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}, and RB4 announces {LAALP3, LAALP4}, respectively. ✨
An edge RBridge is called an "LAALP related RBridge" if it has at least one LAALP configured on an access port 🌸. When it receives the PN-LAALP-Membership APPsub-TLVs, RBn ignores them if it is not an LAALP related RBridge. Otherwise, RBn SHOULD use the LAALP information contained in the sub-TLVs, along with its own PN-LAALP-Membership APPsub-TLVs, to decide which RBv(s) it should join and which edge RBridges constitute each such RBv. Based on the information received, each of the four RBridges knows the following:
LAALP ID OE-flag Set of edge RBridges
--------- -------- ---------------------
LAALP1 0 {RB1, RB2, RB3}
LAALP2 0 {RB1, RB2, RB3}
LAALP3 1 {RB3, RB4}
LAALP4 0 {RB3, RB4}The OE-flag tells you whether a given LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as it does 🦋.
For an LAALP (for example, LAALP3), if its OE-flag is one, it means that LAALP3 does not want to share. So it MUST Occupy an RBv Exclusively (OE) 🔥. Support of OE is optional. RBridges that do not support OE ignore the OE-flag and act as if it were zero (see Section 11 ("Configuration Consistency")).
Otherwise, the LAALP (for example, LAALP1) will share an RBv with other LAALPs if possible 🫶. By default, this flag is set to zero. For an LAALP, this flag is considered 1 if any edge RBridge advertises it as (value) 1 (see Section 9.1).
In the table above, some LAALPs might attach to a single RBridge because of misconfiguration or link failure, and so on. Those LAALPs are considered to be invalid entries 💀. Each of the LAALP related edge RBridges then runs the following algorithm to decide which valid LAALPs can be served by an RBv:
- Step 1: Take all the valid LAALPs that have their OE-flags set to 1 out of the table, and create an RBv for each such LAALP.
- Step 2: Sort the valid LAALPs left in the table in descending order based on the number of RBridges in their associated set of multihomed RBridges. If several LAALPs have the same number of RBridges, order those LAALPs in ascending order in the proper places of the table, based on their LAALP IDs considered to be unsigned integers. (For example, in the table above, both LAALP1 and LAALP2 have three member RBridges. Assuming the LAALP1 ID is smaller than the LAALP2 ID, LAALP1 is followed by LAALP2 in the ordered table.)
- Step 3: Take the first valid LAALP (say LAALP_i) with the maximum set of RBridges, say S_i, out of the table, and create a new RBv (say RBv_i) for it.
- Step 4: Walk through the remaining valid LAALPs in the table one by one. Pick up all the valid LAALPs whose sets of multihomed RBridges contain exactly the same RBridges as LAALP_i, and take them out of the table. Then appoint RBv_i as the servicing RBv for those LAALPs.
- Step 5: Repeat Steps 3 and 4 for any LAALPs left, until all the valid entries in the table are associated with an RBv.
After doing all of that, all four RBridges know that LAALP3 is served by an RBv, say RBv1, which has RB3 and RB4 as member RBridges 🌈. LAALP1 and LAALP2 are served by another RBv, say RBv2, which has RB1, RB2, and RB3 as member RBridges. LAALP4 is served by RBv3, which has RB3 and RB4 as member RBridges. Here's the lineup:
RBv Serving LAALPs Member RBridges
----- ------------------- ---------------
RBv1 {LAALP3} {RB3, RB4}
RBv2 {LAALP1, LAALP2} {RB1, RB2, RB3}
RBv3 {LAALP4} {RB3, RB4}In each RBv, one of the member RBridges gets elected as the vDRB (in this document, called the Designated RBridge of the RBv) 👑. That RBridge then picks an available nickname as the pseudo-nickname for the RBv and announces it to all the other member RBridges of the RBv via its TRILL E-L1FS FS-LSPs (refer to Section 9.2 for the relative extended sub-TLVs) ✨.
4.2. Selection of Pseudo-Nickname for an RBv 💅
As described in Section 3, in the TRILL campus, an RBv is identified by its pseudo-nickname 🦋. In an AAE group, one member RBridge is elected for the job of selecting a pseudo-nickname for this RBv, and this RBridge will be the vDRB. The winner in the group is the RBridge with the largest IS-IS System ID considered to be an unsigned integer 👑. Then, based on its TRILL IS-IS link-state database and the potential pseudo-nickname(s) reported in the PN-LAALP-Membership APPsub-TLVs by the other member RBridges of this RBv (see Section 9.1 for more details), the vDRB selects an available nickname as the pseudo-nickname for this RBv and advertises it to the other RBridges via its E-L1FS FS-LSP(s) (see Section 9.2 and [RFC7780]). Except as provided below, the selection of a nickname to use as the pseudo-nickname follows the usual TRILL rules given in [RFC6325], as updated by [RFC7780].
To reduce the traffic disruption caused by nickname changes, the vDRB SHOULD attempt, if possible, to reuse the pseudo-nickname the group recently used when it selects a nickname for the RBv 🔁. To help the vDRB do this, each LAALP related RBridge advertises a reusing pseudo-nickname for each of its LAALPs in its PN-LAALP-Membership APPsub-TLV if it has recently used such a pseudo-nickname for that LAALP. It's up to the vDRB's implementation how it treats the reusing pseudo-nicknames, but the following are RECOMMENDED:
- If there are multiple available reusing pseudo-nicknames reported by all the member RBridges of some LAALPs in this RBv, the available one reported by the largest number of such LAALPs is chosen as the pseudo-nickname for this RBv. If there's a tie, the reusing pseudo-nickname with the smallest value considered to be an unsigned integer is chosen.
- If only one reusing pseudo-nickname is reported, it SHOULD be chosen if it is available.
If no available reusing pseudo-nickname is reported, the vDRB selects a nickname by its usual method.
The vDRB then announces the selected pseudo-nickname to the other member RBridges of this RBv in the PN-RBv APPsub-TLV (see Section 9.2) 📣.
5. Distribution Trees and Designated Forwarder 🌸
In an AAE group, each member RBridge thinks it is the Appointed Forwarder for VLAN x. Without changes made for active-active connection support, they would all ingress frames into, and egress frames from, the TRILL campus for all VLANs 😭. For multi-destination frames, more than one member RBridge ingressing them may cause some of the resulting TRILL Data packets to be discarded due to failure of the Reverse Path Forwarding (RPF) check on other RBridges. For multi-destination traffic, more than one RBridge egressing it may cause local CE(s) to receive duplicate frames. Furthermore, in an AAE group, a multi-destination frame sent by a CE (say CEi) may be ingressed into the TRILL campus by one member RBridge, and another member RBridge will then receive it from the TRILL campus and egress it to CEi. This results in loopback of the frame for CEi 🙈. These problems are all described in [RFC7379].
In the following subsections, the first two issues are discussed in Sections 5.1 and 5.2, respectively. The third issue is discussed in Section 5.3.
5.1. Different Trees for Different Member RBridges 🌳
In TRILL, RBridges normally use distribution trees to forward multi-destination frames. (Under some circumstances, they can be unicast, as specified in [RFC7172].) An RPF check, along with other types of checks, is used to avoid temporary multicast loops during topology changes (Section 4.5.2 of [RFC6325]). The RPF check mechanism only accepts a multi-destination frame ingressed by an RBridge (say RBi) and forwarded on a distribution tree if it arrives at another RBridge (say RBn) on the expected port. If the frame arrives on any other port, the frame MUST be dropped 🚫.
To avoid address flip-flopping on remote RBridges, member RBridges use the RBv's pseudo-nickname instead of their regular nicknames as the ingress nickname to ingress native frames, including multi-destination frames. From the view of other RBridges, these frames appear as if they were ingressed by the RBv. When multi-destination frames of different flows are ingressed by different member RBridges of an RBv and forwarded along the same distribution tree, they may arrive at RBn on different ports. Some of them will violate the RPF check principle at RBn and be dropped, which results in lost traffic 😤.
In an RBv, if a different member RBridge uses different distribution trees to ingress multi-destination frames, the RPF check violation issue can be fixed 🩷. The Coordinated Multicast Trees (CMT) document [RFC7783] proposes such an approach. It makes use of the Affinity sub-TLV defined in [RFC7176] to tell other RBridges which trees a member RBridge (say RBi) may choose when ingressing multi-destination frames. All RBridges in the TRILL campus can then calculate RPF check information for RBi on those trees, taking the tree affinity information into account [RFC7783].
This document uses the approach proposed in [RFC7783] to fix the RPF check violation issue. Please refer to [RFC7783] for more details regarding this approach 🧡.
5.2. Designated Forwarder for Member RBridges ✨
Okay bestie, let's use Figure 3 as our example 💅 CE1 and CE2 are served by an RBv that has RB1 and RB2 as member RBridges. In VLAN x, all three CEs can talk to each other 🫶
---------------------
/ \ +-----+
| TRILL Campus |---| RBn |
\ / +-----+
-----------------------
| |
+----+ +------+
| |
+---------+ +--------+
| RB1 | | RB2 |
| oooooooo|oooooooooooooooo|ooooo |
+o--------+ RBv +-----o--+
o|oooo|oooooooooooooooooooo|o|o |
| +--|--------------------+ | |
| | +---------+ +----------+ |
(| |)<-LAALP1 (| |)<-LAALP2 |
+-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 |
+-------+ +-------+ +-------+Figure 3: A Topology with Multihomed and Single-Homed CEs
So here's the drama 😭 When a remote RBridge (say RBn) sends a multi-destination TRILL Data packet in VLAN x (or the FGL that VLAN x maps to, if the packet is FGL), both RB1 and RB2 receive it. Each of them thinks it's the Appointed Forwarder for VLAN x, and without changes made for active-active connection support, they'd BOTH forward the frame to CE1/CE2. Result? CE1/CE2 get duplicate copies through this RBv. Not iconic 💀
It gets messier if CE3 is single-homed to RB2. When CE3 sends a native multi-destination frame onto link CE3-RB2 in VLAN x, the frame gets replicated locally to the ports to CE1/CE2, and it also gets encapsulated into a TRILL Data packet and ingressed into the TRILL campus. When that packet arrives at RB1 across the TRILL campus, RB1 egresses it to CE1/CE2. Now CE1/CE2 get duplicates from RB1 and RB2 🙈
Enter the Designated Forwarder (DF) 👑 This document introduces the DF for a VLAN to stop those duplicate copies. The basic idea is to elect one RBridge per VLAN from an RBv to egress multi-destination TRILL Data traffic, and to replicate locally received multi-destination native frames to the CEs served by the RBv.
Note that the DF only matters for egressing and replicating multi-destination traffic. It has zero effect on ingressing, forwarding, or egressing unicast frames 🦋 Also, the DF check only happens on RBv ports, not on regular access ports.
Every RBridge in an RBv elects a DF using the same algorithm. That's the magic part ✨ It guarantees that, per VLAN, every member of the RBv picks the same RBridge as the DF.
Here's the math, don't panic 🤓 Say there are m LAALPs and k member RBridges in an RBv. Then (1) each LAALP is called "LAALPi", where 0 <= i < m, and (2) each RBridge is called "RBj", where 0 <= j < k. The DF election algorithm per VLAN goes like this:
- Step 1: For LAALPi, sort all the RBridges in numerically ascending order based on
SHA-256(System IDj | LAALP IDi)considered to be an unsigned integer, where SHA-256 is the hash function specified in [RFC6234], "System IDj" is the 6-byte IS-IS System ID of RBj, "|" means concatenation, and "LAALP IDi" is the LAALP ID for LAALPi. The System ID and LAALP ID are considered to be byte strings. In the case of a tie, the tied RBridges are sorted in numerically ascending order by their System IDs considered to be unsigned integers. - Step 2: Each RBridge in the numerically sorted list is assigned a monotonically increasing number j, such that increasing number j corresponds to its position in the sorted list. That means the first RBridge (the one with the smallest
SHA-256(System ID | LAALP ID)) is assigned zero, and the last is assigned k-1. - Step 3: For each VLAN ID n, choose the RBridge whose number equals
(n mod k)as the DF. - Step 4: Repeat Steps 1-3 for the remaining LAALPs until there is a DF per VLAN per LAALP in the RBv. 🎀
For any multi-destination native frames of VLAN x that get received, if RBi is an LAALP attached RBridge, there are three cases where RBi replicates the multi-destination frame:
- Local replication of the frame to regular (non-AAE) access ports as per [RFC6325] (and [RFC7172] for FGL).
- RBv ports associated with the same pseudo-nickname as that of the incoming port, no matter whether RBi is the DF for the frame's VLAN on the outgoing ports, except that the frame MUST NOT be replicated back to the incoming port. RBi can't just rely on the DF to forward the multi-destination frame back into the AAEs associated with the pseudo-nickname, because that would make the source CE get its own frame back, which breaks basic Ethernet properties 😱 The DF won't forward such a frame back into the AAE thanks to ingress nickname filtering, described in Section 5.3.
- RBv ports on which RBi is the DF for the frame's VLAN, while they're associated with different pseudo-nickname(s) than that of the incoming port.
For any multi-destination TRILL Data packets that get received, RBi MUST NOT egress them out of the RBv ports where it is not the DF for the frame's Inner.VLAN (or for the VLAN corresponding to the Inner.Label if the packet is an FGL one). Otherwise, whether or not to egress it out of such ports is further subject to the filtering check result of the frame's ingress nickname on these ports (see Section 5.3). Main character rules, honestly 👑
5.3. Ingress Nickname Filtering
As shown in Figure 3, CE1 may send multi-destination traffic in VLAN x to the TRILL campus via a member RBridge (say RB1). RB1 TRILL-encapsulates the traffic, and it's delivered through the TRILL campus to multi-destination receivers. Here's the problem 💀 RB2 may receive that traffic and egress it right back to CE1 if it's the DF for VLAN x on the port to LAALP1. The traffic then loops back to CE1 (see Section 3.2 of [RFC7379]). Not it 🙅♀️
To fix this, this document requires an ingress nickname filtering check 🧚 The idea is to check the ingress nickname of a multi-destination TRILL Data packet before egressing a copy of it out of an RBv port. If the ingress nickname matches the pseudo-nickname of the RBv (associated with the port), the filtering check should fail, and the copy MUST NOT be egressed out of that RBv port. Otherwise, the copy is egressed out of that port if it has also passed other checks, such as the Appointed Forwarder check described in Section 4.6.2.5 of [RFC6325] and the DF check described in Section 5.2.
Note that this ingress nickname filtering check has no effect on multi-destination native frames received on access ports and replicated to other local ports (including RBv ports), since there's no ingress nickname associated with those frames 🌸 Also, regular access ports on the RBridge don't have a pseudo-nickname associated with them, so no ingress nickname filtering check is needed on those ports.
More details of data packet processing on RBv ports are coming up in the next section 💖
6. TRILL Traffic Processing
This section gives you more details on native frame and TRILL Data packet processing as it relates to the RBv's pseudo-nickname 🍓
6.1. Ingressing Native Frames
When RB1 receives a unicast native frame from one of its ports that has end-station service enabled, it processes the frame as described in Section 4.6.1.1 of [RFC6325], with this one exception:
- If the port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
When RB1 receives a native multi-destination (broadcast, unknown unicast, or multicast) frame from one of its access ports (including regular access ports and RBv ports), it processes the frame as described in Section 4.6.1.2 of [RFC6325], with these exceptions:
- If the incoming port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
- For the copies of the frame replicated locally to RBv ports, there are two cases:
- If the outgoing port(s) is associated with the same pseudo-nickname as that of the incoming port but not with the same LAALP as the incoming port, the copies are forwarded out of that outgoing port(s) after passing the Appointed Forwarder check for the frame's VLAN. That is to say, the copies are processed on such port(s), as discussed in Section 4.6.1.2 of [RFC6325].
- Else, the Designated Forwarder (DF) check is also made on the outgoing ports for the frame's VLAN after the Appointed Forwarder check, and the copies are not output through any ports that failed the DF check (i.e., RB1 is not the DF for the frame's VLAN on those ports). Otherwise, the copies are forwarded out of the outgoing ports that pass both the Appointed Forwarder check and the DF check (see Section 5.2). 🦋
For any such frames received, the MAC address information learned by observing them, together with the LAALP ID of the incoming port, SHOULD be shared with other member RBridges in the group (see Section 7). Share the tea, bestie 🫖✨
6.2. Egressing TRILL Data Packets
This section describes egress processing of the TRILL Data packets received on an RBv member RBridge (say RBn). Section 6.2.1 describes the egress processing of unicast TRILL Data packets, and Section 6.2.2 specifies the egressing of multi-destination TRILL Data packets. Next up, we get into the nitty-gritty 💜
6.2.1. Unicast TRILL Data Packets 💌
Okay so when RBn gets a unicast TRILL Data packet, the first thing it does is check the egress nickname in the TRILL Header 👀. If that nickname is one of RBn's regular nicknames, the packet gets handled exactly as Section 4.6.2.4 of [RFC6325] says 💅.
If the egress nickname is the pseudo-nickname of a local RBv, RBn is on learning duty 🧠. It learns the source MAC address, unless data-plane learning has been disabled. The learned {Inner.MacSA, Data Label, ingress nickname} triplet SHOULD be shared within the AAE group as described in Section 7 🫶.
Then the packet gets decapsulated back to its native form ✨. RBn looks up the Inner.MacDA and Data Label in its local forwarding tables, and one of three cases happens. RBn uses the first case that applies and ignores the rest, which is very main character of it 👑.
- If the destination end station identified by the
Inner.MacDAandData Labelis on a local link, the native frame is sent onto that link with the VLAN from theInner.VLANor the VLAN corresponding to theInner.Labelif the packet is FGL 🎀. - Else if RBn can reach the destination through another member RBridge (say RBk), it tunnels the native frame to RBk 🚇. It does this by re-encapsulating the frame into a unicast TRILL Data packet and sending it to RBk. RBn uses RBk's regular nickname instead of the pseudo-nickname as the egress nickname for the re-encapsulation, and the ingress nickname stays unchanged (somewhat similar to Section 2.4.2.1 of [RFC7780]) 🦋. If the Hop Count value of the packet is too small for it to reach RBk safely, RBn SHOULD increase that value properly when doing the re-encapsulation 🌸.
(NOTE: When receiving that re-encapsulated TRILL Data packet, as the egress nickname of the packet is RBk's regular nickname rather than the pseudo-nickname of a local RBv, RBk will process it per Section 4.6.2.4 of [RFC6325] and will not re-forward it to another RBridge.) 🙈
- Else, RBn does not know how to reach the destination 🥺. It sends the native frame out of all the local ports on which it is Appointed Forwarder for the
Inner.VLAN(or Appointed Forwarder for the VLAN into which theInner.Labelmaps on that port for an FGL TRILL Data packet [RFC7172]).
6.2.2. Multi-Destination TRILL Data Packets 🌈
When RB1 receives a multi-destination TRILL Data Packet, it checks and processes the packet as described in Section 4.6.2.5 of [RFC6325], with one exception 🧚:
- On each RBv port where RBn is the Appointed Forwarder for the packet's
Inner.VLAN(or for the VLAN to which the packet'sInner.Labelmaps on that port if it is an FGL TRILL Data packet), the DF check (see Section 5.2) and the ingress nickname filtering check (see Section 5.3) are also performed. For such an RBv port, if either the DF check or the filtering check fails, the frame MUST NOT be egressed out of that port 🚫. Otherwise, it can be egressed out of that port 💖.
7. MAC Information Synchronization in Edge Group 🔄
Let's talk about RB1 in LAALP1 🍓. An edge RBridge, say RB1 in LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host (say h1) when h1 sends a packet to CE1. The returning traffic from CE1 may go to another member RBridge of LAALP1 (for example, RB2). RB2 may not have that correspondence stored, so it has to do the flooding for unknown unicast 😩. That flooding is unnecessary, since the returning traffic is almost always expected and RB1 had already learned the address correspondence. To avoid the unnecessary flooding, RB1 SHOULD share the correspondence with other RBridges of LAALP1 💜. RB1 synchronizes the correspondence by using the MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs [RFC7357].
Now flip it around 🔁. RB2 has learned the MAC address and Data Label of CE1 when CE1 sends a frame to h1 through RB2. The returning traffic from h1 may go to RB1. RB1 may not have CE1's MAC address and Data Label stored, even though it is in the same LAALP for CE1 as RB2. So it has to flood the traffic out of all its access ports where it is Appointed Forwarder for the VLAN (see Section 6.2.1), or the VLAN the FGL maps to on that port if the packet is FGL 😭. That flooding is unnecessary, since the returning traffic is almost always expected and RB2 had learned CE1's MAC and Data Label information. To avoid that unnecessary flooding, RB2 SHOULD share the MAC address and Data Label with other RBridges of LAALP1 ✨. RB2 synchronizes the MAC address and Data Label by enclosing the relative MAC-RI TLV within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see Section 9.3) in its ESADI-LSP [RFC7357].
After receiving the enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 related RBridges) treat the MAC address and Data Label as if they had learned them locally on their member port of LAALP1 🥰. The LAALP1 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and treat the MAC address and Data Label as specified in [RFC7357] 🙃. Furthermore, so the LAALP1 unrelated RBridges know that the MAC and Data Label are reachable through the RBv that provides service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV SHOULD carry the pseudo-nickname of the RBv 🛰️. It should not carry a zero value or one of the originating RBridge's (i.e., RB2's) regular nicknames. Hmm, I need to keep it exact: it SHOULD carry the pseudo-nickname of the RBv, rather than a zero value or one of the originating RBridge's (i.e., RB2's) regular nicknames.
8. Member Link Failure in an RBv 💔
As shown in Figure 4, suppose that the link RB1-CE1 fails 🙀. Although a new RBv will be formed by RB2 and RB3 to provide active-active service for LAALP1 (see Section 5), the unicast traffic to CE1 might still be forwarded to RB1 before the remote RBridge learns that CE1 is attached to the new RBv. That traffic might be disrupted by the link failure. Section 8.1 discusses failure protection in this scenario 🛡️.
However, multi-destination TRILL Data packets can reach all member RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3 💫. That is, the new DF for the traffic's Inner.VLAN or the VLAN the packet's Inner.Label maps to in the new RBv does the job. Although there might be a transient hang time between failure and the establishment of the new RBv, special actions to protect against downlink failure for such multi-destination packets are not needed 🙌.
------------------
/ \
| TRILL Campus |
\ /
--------------------
| | |
+---+ | +----+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
ooooooo|ooooo|oooooo|ooo|ooooo |
o+------+ RBv +------+ +-----o+
o|oooo|ooooooo|oooo|ooooo|oo|o
| | | +-|-----+ |
\|/+--|-------+ | +------+ |
- B | +----------|------+ | |
/|\| +-----------+ | | |
(| | |)<--LAALP1 (| | |)<--LAALP2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+B - Failed Link or Link Bundle
Figure 4: A Multi-Homed CE with a Failed Link 📸
8.1. Link Protection for Unicast Frame Egressing 🧯
When the link CE1-RB1 fails, RB1 loses its direct connection to CE1 😱. The MAC entry through the failed link to CE1 is removed from RB1's local forwarding table immediately. Another MAC entry, learned from another member RBridge of LAALP1 (for example, RB2, since it is still a member RBridge of LAALP1), is installed into RB1's forwarding table (see Section 9.3) 🔧. In that new entry, RB2 (identified by one of its regular nicknames) is the egress RBridge for CE1's MAC address. Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be tunneled to RB2 after being re-encapsulated (the ingress nickname remains unchanged and the egress nickname is replaced by RB2's regular nickname), based on the above installed MAC entry (see bullet 2 in Section 6.2.1) 🚀. RB2 then receives the frame and egresses it to CE1 🎉.
After failure recovery, RB1 learns that it can reach CE1 via link CE1-RB1 again 🥹. It learns this by observing CE1's native frames, or from the MAC information synchronization by member RBridge(s) of LAALP1 as described in Section 7. It then restores the MAC entry to its previous one and downloads it to its data-plane "fast path" logic ⚡.
9. TLV Extensions for Edge RBridge Group 🎀
Here's where the new TLVs come in 💅. The following subsections specify the APPsub-TLVs needed to support pseudo-nickname edge groups 🧩.
9.1. PN-LAALP-Membership APPsub-TLV ✨
okay so this APPsub-TLV is how an edge RBridge announces its associated pseudo-nickname LAALP info 📣 It's a sub-TLV of the TRILL GENINFO TLV [RFC7357], and it gets distributed in E-L1FS FS-LSPs [RFC7780]. Here's the layout 💖
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-LAALP-Membership | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Figure 5: PN-LAALP-Membership Advertisement APPsub-TLVand each LAALP RECORD is shaped like this 🧚
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
+--+-+-+-+-+-+-+-+
|OE| RESV | (1 byte)
+--+-+-+-+-+-+-+-+
| Size | (1 byte)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reusing Pseudo-Nickname | (2 bytes)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID | (variable)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+here's what each field does:
PN-LAALP-Membership(2 bytes): this is the type of the sub-TLV, which is2🎀Length(2 bytes): the sum of the lengths of the LAALP RECORDs 📏OE(1 bit): a flag saying whether the LAALP wants to occupy an RBv by itself.1means occupying by itself (or Occupying Exclusively (OE)) 🦋 By default it's set to0on transmit. This bit is used for edge RBridge group auto-discovery (see Section 4.1). For any one LAALP, the values of this flag might conflict in the LSPs advertised by different member RBridges of that LAALP. When that happens, the flag for that LAALP is considered to be1. 😭RESV(7 bits): MUST be transmitted as zero and ignored on receipt. 🙈Size(1 byte): the size of the remaining part of the LAALP RECORD, which is 2 plus the length of the LAALP ID 💅Reusing Pseudo-Nickname(2 bytes): the suggested pseudo-nickname of the AAE group serving the LAALP. If the LAALP isn't served by any AAE group, this field MUST be set to zero. The originating RBridge uses it to help the vDRB reuse the previous pseudo-nickname of an AAE group (see Section 4.2) ✨LAALP ID(variable): the ID of the LAALP. See Section 9.4. 🌸
When one of these shows up, if RBn isn't an LAALP related edge RBridge, it just ignores the sub-TLV. Otherwise it parses the sub-TLV. When new LAALPs appear or old ones get withdrawn compared to its old copy, and they're also configured on RBn, RBn runs the "Member RBridges Auto-Discovery" procedure described in Section 4. 👑
9.2. PN-RBv APPsub-TLV 🌈
The PN-RBv APPsub-TLV is how a Designated RBridge of a virtual RBridge (vDRB) dictates the pseudo-nickname for the LAALPs served by the RBv 🦋 It's also a sub-TLV of the TRILL GENINFO TLV [RFC7357], distributed in E-L1FS FS-LSPs [RFC7780]. The shape is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-RBv | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBv's Pseudo-Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+the fields, bestie:
PN-RBv(2 bytes): the type of this sub-TLV, which is3🍓Length(2 bytes):3+n*kbytes, where there are n LAALP IDs, each of size k bytes. k is found in theLAALP ID Sizefield below. If Length is not 3 plus an integer times k, the sub-TLV is corrupt and MUST be ignored. 💀RBv's Pseudo-Nickname(2 bytes): the appointed pseudo-nickname for the RBv that serves the LAALPs listed in the following fields 🫶LAALP ID Size(1 byte): the size of each of the following LAALP IDs in this sub-TLV. It's 8 if the LAALPs listed are MC-LAGs or DRNI (Section 6.3.2 of [802.1AX]). The value in this field is the k value that appears in the formula for Length above. 🔥LAALP ID(LAALP ID Size bytes): the ID of the LAALP. See Section 9.4. 🌷
This sub-TLV can show up multiple times with the same RBv pseudo-nickname, which means all the LAALPs listed are identified by that pseudo-nickname. For example, if there are LAALP IDs of different lengths, then the LAALP IDs of each size have to be listed in a separate sub-TLV. 🧁
Since a PN-RBv APPsub-TLV gets distributed as part of the application link state via the E-L1FS FS-LSP [RFC7780], creating it, changing its contents, or withdrawing it is done by the Designated RBridge updating and flooding an E-L1FS PDU. 📬
On receipt, if RBn isn't an LAALP related edge RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member RBridge of the RBv identified by the list of LAALPs, it associates the pseudo-nickname with the ports of these LAALPs and downloads that association to the data-plane fast path logic. At the same time, RBn claims the RBv's pseudo-nickname across the campus and announces the RBv as its child on the corresponding tree or trees using the Affinity sub-TLV [RFC7176] [RFC7783]. 💜
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs 🎀
Two APPsub-TLVs act as boundary APPsub-TLVs in this document. They let an edge RBridge wrap up the MAC-RI TLV(s) with the MAC address info it learned from the local port of an LAALP, for when it wants to share that info with other edge RBridges. Both are defined as TRILL APPsub-TLVs [RFC7357]. First up is PN-MAC-RI-LAALP-INFO-START 🚪
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
| LAALP ID | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+PN-MAC-RI-LAALP-INFO-START(2 bytes): the type of this sub-TLV, which is4🍓Length(2 bytes): the size of the following LAALP ID. It's 8 if the LAALP listed is an MC-LAG or DRNI. 📏LAALP ID(variable): the ID of the LAALP (see Section 9.4). 🌸
And here's the PN-MAC-RI-LAALP-INFO-END one 🏁
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PN-MAC-RI-LAALP-INFO-END(2 bytes): the type of this sub-TLV, which is5🦋Length(2 bytes):0✨
This pair of APPsub-TLVs can be carried multiple times in an ESADI-LSP and across multiple ESADI-LSPs. When an LAALP related edge RBridge (say RBn) wants to share the MAC addresses it learned on its local ports of different LAALPs with other edge RBridges, it uses one or more pairs of these APPsub-TLVs for each LAALP in its ESADI-LSPs. Each pair encloses the MAC-RI TLVs containing the MAC addresses learned from one specific LAALP. Also, if the LAALP is served by a local RBv, the value of the Topology-ID/Nickname field in the relevant MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv, rather than one of RBn's regular nicknames or a zero value. That way, when a remote RBridge gets such a MAC-RI TLV, it knows the contained MAC addresses are reachable through the RBv. 🌈
On receipt, if the edge RBridge isn't an LAALP related one or can't recognize these sub-TLVs, it ignores them and keeps parsing the enclosed MAC-RI TLVs per [RFC7357]. Otherwise, the recipient parses the boundary APPsub-TLVs. The PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur within one TRILL GENINFO TLV. If an END shows up without any previous START in the ESADI-LSP, the END APPsub-TLV is ignored. After a START is encountered, if the end of the ESADI-LSP is reached without an END, then the end of the ESADI-LSP is treated as if it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs and the TLVs between them get handled like this 👑
- If the edge RBridge is configured with the contained LAALP and the LAALP is also enabled locally, it treats all the MAC addresses contained in the following MC-RI TLVs enclosed by the corresponding pair of boundary APPsub-TLVs as if they were learned from its local port of that LAALP;
- Else, it ignores these boundary APPsub-TLVs and keeps parsing the following MAC-RI TLVs per [RFC7357] until another pair of boundary APPsub-TLVs is encountered.
9.4. LAALP IDs 🧚
The LAALP ID identifies an AAE RBridge group in the TRILL campus, so it MUST be unique across the campus 🔒 In all of the APPsub-TLVs specified above, the length of the LAALP ID can be figured out from a size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or DRNI identifier as specified in Section 6.3.2 of [802.1AX]. The meaning and structure of LAALP IDs of other lengths are reserved and may be specified in future documents. 🌸
10. OAM Packets 🫶
Attention must be paid when generating Operations, Administration, and Maintenance (OAM) packets, bestie 🫣 So here's the deal: a pseudo-nickname can't be used as the ingress nickname in TRILL OAM messages, unless it's the response to an OAM message that has that RBv's pseudo-nickname as the egress nickname. That way the response messages can actually make it back to the originating member RBridge of an RBv 🔁 For example, say RB1 is a member RBridge of RBvi. RB1 can't use RBvi's pseudo-nickname as the ingress nickname when it originates OAM messages, otherwise the responses could get delivered to a different member RBridge of RBvi instead of RB1 😱 But when RB1 responds to an OAM message with RBvi's pseudo-nickname as the egress nickname, it can use that pseudo-nickname as the ingress nickname in the response message. ✨
Here's the bit that makes it all okay 💅 RBridges can't use OAM messages for learning MAC addresses (Section 3.2.1 of [RFC7174]), so there's no MAC address flip-flopping at a remote RBridge. That's true even though RB1 uses its regular nicknames as ingress nicknames in its TRILL OAM messages while also using RBvi's pseudo-nickname in its TRILL Data packets. Iconic, honestly 🌈
11. Configuration Consistency ✨
okay bestie, listen 👀 the VLAN membership of all the RBridge ports in an LAALP MUST be the same 🫶 if the VLANs don't match, you can get packet loss or paths that aren't the shortest ones 💀
Take Figure 1 as our example 🦋 say RB1 sets up VLAN1 and VLAN2 on the CE1-RB1 link, but RB2 only has VLAN1 on the CE1-RB2 link. Both RB1 and RB2 use the same ingress nickname RBv for every frame coming from CE1. So a remote RBridge (let's call her RBx) learns that CE1's MAC address in VLAN2 is coming from RBv 🙈 then on the return path, RBx might send VLAN2 traffic to RB2. But RB2 doesn't have VLAN2 on the CE1-RB2 link, so the frame could get dropped, or it has to get redirected to RB1, if RB2 knows that RB1 can reach CE1 in VLAN2. chaotic, I know 😭
How LAALP implementations keep the VLAN config consistent on the TRILL switch LAALP ports is out of scope for the TRILL protocol 💅 BUT given how messy inconsistencies can get, TRILL switches MUST disable the ports connected to an LAALP with an inconsistent VLAN configuration 🚫
It's also super important that if any VLAN in an LAALP is being mapped by edge RBridges to an FGL [RFC7172], the mapping MUST be the same for all edge RBridge ports in the LAALP 🧚 otherwise, for example, unicast FGL TRILL Data packets from remote RBridges could get mapped into different VLANs, depending on which edge RBridge receives and egresses them. no thanks 🙅
Last one! It's important that RBridges in an AAE group not be configured to assert the OE-flag if any RBridge in the group doesn't implement it 🌈 as [RFC7379] says, the RBridges in an AAE edge group are expected to be from the same vendor (LAALPs are proprietary, so that's just how it goes), so this will normally sort itself out when all the RBridges either support OE or don't. ✨
12. Security Considerations 🔐
okay this one is serious, so put your listening ears on 👂 authenticity for contents carried in IS-IS PDUs is enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310].
For security considerations about extensions carried by TRILL ESADI, go check the Security Considerations section in [RFC7357] 📖
Here's the spicy part 🌶️ since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, active-active edge groups is proprietary too. If authentication isn't used, a rogue RBridge that insinuates itself into an active-active edge group can disrupt end-station traffic flowing into or out of that group 😱 for example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group. For multi-destination traffic flowing into that group, it could control all the traffic in any VLAN it was the DF for, and it can exercise substantial control over the DF election just by changing its own System ID 💀
For general TRILL security considerations, see [RFC6325] 🔒
13. IANA Considerations 📋
IANA has allocated four code points from the range below 255 for the four TRILL APPsub-TLVs specified in Section 9 💖 and added them to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry, like this:
Type Name Reference
---- -------------------------- ---------
2 PN-LAALP-Membership RFC 7781
3 PN-RBv RFC 7781
4 PN-MAC-RI-LAALP-INFO-START RFC 7781
5 PN-MAC-RI-LAALP-INFO-END RFC 778114. References 📚
14.1. Normative References
these are the ones you really need to read 📖
- [802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [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, <http://www.rfc-editor.org/info/rfc5310>.
- [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
- [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
- [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
- [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
- [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
- [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
- [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
- [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
- [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
- [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <http://www.rfc-editor.org/info/rfc7783>.
14.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/IEC 10589:2002, Second Edition, November 2002.
- [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
- [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
- [RFC7782] Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments", RFC 7782, DOI 10.17487/RFC7782, February 2016, <http://www.rfc-editor.org/info/rfc7782>.
Acknowledgments 🫶
huge thanks to Mingjiang Chen for his contributions to this document 💜 and a big shoutout to Erik Nordmark, Les Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan Pathangi, Jon Hudson, and Fangwei Hu for their good questions and comments 🌸
Contributors 🌷
Weiguo Hao
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States
Phone: +1-508-333-2270
Email: d3e3e3@gmail.comAuthors' Addresses 🦋
Hongjun Zhai
Jinling Institute of Technology
99 Hongjing Avenue, Jiangning District
Nanjing, Jiangsu 211169
China
Email: honjun.zhai@tom.com
Tissa Senevirathne
Consultant
Email: tsenevir@gmail.com
Radia Perlman
EMC
2010 256th Avenue NE, #200
Bellevue, WA 98007
United States
Email: Radia@alum.mit.edu
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd., Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56625409
Email: liyizhou@huawei.com📦 where this page comes from
- ietf: rfc7781 2016-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms