Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7781

Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access

Pages: 35
Proposed Standard
Part 1 of 2 – Pages 1 to 19
None   None   Next

Top   ToC   RFC7781 - Page 1
Internet Engineering Task Force (IETF)                           H. Zhai
Request for Comments: 7781                                           JIT
Category: Standards Track                                T. Senevirathne
ISSN: 2070-1721                                               Consultant
                                                              R. Perlman
                                                                     EMC
                                                                M. Zhang
                                                                   Y. Li
                                                     Huawei Technologies
                                                           February 2016


         Transparent Interconnection of Lots of Links (TRILL):
                Pseudo-Nickname for Active-Active Access

Abstract

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active- active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active- active access by such 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). 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/rfc7781.
Top   ToC   RFC7781 - Page 2
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, 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.
Top   ToC   RFC7781 - Page 3

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 ................................................35
Top   ToC   RFC7781 - Page 4

1. Introduction

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] [RFC7176] link-state routing and encapsulating traffic using 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 be attached to the TRILL campus via a point-to-point link or a shared link such as a bridged LAN (Local Area Network). Although there might be more than one edge RBridge on a shared link, to avoid potential forwarding loops, one and only one of the edge RBridges is permitted to provide forwarding service for end-station traffic in each VLAN (Virtual LAN). That RBridge is referred to as the Appointed Forwarder (AF) for that VLAN on the link [RFC6325] [RFC6439]. However, in some practical deployments, to increase the access bandwidth and reliability, an end station might be multiply connected to several edge RBridges, and all of the uplinks are handled via a Local Active-Active Link Protocol (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [802.1AX]. In this case, it is required that traffic can be ingressed into, and egressed from, the TRILL campus by any of the RBridges for each given VLAN. These RBridges constitute 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 frequently be sent to different member RBridges of the AAE group and then ingressed into the TRILL campus. When an egress RBridge receives such TRILL Data packets ingressed by different RBridges, it learns different correspondences between a {Data Label and MAC address} and nickname continuously when decapsulating the packets if it has data-plane address learning enabled. This issue is known as "MAC address flip-flopping"; it makes most TRILL switches behave badly and causes the returning traffic to reach the destination via different paths, resulting in persistent reordering of the frames. In addition to this issue, other issues, such as duplicate egressing and loopback of multi-destination frames, may also disturb an end station multiply connected to the member RBridges of an AAE group [RFC7379]. This document addresses the AAE issues of TRILL by specifying how members of an edge RBridge group can be represented by a virtual RBridge (RBv) and assigned a pseudo-nickname. A member RBridge of such a group uses a pseudo-nickname instead of its own nickname as
Top   ToC   RFC7781 - Page 5
   the ingress RBridge nickname when ingressing frames received on
   attached LAALP links.  Other methods are possible: for example, the
   specification in this document and the specification in [RFC7782]
   could be simultaneously deployed for different AAE groups in the same
   campus.  If the method defined 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 defined 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.  However, it is
   desirable to only adopt one method in a TRILL campus so that the
   operating expense, complexity of troubleshooting, etc., can be
   reduced.

   The main body of this document is organized as follows:

   o  Section 2 provides an overview of the TRILL active-active access
      issues and the reason that a virtual RBridge (RBv) is used to
      resolve the issues.

   o  Section 3 describes the concept of a virtual RBridge (RBv) and its
      pseudo-nickname.

   o  Section 4 describes how edge RBridges can support an RBv
      automatically and get a pseudo-nickname for the RBv.

   o  Section 5 discusses how to protect multi-destination traffic
      against disruption due to Reverse Forwarding Path (RPF) check
      failure, duplication, forwarding loops, etc.

   o  Section 6 covers the special processing of native frames and TRILL
      Data packets at member RBridges of an RBv (also referred to as an
      Active-Active Edge (AAE) RBridge group).

   o  Section 7 describes the MAC information synchronization among the
      member RBridges of an RBv.

   o  Section 8 discusses protection against downlink failure at a
      member RBridge.

   o  Section 9 lists the necessary TRILL code points and data
      structures for a pseudo-nickname AAE RBridge group.
Top   ToC   RFC7781 - Page 6

1.1. Terminology and Acronyms

This document uses the acronyms and terms defined in [RFC6325] and [RFC7379], as well as the following additional acronyms: 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 consisting 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).
Top   ToC   RFC7781 - Page 7
   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

