RFC 7783

Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)

📅 published February 2016, from ietf

okay bestie, this is RFC 7783 💖 It's a Standards Track document from the IETF, dated February 2016, with ISSN 2070-1721. Three authors wrote it: T. Senevirathne (Consultant), J. Pathangi (Dell), and J. Hudson (Brocade). It updates RFC 6325 and doesn't obsolete anything. Keep that in your back pocket 🫶

Abstract ✨

okay so TRILL (Transparent Interconnection of Lots of Links) gets you loop-free connectivity to non-TRILL networks by picking an Appointed Forwarder for a set of VLANs. 🌸 Appointed Forwarders do VLAN-based load sharing with an active-standby model, but high-performance apps want active-active load sharing, which is lowkey the dream 😭

To get active-active, you represent a given non-TRILL network as a single virtual RBridge (also called a virtual Routing Bridge or virtual TRILL switch). The catch is that this virtual representation causes serious chaos in multi-destination RPF (Reverse Path Forwarding) check calculations 💀 This document specifies the required enhancements to build Coordinated Multicast Trees (CMT) inside the TRILL campus to fix those RPF issues. CMT only needs a software upgrade ✨ and gives RBridges flexibility to pick the path they want to associate with a given TRILL multi-destination distribution tree. It's giving main character energy 👑

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). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7783.

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, as 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 are provided without warranty as described in the Simplified BSD License.

1. Introduction 🌸

okay so TRILL (Transparent Interconnection of Lots of Links), as laid out in [RFC6325] and other related docs, gives you ways to use all the available paths for active forwarding, with minimum configuration 🧚 It uses IS-IS (Intermediate System to Intermediate System) [IS-IS] as its control plane, and its TRILL Header includes a Hop Count.

[RFC6325], [RFC7177], and [RFC6439] give you methods for interoperating between TRILL and Ethernet end stations and bridged networks. [RFC6439] is the active-standby solution, where only one of the RBridges (aka Routing Bridges or TRILL switches) on a link with end stations is in the active forwarding state for end-station traffic for any given VLAN. That RBridge is the Appointed Forwarder (AF). Every frame that enters a TRILL network through the AF gets encapsulated with the TRILL Header, using a nickname held by the ingress AF RBridge. 🦋 Failures, reconfigurations, and other network dynamics mean the AF for any set of VLANs can change. RBridges keep forwarding tables with bindings from destination Media Access Control (MAC) addresses and Data Labels (VLAN or Fine-Grained Labels (FGLs)) to egress RBridges. When the AF changes, remote RBridges' forwarding tables may keep sending traffic to the previous AF 😬 That traffic can get discarded at the egress, which causes traffic disruption. Not it!

High-performance apps need resiliency during failover 🔥 The active-active forwarding model minimizes impact during failures and maximizes the available network bandwidth. A typical deployment, shown in Figure 1, may have end stations and/or bridges attached to the RBridges. These devices are usually multi-homed to several RBridges, and they treat all the uplinks independently using a Local Active-Active Link Protocol (LAALP) [RFC7379], such as a single Multi-Chassis Link Aggregation (MC-LAG) bundle or Distributed Resilient Network Interconnect [802.1AX]. The AF designation in [RFC6439] requires each of the edge RBridges to exchange TRILL Hello packets. By design, an LAALP does not forward packets received on one of the member ports of the MC-LAG to other member ports of the same MC-LAG. So the AF designation methods in [RFC6439] cannot be applied to the deployment scenario in Figure 1 💀

An active-active load-sharing model can be built by representing the edge of the network connected to a specific edge group of RBridges as a single virtual RBridge ✨ Each virtual RBridge MUST have a nickname unique within its TRILL campus. Beyond active-active forwarding, other apps may need similar representations too.

Sections 4.5.1 and 4.5.2 of [RFC6325], as updated by [RFC7780], specify the distribution tree calculation and RPF check calculation algorithms for multi-destination forwarding. These algorithms depend strictly on link cost and parent RBridge priority. So depending on the network topology, an edge RBridge that's forwarding on behalf of the virtual RBridge might not have a candidate multicast tree to forward traffic on, because there's no tree where the virtual RBridge is a leaf node from that edge RBridge. Real main character problem 😭

This document presents a method that lets RBridges specify the path of association for real or virtual child nodes to distribution trees. Remote RBridges calculate their forwarding tables and derive the RPF for distribution trees based on these distribution tree association advertisements. Without any distribution tree association advertisements, remote RBridges derive the SPF (Shortest Path First) using the algorithm in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. This document updates [RFC6325] by changing, when Coordinated Multicast Trees (CMT) sub-TLVs are present, the [RFC6325] mandatory provisions about how distribution trees are constructed.

