RFC 8361
Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
RFC 8361 ✨ Centralized Replication for TRILL Active-Active BUM Traffic 🎀
Okay bestie, let's talk about this one 💅 It's RFC 8361, titled "Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic" 🦋 It was written by W. Hao, Y. Li (both from Huawei Technologies), M. Durrani (Equinix), S. Gupta (IP Infusion), and A. Qu (MediaTec) 🫶 It's a Standards Track document, dated April 2018, and it updates RFC 6325 🌈 It doesn't obsolete anything. It's published by the IETF, with ISSN 2070-1721 💜
Here's the vibe: this spec fixes a sneaky RPF check failure that happens in TRILL active-active setups when you use the pseudo-nickname trick from RFC 7781 😭
Abstract
Okay, so TRILL active-active access has this one problem 💀 When you use the pseudo-nickname mechanism from RFC 7781, a Reverse Path Forwarding (RPF) check can fail. Not cute 🙈
The fix? Centralized replication 🔥 Every ingress RBridge sends its BUM traffic (that's Broadcast, Unknown Unicast, and Multicast, obviously 💅) to one centralized node using unicast TRILL encapsulation. That node decapsulates everything and forwards it to the destination RBridges along a distribution tree built by the TRILL base protocol (RFC 6325) ✨
To keep the RPF check from blowing up on the RBridge sitting between the ingress and the centralized node, the RPF calculation has to change 🦋 Specifically, RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of using the actual ingress RBridge 👑 This document updates RFC 6325 🎀
Status of This Memo
This is an Internet Standards Track document 🌸
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🧚
For the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8361 💖
Copyright Notice
Copyright (c) 2018 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 were on the publication date. Please read these carefully, because they spell out your rights and restrictions. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 🔥
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Centralized Replication Solution Overview .......................4
4. Frame Duplication from Remote RBridge ...........................6
5. Local Forwarding Behavior on Ingress RBridge ....................6
6. Loop Prevention among RBridges in an Edge Group .................8
7. Centralized Replication Forwarding Process ......................9
8. BUM Traffic Load-Balancing among Multiple Centralized Nodes ....10
9. Coexisting with the CMT Solution (RFC 7783) ....................11
10. Network Upgrade Analysis ......................................12
11. TRILL Protocol Extensions .....................................13
11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV ........13
12. Security Considerations .......................................14
13. IANA Considerations ...........................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................171. Introduction 🌸
Okay so, the IETF TRILL protocol [RFC6325] gives you multipath data forwarding that's loop free and per-hop based, with minimal configuration 💅 It uses IS-IS [RFC6165] [RFC7176] as its control plane routing protocol and defines a TRILL-specific header for user data ✨
Customer Equipment (CE) devices can be multihomed to a set of edge RBridges that form an edge group, which is where active-active service comes in 🦋 In that setup, all the uplinks from a CE are handled through a Local Active-Active Link Protocol (LAALP) [RFC7379], like Multi-Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [IEEE802.1AX] 🫶 An active-active flow-based load-sharing mechanism can give you better load balancing and high reliability 👑 A CE can be a Layer 3 (L3) end system by itself, or a bridge switch that L3 end systems use to get into the TRILL campus 🧚
In active-active access, the pseudo-nickname solution in [RFC7781] can stop Media Access Control (MAC) flip-flop on remote RBridges 💖 The big idea is to use a virtual RBridge (RBv) with one pseudo-nickname to represent the whole edge group 🌈 Any member RBridge of that group uses this pseudo-nickname, instead of its own nickname, as the ingress nickname when it injects TRILL data frames into the campus ✨ Using the nickname fixes the address flip-flop, because a remote RBridge learns the pseudo-nickname as the nickname 🎀
BUT (and this is the tea 🍓) it creates a new problem: incorrect packet dropping 😭 When an edge RBridge uses a pseudo-nickname as the ingress nickname to forward BUM traffic, any RBridges (RBn) between the ingress RBridge and the distribution tree root will treat the traffic as if it came in from the RBv 💀 If different edge RBridges of the same RBv use the same distribution tree, the traffic can reach some RBn through different ports 🙈 Then the RPF check required by TRILL [RFC6325] fails, and RBn drops BUM traffic that shows up on unexpected ports 💔
This document specifies a centralized replication solution for BUM traffic forwarding that fixes the incorrect drops caused by RPF check failure in the virtual RBridge case 🔥 The basic idea: all ingress RBridges send BUM traffic to a centralized node, which MUST be a distribution tree root, using unicast TRILL encapsulation 🫶 When the centralized node gets the packets, it decapsulates them and forwards them to their destination RBridges over a distribution tree built per the TRILL base protocol ✨ This document updates [RFC6325]. Per [RFC6325], multi-destination traffic is ingressed into a multi-destination TRILL data packet. But per this document, when centralized replication is in use, multi-destination traffic is first ingressed into a unicast TRILL data packet 💅
2. Conventions Used in This Document 🎀
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 💖
Terms and abbreviations from [RFC6325] are used here too, plus these extras 🦋
- BUM: Broadcast, Unknown unicast, and Multicast
- CE: Customer Equipment (as in [RFC7783]), meaning a device (end station or bridge). It can be physical or virtual equipment 🌸
- Data Label: VLAN or Fine-Grained Labeled (FGL) [RFC7172]
- DF: Designated Forwarder [RFC7781]
- FGL: Fine-Grained Label [RFC7172]
- LAALP: Local Active-Active Link Protocol [RFC7379]
- MAC flip flop: A problem where the attachment point of a MAC address keeps looking like it's changing to a remote switch. See Section 3.3 of [RFC7379] 🙈
- MC-LAG: Multi-Chassis Link Aggregation
- RPF: Reverse Path Forwarding 🧚
Part 1 of 4 is done, bestie 💜 Part 2 picks up with Section 3, the Centralized Replication Solution Overview, so stay tuned 🫶✨
3. Centralized Replication Solution Overview ✨
okay bestie, here's the big idea 💖 When an edge RBridge gets BUM traffic 🌸 from a CE device, it doesn't use multicast encapsulation. It uses unicast TRILL encapsulation to send the packets to a centralized node 🦋 That centralized node MUST be a distribution tree root. Distribution tree roots are normally picked to be high-capacity core RBridges with lots of high-bandwidth adjacencies 👑 This constraint is what makes it practical (more on that below) to support centralized replication with only software changes to transit RBridges 💅
The TRILL header of the unicast TRILL encapsulation has an ingress RBridge nickname field and an egress RBridge nickname field [RFC6325]. If the ingress RBridge gets the BUM packet from a port in an active-active edge group using [RFC7781], it sets the ingress RBridge nickname to the pseudo-nickname instead of its own nickname. That's to avoid MAC flip-flop (see Section 3.3 of [RFC7379]) on remote RBridges 🙈 The egress RBridge nickname is set to a special nickname of the centralized node, which tells the centralized replication unicast TRILL encapsulation apart from a normal one. This special nickname is called an R-nickname 🎀
When the centralized RBridge receives a unicast TRILL-encapsulated packet with its R-nickname as the egress nickname, it decapsulates the packet. Then it replicates and forwards the BUM packet to the packet's destination RBridges using one of the distribution trees set up per the TRILL base protocol [RFC6325]. It MUST use a distribution tree whose tree root is the centralized RBridge itself. (An RBridge may be the root of more than one tree.) When the centralized RBridge forwards the BUM traffic, it sends it on the distribution tree as if it were a locally ingressed frame. The one difference is that the ingress nickname stays the same as in the packet it received, so that MAC address learning by all egress RBridges is bound to the pseudo-nickname 🧚
As each RBridge forwards the replicated packet along the distribution tree starting from the centralized node, an RPF check is performed per [RFC6325]. For any RBridge between the ingress RBridge and the centralized replication node, the incoming port of such a BUM packet should be the centralized-node-facing port, since multicast traffic always comes from the centralized node in this solution. However, the RPF port from the distribution tree calculation in [RFC6325] will be the real ingress RBridge-facing port. That's because it uses the edge group's virtual RBridge as the ingress RBridge, so the RPF check will fail 😭
To fix this, the RPF test needs a tweak. The RPF calculation on each RBridge should use the centralized node as the ingress RBridge for each tree where that node is the root, instead of the real ingress virtual RBridge. As a result, the RPF check will accept traffic on the centralized-node-facing port of the RBridge for multi-destination traffic. This stops incorrect frame drops by the RPF check ✨
Changing the actual RPF check on a received multi-destination TRILL data packet is honestly easy. The RPF check from [RFC6325] asks whether a triple of {ingress nickname, tree, receiving RBridge port} is allowed. (The tree is identified by the nickname of its root, which is stored in the TRILL Header egress nickname field.) When doing the RPF check, if ingress nickname is using centralized replication (indicated by a C-nickname, see Section 9), then the check is based on distribution from the tree root. If ingress nickname is not using centralized replication, the check is based on distribution from the RBridge that has that ingress nickname.
To tell centralized replication unicast TRILL encapsulation apart from normal unicast, the R-nickname is introduced for centralized replication. When the centralized node receives unicast TRILL encapsulation traffic with the egress nickname R-nickname, it decapsulates the packet and forwards it to the destination RBridges through a distribution tree for which it is the root, re-encapsulating as mentioned above. In TRILL, RBridges can hold multiple nicknames, so the centralized RBridge just obtains another nickname to use as its R-nickname 💜 The centralized RBridge or RBridges should announce their R-nickname to all TRILL campuses through the TRILL Link State PDU (LSP) extension specified in Section 11.
4. Frame Duplication from Remote RBridge
Frame duplication can happen when a remote host sends a multi-destination frame to a local CE that has an active-active connection to the TRILL campus 😬 To stop the local CE from getting multiple copies from a remote RBridge, the Designated Forwarder (DF) mechanism is supported for egress-direction multicast traffic 🫶
The DF election mechanism [RFC7781] lets only one port of one RBridge in an active-active group forward multicast traffic from the TRILL campus to the local access side for each VLAN. The basic idea is to elect one RBridge per VLAN from an edge group to be responsible for egressing the BUM traffic. [RFC7781] describes the DF election mechanism among the member RBridges involved in an edge group.
If the DF election mechanism is used for frame-duplication prevention, access ports on an RBridge are categorized as one of three types: non-group, group DF port, and group non-DF port. The last two types can be called group ports. Each group port is associated with a pseudo-nickname. If consistent nickname allocation to edge group RBridges is used, it's possible for the same pseudo-nickname to be associated with more than one port on a single RBridge 🌈 A typical scenario is that CE1 is connected to RB1 and RB2 by LAALP1, whereas CE2 is connected to RB1 and RB2 by LAALP2. To conserve the number of pseudo-nicknames used, member ports for both LAALP1 and LAALP2 on RB1 and RB2 are all associated with the same pseudo-nickname 🍓
5. Local Forwarding Behavior on Ingress RBridge
When an ingress RBridge (RB1) gets BUM traffic from a local active-active connected CE (CE1) device, the traffic is injected into the TRILL campus with TRILL encapsulation. It's replicated and forwarded to all destination RBridges through centralized replication, including the ingress RBridge itself, along a TRILL distribution tree. To keep the traffic from looping back to the original sender CE, an ingress nickname of the CE group's pseudo-nickname is used for traffic filtering 🔥
However, if there are two CEs, say CE1 and CE2, connecting to the ingress RB1 and each associated with the same pseudo-nickname, RB1 needs to locally replicate and forward to CE2. That's because another copy of the BUM traffic between CE1 and CE2 through the TRILL campus will be blocked by the traffic filtering 💀
If CE1 and CE2 are not associated with the same pseudo-nickname, the copy of the BUM traffic between CE1 and CE2 through the TRILL campus won't be blocked by the traffic filtering. To avoid duplicated traffic on the receiver CE, there cannot be local replicated BUM traffic between these two CEs on ingress RB1 🙅♀️
In summary, to ensure correct BUM traffic forwarding behavior for each CE, the local replication behavior on the ingress RBridge is as follows:
- Replicate to the active-active group ports associated with the same pseudo-nickname as that associated with the incoming port.
- Do not replicate to active-active group ports associated with other pseudo-nicknames.
- Do not replicate to non-edge-group ports.
The above local forwarding behavior on the ingress RBridge of RB1 can be called "centralized replication local forwarding behavior A" 🌸
If ingress RBridge RB1 itself is the centralized replication node, BUM traffic injected by RB1 into the TRILL campus won't loop back to RB1. In this case, the local forwarding behavior is called centralized replication local forwarding behavior B. Behavior B on RB1 is as follows:
- Local replication to the ports associated with the same pseudo-nickname as that associated with the incoming port.
- Local replication to the group DF port associated with different pseudo-nicknames. Do not replicate to group non-DF ports associated with different pseudo-nicknames.
- Local replication to non-edge-group ports.
6. Loop Prevention among RBridges in an Edge Group
If a CE sends a BUM packet through a DF port to an ingress RBridge, that RBridge will forward the packet to all or a subset of the other RBridges that only have non-DF ports for that active-active group. Because BUM traffic forwarding to non-DF ports isn't allowed, in this case the frame won't loop back to the CE 🦋
If a CE sends a BUM packet through a non-DF port to an ingress RBridge, say RB1, then RB1 will forward that packet to other RBridges that have a DF port for that active-active group. In this case, the frame will loop back to the CE, and the traffic split-horizon filtering mechanism is used to avoid looping back among RBridges in the edge group 🔁
This split-horizon mechanism relies on the ingress nickname field in the TRILL header to check if a packet's egress port belongs to the same active-active group as the packet's incoming port to the TRILL campus 🧐
When the ingress RBridge receives BUM traffic from an active-active connected CE device, the traffic is sent through the TRILL campus with TRILL encapsulation to a centralized RBridge. There it's replicated and forwarded to its destination RBridges, which include the ingress RBridge itself, through a TRILL distribution tree. If the same pseudo-nickname is used for two active-active access CEs as the ingress nickname, an egress RBridge can use that nickname to filter traffic forwarding to all local CEs. In this case, the traffic between these two CEs goes through the local RBridge, and another copy of the traffic from the TRILL campus is filtered. If different ingress nicknames are used for two connecting CE devices, the access ports connecting to these two CEs should be isolated from each other. The BUM traffic between these two CEs should go through the TRILL campus; otherwise, the destination CE connected to the same RBridge as the sender CE will receive two copies of the traffic 👑
7. Centralized Replication Forwarding Process ✨
okay so here's the figure, bestie 🎀
+-----------+
| (RB5) |
+-----------+
|
+-----------+
| (RB4) |
+-----------+
| | |
-------- | --------
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RB3)|
+------+ +------+ +------+
* | * | * | ^
* | * | * | ^
* ----------*-------------*-- ^
***************************** | ^
* | ^
LAALP1 * LAALP2 | ^
+------+ +------+ +------+
| CE1 | | CE2 | | CE3 |
+------+ +------+ +------+
Figure 1: TRILL Active-Active AccessNote: the asterisk line, the hyphen and vertical bar line, and the circumflex line in this figure show how each CE connects to each RB. 🧚
Okay, so picture the example network from Figure 1. RB5 is the distribution tree root and the centralized replication node 👑. CE1 and CE2 are active-active accessed to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, and CE3 is single-homed to RB3 💅. The RBridges' own nicknames are nick1 through nick5 for RB1 through RB5. RB1, RB2, and RB3 all use the same pseudo-nickname for LAALP1 and LAALP2, and that pseudo-nickname is P-nick 💖. The R-nickname on the centralized replication node RB5 is S-nick ✨.
So here's how BUM traffic goes from CE1 to CE2 and CE3 🦋:
- CE1 sends BUM traffic to RB3.
- RB3 replicates the BUM traffic and sends it to CE2 locally. RB2 also sends the traffic to RB5 using unicast TRILL encapsulation. In the TRILL Header, the ingress nickname is set to
P-nickand the egress nickname is set toS-nick🌸. - RB5 decapsulates the unicast TRILL data packet. Then it uses a distribution tree that it is the root of to forward the packet as a multi-destination TRILL data packet. The egress nickname in the multi-destination TRILL Header is
nick5, and the ingress nickname is stillP-nick. If RB3 had sent the unicast to some nickname that was not an R-nickname, the packet would not be re-encapsulated. If it is sent to an R-nickname that is not a tree root, it either will not be forwarded at all or, if it is re-encapsulated and forwarded, will be subject to incorrect pruning and will not be delivered to all of its intended recipients 💀. - RB4 receives multicast TRILL traffic from RB5. The incoming traffic port is the up port facing the distribution tree root. RB4's RPF check will be correct based on the changed RPF port calculation algorithm in this document. After the RPF check is performed, it forwards the traffic to all other egress RBridges (RB1, RB2, and RB3) 🔥.
- RB3 receives multicast TRILL traffic from RB4 and decapsulates the multi-destination TRILL data packet. Because the ingress nickname
P-nickis equivalent to the nickname of the local LAALPs connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 and CE2, so there's no duplicated frame 🙈. RB3 only forwards the packet to CE3. - RB1 and RB2 receive multicast TRILL traffic from RB4. The process is similar to the one on RB3. Because the ingress nickname
P-nickis equivalent to the nickname of the local LAALPs connecting CE1 and CE2, they also don't forward the traffic to local CE1 and CE2 🫶.
8. BUM Traffic Load-Balancing among Multiple Centralized Nodes
Here's the glow-up 🌈: to support BUM traffic load-balancing with unicast TRILL encapsulation, you can deploy multiple centralized replication nodes and spread the traffic across them based on the data label (VLAN or FGL [RFC7172]) 🦋. And if one centralized node should get more of this BUM traffic, it can hold two or more R-nicknames. Its share of the BUM traffic is proportional to how many R-nicknames it holds 💜.
Say there are k different R-nicknames held by centralized nodes in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load-balancing algorithm used by an ingress active-active access RBridge goes like this 💅:
- All R-nicknames are ordered and numbered from 0 to k-1 in ascending order, treating the nicknames as unsigned 16-bit integers.
- For data label ID
m, choose the R-nickname whose index is given by (m mod k) as the egress nickname for BUM traffic unicast TRILL encapsulation.
For example, there are three R-Nicknames (RNs), ordered RN0 to RN2 🍓. Say there are five VLANs, from VLAN ID1 to ID5, spread among the edge RBridges. Then the traffic in VLAN1 goes to RN1, VLAN2 goes to RN2, and so on ✨.
When an ingress RBridge in an active-active connection gets BUM traffic from a local CE, it decides which R-nickname to send the traffic to using the VLAN-based load-spreading algorithm. So data-label-based load-balancing for BUM traffic can be achieved with multiple centralized nodes and multiple R-nicknames 👑.
9. Coexisting with the CMT Solution (RFC 7783)
Here's the picture of the two solutions hanging out together 🎀:
+------+ +------+
|(RB6) | |(RB7) |
+------+ +------+
------------------|-----------|----------------------
| | | | |
+------+ +------+ +------+ +------+ +------+
|(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) |
+------+ +------+ +------+ +------+ +------+
| | | | |
------------ -------------------------
| |
+------+ +------+
| CE1 | | CE2 |
+------+ +------+
Figure 2: CMT and Centralized Replication Coexisting ScenarioBoth the centralized replication solution and the Coordinated Multicast Trees (CMT) solution from [RFC7783] rely on pseudo-nicknames to avoid MAC flip-flop on remote RBridges 🦋. These two solutions can coexist in a single TRILL campus, and each active-active edge group of RBridges can pick its solution independently 🫶.
In Figure 2, RB1 and RB2 use CMT for CE1's active-active access, while RB3, RB4, and RB5 use centralized replication for CE2's active-active access 💅.
For the centralized replication solution, edge group RBridges MUST announce the local pseudo-nickname using the Nickname Flags APPsub-TLV with the C flag set. A nickname with the C flag set is called a "C-nickname" 🌈. A transit RBridge will perform the centralized replication-specific RPF check algorithm if it receives TRILL data packets with a C-nickname as the ingress nickname.
An edge group using CMT [RFC7783] MUST NOT set the C flag on the pseudo-nickname it is using. Honestly this is already mandatory behavior 🙈, because any RBridge originating a Nickname Flags APPsub-TLV is required by [RFC7780] to set any flag bit it doesn't know about to zero. > If an edge RBridge using CMT [RFC7783] sets the C-bit for an edge group pseudo-nickname anyway, it is very likely that BUM traffic encapsulated with that nickname as ingress would be incorrectly pruned early in its distribution. It would then reach few (possibly none) of its intended targets 😭.
To avoid confusion, a pseudo-nickname MUST NOT be shared between a centralized replication edge group and a CMT-based edge group 🔥.
10. Network Upgrade Analysis
Let's talk upgrades, bestie 🛠️. Centralized nodes will typically need software and hardware upgrades to support centralized replication, which stitches together the TRILL unicast traffic decapsulation process and the normal TRILL multicast forwarding process along the distribution tree 👑.
Active-active connection edge RBridges will typically need software and hardware upgrades to support unicast TRILL encapsulation for BUM traffic. The process is similar to other head-end replication processes 💜.
Transit nodes typically need only a software upgrade to support the changed RPF port calculation algorithm 🦋. Low effort, high reward, iconic ✨.
11. TRILL Protocol Extensions
Two new flags, "R" and "C", are specified in the Nickname Flags APPsub-TLV [RFC7780] 🎀. A nickname with the R flag set is called an "R-nickname", and a nickname with the C flag set is called a "C-nickname" 💖. The R-nickname is a specialized nickname attached to a centralized node, and it's how unicast TRILL-encapsulated BUM traffic gets told apart from normal unicast TRILL traffic 🧚. The C-nickname flag is set on the pseudo-nickname for each edge group that uses centralized replication. A C-nickname is a specialized pseudo-nickname for which transit RBridges perform a different RPF check algorithm for TRILL data packets with the C-nickname in the ingress nickname field 🌸.
When active-active edge RBridges use centralized replication to forward BUM traffic, the R-nickname is used as the egress nickname, and the C-nickname is used as the ingress nickname in the TRILL header for the unicast TRILL encapsulation of BUM traffic 🍓. The whole plan is giving teamwork ✨.
11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV ✨
okay bestie, so if an RBridge is advertising this APPsub-TLV but the nickname isn't even listed in its own Nickname Flags APPsub-TLV, the R and C flag bits MUST be treated as if they were zero 🙈. And if an RBridge that is not a distribution tree root advertises an R-nickname, that nickname MUST NOT be treated as an R-nickname. It's just an ordinary nickname now. The R-nickname flag gets ignored for all purposes when the nickname is held by a non-root RBridge 💅.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE|R | C| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD- R = If the R flag is one, it indicates that the advertising TRILL switch holding Nickname is a centralized replication node, and Nickname is used as egress nickname for edge group RBridges to inject BUM traffic into the TRILL campus when the edge group RBridges use this centralized replication solution for active-active access. If the R flag is zero, that nickname will not be used for that purpose.
- C = If C flag is one, it indicates that the TRILL traffic with this nickname as an ingress nickname requires the special RPF check algorithm specified in Section 3. If the C flag is zero, that nickname will not be used for that purpose.
Now, the tricky bit 🌀. Because of errors, or because LSPs are temporarily inconsistent while the link state database is converging after a config change or something similar, you can end up with Nickname Flags APPsub-TLVs that disagree about the same nickname. When that happens, it is RECOMMENDED that the nickname be treated as if the R / C flag were set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set. Basically, if anyone says yes, we're going with yes 🧚.
12. Security Considerations 🛡️
okay, serious moment, but make it cute 🎀. This document does not introduce any extra security risks. A rogue RBridge that is a tree root can attract traffic by advertising an R-nickname, so yes, that's a thing. Honestly though, it's not a huge jump in risk, because RBridges could already cause chaos in plenty of other ways, like advertising low-cost adjacencies or making themselves the highest priority tree root or whatever. The real protection against an untrusted device pretending to be an RBridge and wreaking havoc is to use IS-IS authentication [RFC5310] and to configure and administer the TRILL campus so that only trusted RBridges have the authentication key 🔐.
For general TRILL security considerations, see [RFC6325]. For security considerations related to pseudo-nickname active-active, see [RFC7781]. Go read those, they're giving important 📚.
13. IANA Considerations 🌸
IANA has assigned two bits in the Nickname Flags APPsub-TLV flags for the R and C bits discussed in Section 11.1, and updated the "NickFlags Bits" subregistry of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
Bit Mnemonic Description Reference
--- -------- -------------------- -----------
2 R Replication Nickname [RFC8361]
3 C Special RPF Check [RFC8361]14. References 📚
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://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, <https://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,
<https://www.rfc-editor.org/info/rfc6165>.
[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,
<https://www.rfc-editor.org/info/rfc6325>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7176>.
[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,
<https://www.rfc-editor.org/info/rfc7780>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.14.2. Informative References
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y.
Li, "Transparent Interconnection of Lots of Links (TRILL):
Pseudo-Nickname for Active-Active Access", RFC 7781,
DOI 10.17487/RFC7781, February 2016,
<https://www.rfc-editor.org/info/rfc7781>.
[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, <https://www.rfc-editor.org/info/rfc7379>.
[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,
<https://www.rfc-editor.org/info/rfc7783>.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE 802.1AX,
DOI 10.1109/IEEESTD.2017.7888436, March 2017,
<http://ieeexplore.ieee.org/document/7888436/>.Acknowledgments 🫶
The authors want to give a huge shoutout to Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia, and Francis Dupont for their important contributions. Thank you, legends 👑.
Authors' Addresses 💌
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Email: liyizhou@huawei.com
Muhammad Durrani
Equinix
Email: mdurrani@equinix.com
Sujay Gupta
IP Infusion
RMZ Centennial
Mahadevapura Post
Bangalore - 560048
India
Email: sujay.gupta@ipinfusion.com
Andrew Qu
MediaTec
Email: laodulaodu@gmail.comThat's the whole RFC, bestie! 🌈💖 Go be a TRILL expert, you've earned it 🦋✨
📦 where this page comes from
- ietf: rfc8361 2018-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms