GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7781

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.

Zhai, et al. Standards Track [Page 1] RFC 7781 Pseudo-Nickname February 2016

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.

Zhai, et al. Standards Track [Page 2] RFC 7781 Pseudo-Nickname February 2016

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

Zhai, et al. Standards Track [Page 3] RFC 7781 Pseudo-Nickname February 2016

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

Zhai, et al. Standards Track [Page 4] RFC 7781 Pseudo-Nickname February 2016

 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.

Zhai, et al. Standards Track [Page 5] RFC 7781 Pseudo-Nickname February 2016

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).

Zhai, et al. Standards Track [Page 6] RFC 7781 Pseudo-Nickname February 2016

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

Zhai, et al. Standards Track [Page 7] RFC 7781 Pseudo-Nickname February 2016

  1. ———————

| |

                      |     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.

Zhai, et al. Standards Track [Page 8] RFC 7781 Pseudo-Nickname February 2016

 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

Zhai, et al. Standards Track [Page 9] RFC 7781 Pseudo-Nickname February 2016

 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).

Zhai, et al. Standards Track [Page 10] RFC 7781 Pseudo-Nickname February 2016

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.
  1. ———————–

/ \

                  |       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.

Zhai, et al. Standards Track [Page 11] RFC 7781 Pseudo-Nickname February 2016

 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

Zhai, et al. Standards Track [Page 12] RFC 7781 Pseudo-Nickname February 2016

       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

Zhai, et al. Standards Track [Page 13] RFC 7781 Pseudo-Nickname February 2016

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

Zhai, et al. Standards Track [Page 14] RFC 7781 Pseudo-Nickname February 2016

 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.

Zhai, et al. Standards Track [Page 15] RFC 7781 Pseudo-Nickname February 2016

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.
  1. ——————–

/ \ +—–+

                  |       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.

Zhai, et al. Standards Track [Page 16] RFC 7781 Pseudo-Nickname February 2016

 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.

Zhai, et al. Standards Track [Page 17] RFC 7781 Pseudo-Nickname February 2016

 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

Zhai, et al. Standards Track [Page 18] RFC 7781 Pseudo-Nickname February 2016

 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.

6. TRILL Traffic Processing

 This section provides more details of native frame and TRILL Data
 packet processing as it relates to the RBv's pseudo-nickname.

6.1. Ingressing Native Frames

 When RB1 receives a unicast native frame from one of its ports that
 has end-station service enabled, it processes the frame as described
 in Section 4.6.1.1 of [RFC6325], with the following exception:
 o  If the port is an RBv port, RB1 uses the RBv's pseudo-nickname
    instead of one of its regular nickname(s) as the ingress nickname
    when doing TRILL encapsulation on the frame.
 When RB1 receives a native multi-destination (broadcast,
 unknown unicast, or multicast) frame from one of its access ports
 (including regular access ports and RBv ports), it processes the
 frame as described in Section 4.6.1.2 of [RFC6325], with the
 following exceptions:
 o  If the incoming port is an RBv port, RB1 uses the RBv's
    pseudo-nickname instead of one of its regular nickname(s) as the
    ingress nickname when doing TRILL encapsulation on the frame.

Zhai, et al. Standards Track [Page 19] RFC 7781 Pseudo-Nickname February 2016

 o  For the copies of the frame replicated locally to RBv ports, there
    are two cases, as follows:
  1. If the outgoing port(s) is associated with the same

pseudo-nickname as that of the incoming port but not with the

      same LAALP as the incoming port, the copies are forwarded out of
      that outgoing port(s) after passing the Appointed Forwarder
      check for the frame's VLAN.  That is to say, the copies are
      processed on such port(s), as discussed in Section 4.6.1.2 of
      [RFC6325].
  1. Else, the Designated Forwarder (DF) check is also made on the