Beyond the active-active forwarding model above, other applications can use the distribution tree association framework in this document to associate with distribution trees through a preferred path 🌈

This proposal requires (1) the presence of multiple multi-destination trees within the TRILL campus, and (2) that all the RBridges in the network are updated to support the new Affinity sub-TLV (Section 3). Both of these are expected to be met, since they're control-plane changes and will be common deployment scenarios. If either of those two conditions is not met, RBridges MUST support a fallback option for interoperability. Since the fallback is expected to be temporary until all RBridges are upgraded, this proposal gives guidelines for such fallbacks but does not mandate or specify any particular set of fallback options 🫶

1.1. Scope and Applicability 💅

This document specifies an Affinity sub-TLV to solve RPF issues at the active-active edge. The specific methods here for using the Affinity sub-TLV apply where a virtual RBridge represents multiple RBridges connected to an edge Customer Equipment (CE) device through an LAALP, such as MC-LAG or a similar arrangement where the RBridges cannot see each other's Hellos.

This document does not provide the other operational elements needed to implement an active-active edge solution, such as MC-LAG methods. Solution-specific operational elements are outside the scope of this document and will be covered in other documents. (See, for example, [RFC7781].)

Examples in this document are for illustration purposes only 🙈

2. Conventions Used in This Document 🎀

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 [RFC2119].

In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying [RFC2119] significance.

2.1. Acronyms and Phrases ✨

okay so this is the glossary bit and honestly it's giving ✨ organized. let's go through the acronyms the doc keeps using 💅

AF: Appointed Forwarder [RFC6439]. 🦋

CE: Customer Equipment device, that is, a device that performs forwarding based on 802.1Q bridging. 🎀 This also can be an end station or a server.

Data Label: VLAN or FGL. 🌸

FGL: Fine-Grained Label [RFC7172]. 💜

LAALP: Local Active-Active Link Protocol [RFC7379]. 🧚

MC-LAG: Multi-Chassis Link Aggregation. 👑 A proprietary extension to [802.1AX] that facilitates connecting a group of links from an originating device (A) to a group of discrete devices (B). 🫶 Device (A) treats all of the links in a given MC-LAG bundle as a single logical interface and treats all devices in Group (B) as a single logical device for all forwarding purposes. Device (A) does not forward packets received on the multi-chassis link bundle out of the same multi-chassis link bundle. 😭 Figure 1 depicts a specific use case example. 🍓

RPF: Reverse Path Forwarding. See Section 4.5.2 of [RFC6325]. 🌈

Virtual RBridge: A purely conceptual RBridge that represents an active-active edge group and is in turn represented by a nickname. For example, see [RFC7781]. 🔥

3. The Affinity Sub-TLV ✨

okay bestie, this is where the new IS-IS sub-TLV shows up, and it's literally called the Affinity sub-TLV. 💖 binding an RBridge to a multi-destination distribution tree through a specific path happens through it. 🦋

The Affinity sub-TLV shows up in Router Capability TLVs or MT Capability TLVs that live inside Link State PDUs (LSPs), as described in [RFC7176]. 🌸 [RFC7176] is the one that specifies the code point and data structure for the Affinity sub-TLV. 💅

4. Multicast Tree Construction and Use of Affinity Sub-TLV 🎀

Figures 1 and 2 below show the reference topology and a logical topology using CMT to provide active-active service. 🧚 Here's the vibe:

                    --------------------
                   /                    \
                  |                      |
                  |     TRILL Campus     |
                  |                      |
                   \                    /
                    --------------------
                       |       |    |
                  -----        |     --------
                 |             |             |
             +------+      +------+      +------+
             |      |      |      |      |      |
             |(RB1) |      |(RB2) |      | (RBk)|
             +------+      +------+      +------+
               |..|          |..|          |..|
               |  +----+     |  |          |  |
               |   +---|-----|--|----------+  |
               | +-|---|-----+  +-----------+ |
               | | |   +------------------+ | |
              (| | |)  <-- MC-LAG          (| | |) <-- MC-LAG
             +-------+    .  .  .       +-------+
             | CE1   |                  | CEn   |
             |       |                  |       |
             +-------+                  +-------+

                   Figure 1: Reference Topology
         --------------------           Sample Multicast Tree (T1)
        /                    \
       |                      |                  |
       |     TRILL Campus     |                  o RBn
       |                      |                / | \
        \                    /                /  |  ---\
         --------------------             RB1 o  o      o
            |       |    |                    |   RB2    RBk
            |       |    --------------       |
            |       |                  |      o RBv
          +------+ +------+          +------+
          |      | |      |          |      |
          |(RB1) | |(RB2) |          | (RBk)|
          +------+ +------+          +------+
            |..|       |..|             |..|
            |  +----+  |  |             |  |
            |   +---|--|--|-------------+  |
            | +-|---|--+  +--------------+ |
            | | |   +------------------+ | |
 MC-LAG -->(| | |)                    (| | |)<-- MC-LAG
           +-------+    .  .  .       +-------+
           | CE1   |                  | CEn   |
           |       |                  |       |
           +-------+                  +-------+

    RBv: virtual RBridge

                Figure 2: Example Logical Topology