To minimize impact during failures and maximize available access bandwidth, Customer Equipment (referred to as "CE" in this document) may be multiply connected to the TRILL campus via multiple edge RBridges. 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].
Top   ToC   RFC7781 - Page 8
                         ----------------------
                        |                      |
                        |     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.
Top   ToC   RFC7781 - Page 9
   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
Top   ToC   RFC7781 - Page 10
   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.)

   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.

   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.

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. 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).
Top   ToC   RFC7781 - Page 11

4.1. Discovering Member RBridge for an RBv

Take Figure 2 as an example, where CE1 and CE2 multiply attach to RB1, RB2, and RB3 via LAALP1 and LAALP2, respectively; CE3 and CE4 attach to RB3, and RB4 via LAALP3 and LAALP4, respectively. Assume that LAALP3 is configured to occupy a virtual RBridge by itself. ------------------------ / \ | TRILL Campus | \ / ------------------------- | | | | +-------+ | | +----------+ | | | | +-------+ +-------+ +-------+ +-------+ | RB1 | | RB2 | | RB3 | | RB4 | +-------+ +-------+ +-------+ +-------+ | | | | | | | | | | | +--------|--+ | +-------|-+ | +-------|---+ | | +----------+ | | | | | | | | | | +-----------|-|-|-------+ | +-------+ | | | | | | | | | | | | LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |) +-------+ +-------+ +-------+ +-------+ | CE1 | | CE2 | | CE3 | | CE4 | +-------+ +-------+ +-------+ +-------+ Figure 2: Different LAALPs to TRILL Campus RB1 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.
Top   ToC   RFC7781 - Page 12
   An edge RBridge is called an "LAALP related RBridge" if it has at
   least one LAALP configured on an access port.  On receipt of 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}

   where the OE-flag indicates whether a given 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.

   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 above table, there might be some LAALPs that attach to a
   single RBridge due to misconfiguration or link failure, etc.  Those
   LAALPs are considered to be invalid entries.  Each of the LAALP
   related edge RBridges then performs 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, these LAALPs are then ordered in ascending order
         in the proper places of the table, based on their LAALP IDs
         considered to be unsigned integers.  (For example, in the above
Top   ToC   RFC7781 - Page 13
         table, both LAALP1 and LAALP2 have three member RBridges,
         assuming that the LAALP1 ID is smaller than the LAALP2 ID, so
         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 multi-homed
         RBridges contain exactly the same RBridges as that of 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 performing the above steps, all the 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; and LAALP4 is served
   by RBv3, which has RB3 and RB4 as member RBridges, shown as follows:

          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 is elected as the vDRB
   (referred to in this document as the Designated RBridge of the RBv).
   Then, this RBridge picks up an available nickname as the
   pseudo-nickname for the RBv and announces it to all 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 duty of selecting a pseudo-nickname for this RBv; 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 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
Top   ToC   RFC7781 - Page 14
   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 the changing of nicknames,
   if possible, the vDRB SHOULD attempt to reuse the pseudo-nickname
   recently used by the group when selecting nickname for the RBv.  To
   help the vDRB to do so, each LAALP related RBridge advertises a
   reusing pseudo-nickname for each of its LAALPs in its
   PN-LAALP-Membership APPsub-TLV if it has used such a pseudo-nickname
   for that LAALP recently.  Although it is up to the implementation of
   the vDRB as to how to treat the reusing pseudo-nicknames, the
   following are RECOMMENDED:

   o  If there are multiple available reusing pseudo-nicknames that are
      reported by all the member RBridges of some LAALPs in this RBv,
      the available one that is reported by the largest number of such
      LAALPs is chosen as the pseudo-nickname for this RBv.  If a tie
      exists, the reusing pseudo-nickname with the smallest value
      considered to be an unsigned integer is chosen.

   o  If only one reusing pseudo-nickname is reported, it SHOULD be
      chosen if available.

   If there is no available reusing pseudo-nickname reported, the vDRB
   selects a nickname by its usual method.

   The selected pseudo-nickname is then announced by the vDRB to 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, as each of the member RBridges 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 will result in loopback of the frame for CEi. These problems are all described in [RFC7379].
Top   ToC   RFC7781 - Page 15
   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 will result 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 and 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.
Top   ToC   RFC7781 - Page 16

5.2. Designated Forwarder for Member RBridges

Take Figure 3 as an example, where CE1 and CE2 are served by an RBv that has RB1 and RB2 as member RBridges. In VLAN x, the three CEs can communicate with 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 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 will receive it. As each of them thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would both forward the frame to CE1/CE2. As a result, CE1/CE2 would receive duplicate copies of the frame through this RBv. In another case, assume that CE3 is single-homed to RB2. When it transmits a native multi-destination frame onto link CE3-RB2 in VLAN x, the frame can be locally replicated to the ports to CE1/CE2, and also encapsulated into TRILL Data packet and ingressed into the TRILL campus. When the packet arrives at RB1 across the TRILL campus, it will be egressed to CE1/CE2 by RB1. CE1/CE2 then receives duplicate copies from RB1 and RB2.
Top   ToC   RFC7781 - Page 17
   In this document, the Designated Forwarder (DF) for a VLAN is
   introduced to avoid duplicate copies.  The basic idea of the DF is to
   elect one RBridge per VLAN from an RBv to egress multi-destination
   TRILL Data traffic and replicate locally received multi-destination
   native frames to the CEs served by the RBv.

   Note that the DF has an effect only on the egressing/replicating of
   multi-destination traffic.  It has no effect on the ingressing,
   forwarding, or egressing of unicast frames.  Furthermore, the DF
   check is performed only for RBv ports, not on regular access ports.

   Each RBridge in an RBv elects a DF using the same algorithm; this
   guarantees that, per VLAN, the same RBridge is elected as the DF by
   all members of the RBv.

   If we assume that there are m LAALPs and k member RBridges in an RBv,
   then (1) each LAALP is referred to as "LAALPi", where 0 <= i < m, and
   (2) each RBridge is referred to as "RBj", where 0 <= j < k.  The DF
   election algorithm per VLAN is as follows:

      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, i.e., 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.
Top   ToC   RFC7781 - Page 18
   For any multi-destination native frames of VLAN x that are received,
   if RBi is an LAALP attached RBridge, there are three cases where RBi
   replicates the multi-destination frame, as follows:

      1) Local replication of the frame to regular (non-AAE) access
         ports as per [RFC6325] (and [RFC7172] for FGL).

      2) 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 cannot
         simply depend on the DF to forward the multi-destination frame
         back into the AAEs associated with the pseudo-nickname, as that
         would cause the source CE to get the frame back, which is a
         violation of basic Ethernet properties.  The DF will not
         forward such a frame back into the AAE due to ingress nickname
         filtering as described in Section 5.3.

      3) RBv ports on which RBi is the DF for the frame's VLAN while
         they are associated with different pseudo-nickname(s) than that
         of the incoming port.

   For any multi-destination TRILL Data packets that are received, RBi
   MUST NOT egress it 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).

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). The traffic is then TRILL-encapsulated by RB1 and delivered through the TRILL campus to multi-destination receivers. RB2 may receive the traffic and egress it back to CE1 if it is the DF for VLAN x on the port to LAALP1. The traffic then loops back to CE1 (see Section 3.2 of [RFC7379]). To fix the above issue, 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
Top   ToC   RFC7781 - Page 19
   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 the
   multi-destination native frames that are received on access ports and
   replicated to other local ports (including RBv ports), since there is
   no ingress nickname associated with such frames.  Furthermore, for
   the RBridge regular access ports, there is no pseudo-nickname
   associated with them, so no ingress nickname filtering check is
   required on those ports.

   More details of data packet processing on RBv ports are given in the
   next section.



(page 19 continued on part 2)

Next Section