outgoing ports for the frame's VLAN after the Appointed

      Forwarder check, and the copies are not output through any ports
      that failed the DF check (i.e., RB1 is not the DF for the
      frame's VLAN on the ports).  Otherwise, the copies are forwarded
      out of the outgoing ports that pass both the Appointed Forwarder
      check and the DF check (see Section 5.2).
 For any such frames received, the MAC address information learned by
 observing it, together with the LAALP ID of the incoming port, SHOULD
 be shared with other member RBridges in the group (see Section 7).

6.2. Egressing TRILL Data Packets

 This section describes egress processing of the TRILL Data packets
 received on an RBv member RBridge (say RBn).  Section 6.2.1 describes
 the egress processing of unicast TRILL Data packets, and
 Section 6.2.2 specifies the egressing of multi-destination TRILL Data
 packets.

6.2.1. Unicast TRILL Data Packets

 When receiving a unicast TRILL Data packet, RBn checks the egress
 nickname in the TRILL Header of the packet.  If the egress nickname
 is one of RBn's regular nicknames, the packet is processed as defined
 in Section 4.6.2.4 of [RFC6325].
 If the egress nickname is the pseudo-nickname of a local RBv, RBn is
 responsible for learning the source MAC address, unless data-plane
 learning has been disabled.  The learned {Inner.MacSA, Data Label,
 ingress nickname} triplet SHOULD be shared within the AAE group as
 described in Section 7.

Zhai, et al. Standards Track [Page 20] RFC 7781 Pseudo-Nickname February 2016

 The packet is then decapsulated to its native form.  The Inner.MacDA
 and Data Label are looked up in RBn's local forwarding tables, and
 one of the three following cases will occur.  RBn uses the first case
 that applies and ignores the remaining cases:
 o  If the destination end station identified by the Inner.MacDA and
    Data Label is on a local link, the native frame is sent onto that
    link with the VLAN from the Inner.VLAN or VLAN corresponding to
    the Inner.Label if the packet is FGL.
 o  Else if RBn can reach the destination through another member
    RBridge (say RBk), it tunnels the native frame to RBk by
    re-encapsulating it into a unicast TRILL Data packet and sends it
    to RBk.  RBn uses RBk's regular nickname instead of the
    pseudo-nickname as the egress nickname for the re-encapsulation,
    and the ingress nickname remains unchanged (somewhat similar to
    Section 2.4.2.1 of [RFC7780]).  If the Hop Count value of the
    packet is too small for it to reach RBk safely, RBn SHOULD
    increase that value properly in doing the re-encapsulation.
    (NOTE: When receiving that re-encapsulated TRILL Data packet, as
    the egress nickname of the packet is RBk's regular nickname rather
    than the pseudo-nickname of a local RBv, RBk will process it per
    Section 4.6.2.4 of [RFC6325] and will not re-forward it to another
    RBridge.)
 o  Else, RBn does not know how to reach the destination; it sends the
    native frame out of all the local ports on which it is Appointed
    Forwarder for the Inner.VLAN (or Appointed Forwarder for the VLAN
    into which the Inner.Label maps on that port for an FGL TRILL Data
    packet [RFC7172]).

6.2.2. Multi-Destination TRILL Data Packets

 When RB1 receives a multi-destination TRILL Data Packet, it checks
 and processes the packet as described in Section 4.6.2.5 of
 [RFC6325], with the following exception:
 o  On each RBv port where RBn is the Appointed Forwarder for the
    packet's Inner.VLAN (or for the VLAN to which the packet's
    Inner.Label maps on that port if it is an FGL TRILL Data packet),
    the DF check (see Section 5.2) and the ingress nickname filtering
    check (see Section 5.3) are further performed.  For such an RBv
    port, if either the DF check or the filtering check fails, the
    frame MUST NOT be egressed out of that port.  Otherwise, it can be
    egressed out of that port.

Zhai, et al. Standards Track [Page 21] RFC 7781 Pseudo-Nickname February 2016