4.1. Update to RFC 6325 🌈

This document updates Section 4.5.1 of [RFC6325] and changes the calculation of distribution trees, as specified below: 💅

Each RBridge that desires to be the parent RBridge for a child RBridge (RBy) in a multi-destination distribution tree (Tree x) announces the desired association using an Affinity sub-TLV. 🦋 The child is specified by its nickname. If an RBridge (RB1) advertises an Affinity sub-TLV designating one of its own nicknames (N1) as its "child" in some distribution tree, the effect is that nickname N1 is ignored when constructing other distribution trees. Thus, the RPF check will enforce the rule that only RB1 can use nickname N1 to do ingress/egress on Tree x. (This has no effect on least-cost path calculations for unicast traffic.) 🫶

When such an Affinity sub-TLV is present, the association specified by the Affinity sub-TLV MUST be used when constructing the multi-destination distribution tree, except in the case of a conflicting Affinity sub-TLV; such cases are resolved as specified in Section 5.3. In the absence of such an Affinity sub-TLV, or if there are any RBridges in the campus that do not support the Affinity sub-TLV, distribution trees are calculated as specified in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. Section 4.3 below specifies how to identify RBridges that support the Affinity sub-TLV. 🔥

4.2. Announcing Virtual RBridge Nickname 🧚

Each edge RBridge (RB1 to RBk) advertises its LSP virtual RBridge nickname (RBv) by using the Nickname sub-TLV (6) [RFC7176], along with their regular nickname or nicknames. 🌸

It will be possible for any RBridge to determine that RBv is a virtual RBridge, because each RBridge (RB1 to RBk) that appears to be advertising that it is holding RBv is also advertising an Affinity sub-TLV asking that RBv be its child in one or more trees. 👑

Virtual RBridges are ignored when determining the distribution tree roots for the campus. 😭

All RBridges outside the edge group assume that multi-destination packets with their TRILL Header Ingress Nickname field set to RBv might use any of the distribution trees that any member of the edge group advertises that it might use. 🍓

4.3. Affinity Sub-TLV Capability 💜

RBridges that announce the TRILL Version sub-TLV [RFC7176] and set the Affinity capability bit (Section 7) support the Affinity sub-TLV, calculation of multi-destination distribution trees, and RPF checks, as specified herein. 🫶

5. Theory of Operation 🌈

5.1. Distribution Tree Assignment 🎀

Let's assume that there are n distribution trees and k edge RBridges in the edge group of interest. 🦋

If n >= k

   Let's assume that edge RBridges are sorted in numerically
   ascending order by IS-IS System ID such that RB1 < RB2 < RBk.
   Each RBridge in the numerically sorted list is assigned a
   monotonically increasing number j such that RB1 = 0, RB2 = 1,
   RBi = j, and RBi + 1 = j + 1.  (See Section 4.5 of [RFC6325], as
   updated by Section 3.4 of [RFC7780], for how tree numbers are
   determined.)

   Assign each tree to RBi such that tree number
   (((tree_number) % k) + 1) is assigned to edge group RBridge i for
   tree_number from 1 to n, where n is the number of trees, k is the
   number of edge group RBridges considered for tree allocation, and
   "%" is the integer division remainder operation.

If n < k

   Distribution trees are assigned to edge group RBridges RB1 to RBn,
   using the same algorithm as the n >= k case.  RBridges RBn + 1 to
   RBk do not participate in the active-active forwarding process on
   behalf of RBv.

5.2. Affinity Sub-TLV Advertisement 💅

Each RBridge in the RB1 through RBk domain advertises an Affinity sub-TLV for RBv to be its child.

As an example, let's assume that RB1 has chosen Trees t1 and tk + 1 on behalf of RBv.

