From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7781.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc7781.txt (limited to 'doc/rfc/rfc7781.txt') 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, + . + + [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, . + + [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 + Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, + . + + [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, + . + + [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, + . + + + + + + +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, + . + + [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, + . + + [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, + . + + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + . + + [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, . + + [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, + . + + [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, + . + + + + + + + + + + + + +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, + . + + [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, . + + [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, . + + + + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3