summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7781.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7781.txt')
-rw-r--r--doc/rfc/rfc7781.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc7781.txt b/doc/rfc/rfc7781.txt
new file mode 100644
index 0000000..4ec96c0
--- /dev/null
+++ b/doc/rfc/rfc7781.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+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
+
+
+ ----------------------
+ | |
+ | 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.
+
+ ------------------------
+ / \
+ | 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.
+
+ ---------------------
+ / \ +-----+
+ | 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:
+
+ - If the outgoing port(s) is associated with the same
+ pseudo-nickname as that of the incoming port but not with the
+ same LAALP as the incoming port, the copies are forwarded out of
+ that outgoing port(s) after passing the Appointed Forwarder
+ check for the frame's VLAN. That is to say, the copies are
+ processed on such port(s), as discussed in Section 4.6.1.2 of
+ [RFC6325].
+
+ - Else, the Designated Forwarder (DF) check is also made on the
+ outgoing ports for the frame's VLAN after the Appointed
+ Forwarder check, and the copies are not output through any ports
+ that failed the DF check (i.e., RB1 is not the DF for the
+ frame's VLAN on 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.
+
+ ------------------
+ / \
+ | 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]
+