RB1 advertises the Affinity sub-TLV:

{RBv, Num of Trees = 2, t1, tk + 1}

Other RBridges in the RB1 through RBk edge group follow the same procedure. ✨

5.3. Affinity Sub-TLV Conflict Resolution 🔥

In TRILL, multi-destination distribution trees are built outward from the root by each RBridge so that they all derive the same set of distribution trees [RFC6325]. 🦋

If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for RBridge RBroot to be its child in a tree rooted at RBroot, that AFFINITY RECORD is in conflict with TRILL distribution tree root determination and MUST be ignored. 🙈

If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for nickname RBn to be its child in any tree and RB1 is not adjacent to RBn nor does nickname RBn identify RB1 itself, that AFFINITY RECORD is in conflict with the campus topology and MUST be ignored. 💀

If different RBridges advertise Affinity sub-TLVs that try to associate the same virtual RBridge as their child in the same tree or trees, those Affinity sub-TLVs are in conflict with each other for those trees. The nicknames of the conflicting RBridges are compared to identify which RBridge holds the nickname that is the highest priority to be a tree root, with the System ID as the tiebreaker. 👑

The RBridge with the highest priority to be a tree root will retain the Affinity association. Other RBridges with lower priority to be a tree root MUST stop advertising their conflicting Affinity sub-TLVs, recalculate the multicast tree affinity allocation, and, if appropriate, advertise new non-conflicting Affinity sub-TLVs. 💖

Similarly, remote RBridges MUST honor the Affinity sub-TLV from the RBridge with the highest priority to be a tree root (using System ID as the tiebreaker in the event of conflicting priorities) and ignore the conflicting Affinity sub-TLV entries advertised by the RBridges with lower priorities to be tree roots. 🫶

5.4. Ingress Multi-Destination Forwarding 🧚

If there is at least one tree on which RBv has affinity via RBk, then RBk performs the following operations for multi-destination frames received from a CE node: 🌈

  1. Flood to locally attached CE nodes subjected to VLAN and multicast pruning.
  2. Ingress (by encapsulating with a TRILL Header) and set the Ingress Nickname field of the TRILL Header to RBv (the nickname of the virtual RBridge).
  3. Forward to one of the distribution trees, Tree x, in which RBv is associated with RBk. 💅

5.4.1. Forwarding when n < k

Okay so, what if there's no tree that RBv can claim affinity through RBk? 😭 That usually happens because the number of trees (n) built is less than the number of RBridges (k) announcing the Affinity sub-TLV. In that case, RBk MUST fall back to one of the following:

  1. This RBridge (RBk) should stop forwarding frames from the CE nodes and should mark its port towards those CE nodes as disabled. This will prevent the CE nodes from forwarding data to this RBridge. Thus, the CE nodes will only use those RBridges that have been assigned a tree. 💅

-OR-

  1. This RBridge tunnels multi-destination frames received from attached native devices to an RBridge RBy that has an assigned tree. The tunnel destination should forward it to the TRILL network and also to its local access links. (The mechanism of tunneling and handshaking between the tunnel source and destination are out of scope for this specification and may be addressed in other documents, such as [ChannelTunnel].) 🦋

The fallback options above may be specific to the active-active forwarding scenario. However, as mentioned, the Affinity sub-TLV may be used in other applications. If that happens, the application SHOULD specify applicable fallback options. 🎀

5.5. Egress Multi-Destination Forwarding

5.5.1. Traffic Arriving on an Assigned Tree to RBk-RBv

Multi-destination frames arriving at RBk on a Tree x, where RBk has announced the affinity of RBv via x, MUST be forwarded to CE members of RBv that are in the frame's VLAN. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325]. ✨

5.5.2. Traffic Arriving on Other Trees

Multi-destination frames arriving at RBk on a Tree y, where RBk has not announced the affinity of RBv via y, MUST NOT be forwarded to CE members of RBv. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325]. 🙅‍♀️

5.6. Failure Scenarios

The failure recovery algorithm below is only a guideline, so don't treat it as gospel. An active-active edge group MAY use other failure recovery algorithms, but it is recommended that only one algorithm be used in an edge group at a time. Details of those other algorithms are outside the scope of this document. 🌸

5.6.1. Edge RBridge RBk Failure

Each of the member RBridges of a given virtual RBridge edge group knows about its fellow members through configuration, LSP advertisements, or some other method. 👀

Member RBridges detect nodal failure of a member RBridge through IS-IS LSP advertisements or lack thereof.