7. MAC Information Synchronization in Edge Group

 An edge RBridge, say RB1 in LAALP1, may have learned a correspondence
 between a {Data Label and MAC address} and nickname for a remote host
 (say h1) when h1 sends a packet to CE1.  The returning traffic from
 CE1 may go to another member RBridge of LAALP1 (for example, RB2).
 RB2 may not have that correspondence stored.  Therefore, it has to do
 the flooding for unknown unicast.  Such flooding is unnecessary,
 since the returning traffic is almost always expected and RB1 had
 learned the address correspondence.  To avoid the unnecessary
 flooding, RB1 SHOULD share the correspondence with other RBridges of
 LAALP1.  RB1 synchronizes the correspondence by using the
 MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs
 [RFC7357].
 On the other hand, RB2 has learned the MAC address and Data Label of
 CE1 when CE1 sends a frame to h1 through RB2.  The returning traffic
 from h1 may go to RB1.  RB1 may not have CE1's MAC address and Data
 Label stored even though it is in the same LAALP for CE1 as RB2.
 Therefore, it has to flood the traffic out of all its access ports
 where it is Appointed Forwarder for the VLAN (see Section 6.2.1) or
 the VLAN the FGL maps to on that port if the packet is FGL.  Such
 flooding is unnecessary, since the returning traffic is almost always
 expected and RB2 had learned CE1's MAC and Data Label information.
 To avoid that unnecessary flooding, RB2 SHOULD share the MAC address
 and Data Label with other RBridges of LAALP1.  RB2 synchronizes the
 MAC address and Data Label by enclosing the relative MAC-RI TLV
 within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see
 Section 9.3) in its ESADI-LSP [RFC7357].  After receiving the
 enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1
 related RBridges) treat the MAC address and Data Label as if it were
 learned by them locally on their member port of LAALP1; the LAALP1
 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and
 treat the MAC address and Data Label as specified in [RFC7357].
 Furthermore, in order to make the LAALP1 unrelated RBridges know that
 the MAC and Data Label are reachable through the RBv that provides
 service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV
 SHOULD carry the pseudo-nickname of the RBv, rather than a zero value
 or one of the originating RBridge's (i.e., RB2's) regular nicknames.

Zhai, et al. Standards Track [Page 22] RFC 7781 Pseudo-Nickname February 2016

8. Member Link Failure in an RBv

 As shown in Figure 4, suppose that the link RB1-CE1 fails.  Although
 a new RBv will be formed by RB2 and RB3 to provide active-active
 service for LAALP1 (see Section 5), the unicast traffic to CE1 might
 still be forwarded to RB1 before the remote RBridge learns that CE1
 is attached to the new RBv.  That traffic might be disrupted by the
 link failure.  Section 8.1 discusses failure protection in this
 scenario.
 However, multi-destination TRILL Data packets can reach all member
 RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3
 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the
 packet's Inner.Label maps to in the new RBv).  Although there might
 be a transient hang time between failure and the establishment of the
 new RBv, special actions to protect against downlink failure for such
 multi-destination packets are not needed.
  1. —————–

/ \

                     |     TRILL Campus     |
                      \                    /
                       --------------------
                           |     |     |
                       +---+     |     +----+
                       |         |          |
                   +------+     +------+   +------+
                   | RB1  |     | RB2  |   | RB3  |
                   ooooooo|ooooo|oooooo|ooo|ooooo |
                  o+------+ RBv +------+   +-----o+
                   o|oooo|ooooooo|oooo|ooooo|oo|o
                    |    |       |  +-|-----+  |
                   \|/+--|-------+  | +------+ |
                  - B |  +----------|------+ | |
                   /|\| +-----------+      | | |
                   (| | |)<--LAALP1       (| | |)<--LAALP2
                  +-------+              +-------+
                  |  CE1  |              |  CE2  |
                  +-------+              +-------+
        B - Failed Link or Link Bundle
             Figure 4: A Multi-Homed CE with a Failed Link

Zhai, et al. Standards Track [Page 23] RFC 7781 Pseudo-Nickname February 2016