Upon detecting a member failure, each of the member RBridges of the RBv edge group starts recovery timer T_rec for the failed RBridge RBi. If the previously failed RBridge RBi has not recovered after the expiry of timer T_rec, the member RBridges perform the distribution tree assignment algorithm specified in Section 5.1. Each of the member RBridges re-advertises the Affinity sub-TLV with the new tree assignment. This action causes the campus to update the tree calculation with the new assignment. 🔄

RBi, upon startup, advertises its presence through IS-IS LSPs and starts a timer T_i. Other member RBridges of the edge group, detecting the presence of RBi, start a timer T_j.

Upon expiry of timer T_j, the other member RBridges recalculate the multi-destination tree assignment and advertise the related trees using the Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculates the multi-destination tree assignment and advertises the related trees using the Affinity sub-TLV.

Now, the timing drama. ⏰ If the new RBridge in the edge group calculates trees and starts to use one or more of them before the existing RBridges in the edge group recalculate, there could be duplication of packets (for example, more than one edge group RBridge could decapsulate and forward a multi-destination frame on links into the active-active group) or loss of packets (for example, due to the Reverse Path Forwarding check, in the rest of the campus, if two edge group RBridges are trying to forward on the same tree, those from one will be discarded). Alternatively, if the new RBridge in the edge group calculates trees and starts to use one or more of them after the existing RBridges recalculate, there could be loss of data due to frames arriving at the new RBridge being black-holed. 😱

Timers T_i and T_j should be initialized to values designed to minimize these problems, keeping in mind that, in general, duplication of packets is a more serious problem than dropped packets. It is RECOMMENDED that T_j be less than T_i, and a reasonable default is 1/2 of T_i. 💜

5.7. Backward Compatibility

Implementations MUST support a backward compatibility modes to interoperate with "pre-Affinity sub-TLV" RBridges in the network. Such backward compatibility operations MAY include, but are not limited to, tunneling and/or active-standby modes of operation. It should be noted that tunneling would require silicon changes. However, CMT in itself is a software upgrade. 🛠️

Example:

Step 1. Stop using the virtual RBridge nickname for traffic ingressing from CE nodes.

Step 2. Stop performing active-active forwarding. Fall back to active standby forwarding, based on locally defined policies. The definition of such policies is outside the scope of this document and may be addressed in other documents.

6. Security Considerations 🔐

Now the serious part, bestie. Security is not optional. 🚨

In general, the RBridges in a campus are trusted routers, and the authenticity of their link-state information (LSPs) and link-local PDUs (e.g., Hellos) can be enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310]. This includes authenticating the contents of the PDUs used to transport Affinity sub-TLVs.

The particular security considerations involved with different applications of the Affinity sub-TLV will be covered in the document(s) specifying those applications.

For general TRILL security considerations, see [RFC6325].

7. IANA Considerations 📋

This document serves as the reference for the registration of "Affinity sub-TLV support" (bit 0) in the "TRILL-VER Sub-TLV Capability Flags" registry.

This document mentions the registration of "AFFINITY" (value 17) in the "Sub-TLVs for TLV 144" registry, but it is intentionally not listed as a reference for that registration; the reference remains [RFC7176]. 🙃

8. References 📚

8.1. Normative References

8.2. Informative References

  • [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.
  • [ChannelTunnel] Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge Channel Tunnel Protocol", Work in Progress, draft-ietf-trill-channel-tunnel-07, August 2015.
  • [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>.

Acknowledgments 🫶

The authors wish to extend their appreciations towards individuals who volunteered to review and comment on the work presented in this document and who provided constructive and critical feedback. Specific acknowledgments are due for Anoop Ghanwani, Ronak Desai, Gayle Noble, and Varun Shah. Very special thanks to Donald Eastlake for his careful review and constructive comments.

Contributors 🌈

The work in this document is a result of many passionate discussions and contributions from the following individuals, listed in alphabetical order by their first names:

Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Hongjun Zhai, Mingui Zhang, Radia Perlman, Sam Aldrin, and Shivakumar Sundaram.

Authors' Addresses 💌

Tissa Senevirathne
Consultant

Email: tsenevir@gmail.com


Janardhanan Pathangi
Dell/Force10 Networks
Olympia Technology Park
Guindy Chennai  600 032
India

Phone: +91-44-42208400
Email: Pathangi_Janardhanan@Dell.com


Jon Hudson
Brocade
130 Holger Way
San Jose, CA  95134
United States

Phone: +1-408-333-4062
Email: jon.hudson@gmail.com
📦 where this page comes from