8.1. Link Protection for Unicast Frame Egressing

 When the link CE1-RB1 fails, RB1 loses its direct connection to CE1.
 The MAC entry through the failed link to CE1 is removed from RB1's
 local forwarding table immediately.  Another MAC entry learned from
 another member RBridge of LAALP1 (for example, RB2, since it is still
 a member RBridge of LAALP1) is installed into RB1's forwarding table
 (see Section 9.3).  In that new entry, RB2 (identified by one of its
 regular nicknames) is the egress RBridge for CE1's MAC address.
 Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be
 tunneled to RB2 after being re-encapsulated (the ingress nickname
 remains unchanged and the egress nickname is replaced by RB2's
 regular nickname) based on the above installed MAC entry (see
 bullet 2 in Section 6.2.1).  RB2 then receives the frame and egresses
 it to CE1.
 After failure recovery, RB1 learns that it can reach CE1 via link
 CE1-RB1 again by observing CE1's native frames or from the MAC
 information synchronization by member RBridge(s) of LAALP1 as
 described in Section 7.  It then restores the MAC entry to its
 previous one and downloads it to its data-plane "fast path" logic.

9. TLV Extensions for Edge RBridge Group

 The following subsections specify the APPsub-TLVs needed to support
 pseudo-nickname edge groups.

9.1. PN-LAALP-Membership APPsub-TLV

 This APPsub-TLV is used by an edge RBridge to announce its associated
 pseudo-nickname LAALP information.  It is defined as a sub-TLV of the
 TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs
 [RFC7780].  It has the following format:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = PN-LAALP-Membership   |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Length                       |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
       |  LAALP RECORD(1)                          |  (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
       .                                           .
       .                                           .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
       |  LAALP RECORD(n)                          |  (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
        Figure 5: PN-LAALP-Membership Advertisement APPsub-TLV

Zhai, et al. Standards Track [Page 24] RFC 7781 Pseudo-Nickname February 2016

 where each LAALP RECORD has the following form:
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
       +--+-+-+-+-+-+-+-+
       |OE|     RESV    |                  (1 byte)
       +--+-+-+-+-+-+-+-+
       |  Size          |                  (1 byte)
       +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reusing Pseudo-Nickname      |  (2 bytes)
       +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
       |  LAALP ID                                  |  (variable)
       +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
 o  PN-LAALP-Membership (2 bytes): Defines the type of this
    sub-TLV, 2.
 o  Length (2 bytes): The sum of the lengths of the LAALP RECORDs.
 o  OE (1 bit): A flag indicating whether or not the LAALP wants to
    occupy an RBv by itself; 1 for occupying by itself (or Occupying
    Exclusively (OE)).  By default, it is set to 0 on transmit.  This
    bit is used for edge RBridge group auto-discovery (see
    Section 4.1).  For any one LAALP, the values of this flag might
    conflict in the LSPs advertised by different member RBridges of
    that LAALP.  In that case, the flag for that LAALP is considered
    to be 1.
 o  RESV (7 bits): MUST be transmitted as zero and ignored on receipt.
 o  Size (1 byte): Size of the remaining part of the LAALP RECORD
    (2 plus the length of the LAALP ID).
 o  Reusing Pseudo-Nickname (2 bytes): Suggested pseudo-nickname of
    the AAE group serving the LAALP.  If the LAALP is not served by
    any AAE group, this field MUST be set to zero.  It is used by the
    originating RBridge to help the vDRB to reuse the previous
    pseudo-nickname of an AAE group (see Section 4.2).
 o  LAALP ID (variable): The ID of the LAALP.  See Section 9.4.
 On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge
 RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV.
 When new LAALPs are found or old ones are withdrawn compared to its
 old copy, and they are also configured on RBn, RBn performs the
 "Member RBridges Auto-Discovery" procedure described in Section 4.

Zhai, et al. Standards Track [Page 25] RFC 7781 Pseudo-Nickname February 2016

9.2. PN-RBv APPsub-TLV

 The PN-RBv APPsub-TLV is used by a Designated RBridge of a virtual
 RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served
 by the RBv.  It is defined as a sub-TLV of the TRILL GENINFO TLV
 [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780].  It has the
 following format:
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type = PN-RBv                 |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Length                        |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | RBv's Pseudo-Nickname         |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | LAALP ID Size |  (1 byte)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
        | LAALP ID (1)                                |  (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
        .                                             .
        .                                             .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
        | LAALP ID (n)                                |  (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
 o  PN-RBv (2 bytes): Defines the type of this sub-TLV, 3.
 o  Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each
    of size k bytes.  k is found in the LAALP ID Size field below.  If
    Length is not 3 plus an integer times k, the sub-TLV is corrupt
    and MUST be ignored.
 o  RBv's Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for
    the RBv that serves the LAALPs listed in the following fields.
 o  LAALP ID Size (1 byte): The size of each of the following LAALP
    IDs in this sub-TLV.  8 if the LAALPs listed are MC-LAGs or DRNI
    (Section 6.3.2 of [802.1AX]).  The value in this field is the k
    value that appears in the formula for Length above.
 o  LAALP ID (LAALP ID Size bytes): The ID of the LAALP.  See
    Section 9.4.
 This sub-TLV may occur multiple times with the same RBv
 pseudo-nickname; this means that all of the LAALPs listed are
 identified by that pseudo-nickname.  For example, if there are
 LAALP IDs of different length, then the LAALP IDs of each size would
 have to be listed in a separate sub-TLV.

Zhai, et al. Standards Track [Page 26] RFC 7781 Pseudo-Nickname February 2016

 Because a PN-RBv APPsub-TLV is distributed as part of the application
 link state by using the E-L1FS FS-LSP [RFC7780], creation, changes to
 contents, or withdrawal of a PN-RBv APPsub-TLV is accomplished by the
 Designated RBridge updating and flooding an E-L1FS PDU.
 On receipt of such a sub-TLV, if RBn is not an LAALP related edge
 RBridge, it ignores the sub-TLV.  Otherwise, if RBn is also a member
 RBridge of the RBv identified by the list of LAALPs, it associates
 the pseudo-nickname with the ports of these LAALPs and downloads the
 association to data-plane fast path logic.  At the same time, RBn
 claims the RBv's pseudo-nickname across the campus and announces the
 RBv as its child on the corresponding tree or trees using the
 Affinity sub-TLV [RFC7176] [RFC7783].

9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs

 In this document, two APPsub-TLVs are used as boundary APPsub-TLVs
 for an edge RBridge to enclose the MAC-RI TLV(s) containing the MAC
 address information learned from the local port of an LAALP when this
 RBridge wants to share the information with other edge RBridges.
 They are defined as TRILL APPsub-TLVs [RFC7357].  The
 PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Length                        | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
       | LAALP ID                                 | (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
 o  PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this
    sub-TLV, 4.
 o  Length (2 bytes): The size of the following LAALP ID.  8 if the
    LAALP listed is an MC-LAG or DRNI.
 o  LAALP ID (variable): The ID of the LAALP (see Section 9.4).

Zhai, et al. Standards Track [Page 27] RFC 7781 Pseudo-Nickname February 2016

 The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Length                        | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 o  PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this
    sub-TLV, 5.
 o  Length (2 bytes): 0.
 This pair of APPsub-TLVs can be carried multiple times in an
 ESADI-LSP and in multiple ESADI-LSPs.  When an LAALP related edge
 RBridge (say RBn) wants to share with other edge RBridges the MAC
 addresses learned on its local ports of different LAALPs, it uses one
 or more pairs of such APPsub-TLVs for each such LAALP in its
 ESADI-LSPs.  Each encloses the MAC-RI TLVs containing the MAC
 addresses learned from a specific LAALP.  Furthermore, if the LAALP
 is served by a local RBv, the value of the Topology-ID/Nickname field
 in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv,
 rather than one of RBn's regular nicknames or a zero value.  Then, on
 receipt of such a MAC-RI TLV, remote RBridges know that the contained
 MAC addresses are reachable through the RBv.
 On receipt of such boundary APPsub-TLVs, when the edge RBridge is not
 an LAALP related one or cannot recognize such sub-TLVs, it ignores
 them and continues to parse the enclosed MAC-RI TLVs per [RFC7357].
 Otherwise, the recipient parses the boundary APPsub-TLVs.  The
 PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur
 within one TRILL GENINFO TLV.  If an END is encountered without any
 previous START in the ESADI-LSP, the END APPsub-TLV is ignored.
 After encountering a START, if the end of the ESADI-LSP is reached
 without encountering an END, then the end of the ESADI-LSP is treated
 as if it were a PN-MAC-RI-LAALP-INFO-END.  The boundary APPsub-TLVs
 and TLVs between them are handled as follows:
 1) If the edge RBridge is configured with the contained LAALP and the
    LAALP is also enabled locally, it treats all the MAC addresses
    contained in the following MC-RI TLVs enclosed by the
    corresponding pair of boundary APPsub-TLVs as if they were learned
    from its local port of that LAALP;
 2) Else, it ignores these boundary APPsub-TLVs and continues to parse
    the following MAC-RI TLVs per [RFC7357] until another pair of
    boundary APPsub-TLVs is encountered.

Zhai, et al. Standards Track [Page 28] RFC 7781 Pseudo-Nickname February 2016

9.4. LAALP IDs

 The LAALP ID identifies an AAE RBridge group in the TRILL campus and
 thus MUST be unique across the campus.  In all of the APPsub-TLVs
 specified above, the length of the LAALP ID can be determined from a
 size field.  If that length is 8 bytes, the LAALP ID is an MC-LAG or
 DRNI identifier as specified in Section 6.3.2 of [802.1AX].  The
 meaning and structure of LAALP IDs of other lengths are reserved and
 may be specified in future documents.

10. OAM Packets

 Attention must be paid when generating Operations, Administration,
 and Maintenance (OAM) packets.  To ensure that the response messages
 can return to the originating member RBridge of an RBv, a
 pseudo-nickname cannot be used as the ingress nickname in TRILL OAM
 messages, except in the response to an OAM message that has that
 RBv's pseudo-nickname as the egress nickname.  For example, assume
 that RB1 is a member RBridge of RBvi.  RB1 cannot use RBvi's
 pseudo-nickname as the ingress nickname when originating OAM
 messages; otherwise, the responses to the messages may be delivered
 to another member RBridge of RBvi rather than RB1.  But when RB1
 responds to the OAM message with RBvi's pseudo-nickname as the egress
 nickname, it can use that pseudo-nickname as the ingress nickname in
 the response message.
 Since RBridges cannot use OAM messages for the learning of MAC
 addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC
 address flip-flopping at a remote RBridge, even though RB1 uses its
 regular nicknames as ingress nicknames in its TRILL OAM messages, and
 at the same time RB1 uses RBvi's pseudo-nickname in its TRILL Data
 packets.

11. Configuration Consistency

 The VLAN membership of all the RBridge ports in an LAALP MUST be the
 same.  Any inconsistencies in VLAN membership may result in packet
 loss or non-shortest paths.
 Take Figure 1 as an example.  Suppose that RB1 configures VLAN1 and
 VLAN2 for the CE1-RB1 link, while RB2 only configures VLAN1 for the
 CE1-RB2 link.  Both RB1 and RB2 use the same ingress nickname RBv for
 all frames originating from CE1.  Hence, a remote RBridge (say RBx)
 will learn that CE1's MAC address in VLAN2 is originating from the
 RBv.  As a result, on the return path, RBx may deliver VLAN2 traffic
 to RB2.  However, RB2 does not have VLAN2 configured on the CE1-RB2
 link, and hence the frame may be dropped or has to be redirected to
 RB1 if RB2 knows that RB1 can reach CE1 in VLAN2.

Zhai, et al. Standards Track [Page 29] RFC 7781 Pseudo-Nickname February 2016

 How LAALP implementations maintain consistent VLAN configuration on
 the TRILL switch LAALP ports is out of scope for the TRILL protocol.
 However, considering the consequences that might be caused by
 inconsistencies, TRILL switches MUST disable the ports connected to
 an LAALP with an inconsistent VLAN configuration.
 It is important that if any VLAN in an LAALP is being mapped by edge
 RBridges to an FGL [RFC7172] the mapping MUST be the same for all
 edge RBridge ports in the LAALP.  Otherwise, for example, unicast FGL
 TRILL Data packets from remote RBridges may get mapped into different
 VLANs, depending on which edge RBridge receives and egresses them.
 It is important that RBridges in an AAE group not be configured to
 assert the OE-flag if any RBridge in the group does not implement it.
 Since, as stated in [RFC7379], the RBridges in an AAE edge group are
 expected to be from the same vendor, due to the proprietary nature of
 deployed LAALPs, this will normally follow automatically from all of
 the RBridges in an AAE edge group supporting, or not supporting, OE.

12. Security Considerations

 Authenticity for contents transported in IS-IS PDUs is enforced using
 regular IS-IS security mechanisms [IS-IS] [RFC5310].
 For security considerations pertaining to extensions transported by
 TRILL ESADI, see the Security Considerations section in [RFC7357].
 Since currently deployed LAALPs [RFC7379] are proprietary, security
 over membership in, and internal management of, active-active edge
 groups is proprietary.  If authentication is not used, a rogue
 RBridge that insinuates itself into an active-active edge group can
 disrupt end-station traffic flowing into or out of that group.  For
 example, if there are N RBridges in the group, it could typically
 control 1/Nth of the traffic flowing out of that group and a
 similar amount of unicast traffic flowing into that group.  For
 multi-destination traffic flowing into that group, it could control
 all that was in a VLAN for which it was the DF and can exercise
 substantial control over the DF election by changing its own
 System ID.
 For general TRILL security considerations, see [RFC6325].

Zhai, et al. Standards Track [Page 30] RFC 7781 Pseudo-Nickname February 2016

13. IANA Considerations

 IANA has allocated four code points from the range below 255 for the
 four TRILL APPsub-TLVs specified in Section 9 and added them to the
 "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
 registry, as follows:
         Type  Name                        Reference
         ----  --------------------------  ---------
           2   PN-LAALP-Membership         RFC 7781
           3   PN-RBv                      RFC 7781
           4   PN-MAC-RI-LAALP-INFO-START  RFC 7781
           5   PN-MAC-RI-LAALP-INFO-END    RFC 7781

14. References

14.1. Normative 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.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
            and M. Fanto, "IS-IS Generic Cryptographic
            Authentication", RFC 5310, DOI 10.17487/RFC5310,
            February 2009, <http://www.rfc-editor.org/info/rfc5310>.
 [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
            Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
            <http://www.rfc-editor.org/info/rfc6165>.
 [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
            (SHA and SHA-based HMAC and HKDF)", RFC 6234,
            DOI 10.17487/RFC6234, May 2011,
            <http://www.rfc-editor.org/info/rfc6234>.
 [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
            Ghanwani, "Routing Bridges (RBridges): Base Protocol
            Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
            <http://www.rfc-editor.org/info/rfc6325>.

Zhai, et al. Standards Track [Page 31] RFC 7781 Pseudo-Nickname February 2016

 [RFC6439]  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
            Hu, "Routing Bridges (RBridges): Appointed Forwarders",
            RFC 6439, DOI 10.17487/RFC6439, November 2011,
            <http://www.rfc-editor.org/info/rfc6439>.
 [RFC7172]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
            D. Dutt, "Transparent Interconnection of Lots of Links
            (TRILL): Fine-Grained Labeling", RFC 7172,
            DOI 10.17487/RFC7172, May 2014,
            <http://www.rfc-editor.org/info/rfc7172>.
 [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
            D., and A. Banerjee, "Transparent Interconnection of Lots
            of Links (TRILL) Use of IS-IS", RFC 7176,
            DOI 10.17487/RFC7176, May 2014,
            <http://www.rfc-editor.org/info/rfc7176>.
 [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
            Scope Link State PDUs (LSPs)", RFC 7356,
            DOI 10.17487/RFC7356, September 2014,
            <http://www.rfc-editor.org/info/rfc7356>.
 [RFC7357]  Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
            Stokes, "Transparent Interconnection of Lots of Links
            (TRILL): End Station Address Distribution Information
            (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
            September 2014, <http://www.rfc-editor.org/info/rfc7357>.
 [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
            Ghanwani, A., and S. Gupta, "Transparent Interconnection
            of Lots of Links (TRILL): Clarifications, Corrections, and
            Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
            <http://www.rfc-editor.org/info/rfc7780>.
 [RFC7783]  Senevirathne, T., Pathangi, J., and J. Hudson,
            "Coordinated Multicast Trees (CMT) for Transparent
            Interconnection of Lots of Links (TRILL)", RFC 7783,
            DOI 10.17487/RFC7783, February 2016,
            <http://www.rfc-editor.org/info/rfc7783>.

Zhai, et al. Standards Track [Page 32] RFC 7781 Pseudo-Nickname February 2016

14.2. Informative References

 [IS-IS]    International Organization for Standardization,
            "Information technology -- Telecommunications and
            information exchange between systems -- Intermediate
            System to Intermediate System intra-domain routeing
            information exchange protocol for use in conjunction with
            the protocol for providing the connectionless-mode network
            service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
            November 2002.
 [RFC7174]  Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
            3rd, "Transparent Interconnection of Lots of Links (TRILL)
            Operations, Administration, and Maintenance (OAM)
            Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014,
            <http://www.rfc-editor.org/info/rfc7174>.
 [RFC7379]  Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
            "Problem Statement and Goals for Active-Active Connection
            at the Transparent Interconnection of Lots of Links
            (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379,
            October 2014, <http://www.rfc-editor.org/info/rfc7379>.
 [RFC7782]  Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S.
            Gupta, "Transparent Interconnection of Lots of Links
            (TRILL) Active-Active Edge Using Multiple MAC
            Attachments", RFC 7782, DOI 10.17487/RFC7782,
            February 2016, <http://www.rfc-editor.org/info/rfc7782>.

Zhai, et al. Standards Track [Page 33] RFC 7781 Pseudo-Nickname February 2016

Acknowledgments

 We would like to thank Mingjiang Chen for his contributions to this
 document.  Additionally, we would like to thank Erik Nordmark, Les
 Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan
 Pathangi, Jon Hudson, and Fangwei Hu for their good questions and
 comments.

Contributors

 Weiguo Hao
 Huawei Technologies
 101 Software Avenue
 Nanjing  210012
 China
 Phone: +86-25-56623144
 Email: haoweiguo@huawei.com
 Donald E. Eastlake 3rd
 Huawei Technologies
 155 Beaver Street
 Milford, MA  01757
 United States
 Phone: +1-508-333-2270
 Email: d3e3e3@gmail.com

Zhai, et al. Standards Track [Page 34] RFC 7781 Pseudo-Nickname February 2016

Authors' Addresses

 Hongjun Zhai
 Jinling Institute of Technology
 99 Hongjing Avenue, Jiangning District
 Nanjing, Jiangsu  211169
 China
 Email: honjun.zhai@tom.com
 Tissa Senevirathne
 Consultant
 Email: tsenevir@gmail.com
 Radia Perlman
 EMC
 2010 256th Avenue NE, #200
 Bellevue, WA  98007
 United States
 Email: Radia@alum.mit.edu
 Mingui Zhang
 Huawei Technologies
 No. 156 Beiqing Rd., Haidian District
 Beijing  100095
 China
 Email: zhangmingui@huawei.com
 Yizhou Li
 Huawei Technologies
 101 Software Avenue
 Nanjing  210012
 China
 Phone: +86-25-56625409
 Email: liyizhou@huawei.com

Zhai, et al. Standards Track [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7781.txt · Last modified: 2016/02/25 23:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki