wdiff rfc7781.original rfc7781.txt

TRILL Working Group
Internet Engineering Task Force (IETF) H. Zhai
Internet-Draft
Request for Comments: 7781 JIT
Intended Status:
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 Consultant
R. Perlman
EMC
M. Zhang
Y. Li
Huawei Technologies
Expires: March 28,
February 2016 September 25, 2015

TRILL:

Transparent Interconnection of Lots of Links (TRILL):
Pseudo-Nickname for Active-Active Access
draft-ietf-trill-pseudonode-nickname-07.txt

Abstract

The IETF TRILL (TRansparent (Transparent Interconnection of Lots of Links)
protocol provides support for flow level multi-pathing 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 (TRILL (Routing Bridge, or TRILL switch) group providing active-active active-
active access to such an end station are is represented as a Virtual
RBridge. Based on the concept of the Virtual RBridge RBridge, along with its
pseudo-nickname, this document specifies a method for TRILL active-active active-
active access by such end stations.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum
(IETF). It represents the consensus of six months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
time. It the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work available in progress."

The list Section 2 of RFC 5741.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html
http://www.rfc-editor.org/info/rfc7781.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 ....................................................4
1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 5 ...................................6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ........................................................7
3. Virtual RBridge and its Pseudo-nickname . . . . . . . . . . . . 8 Its Pseudo-Nickname .........................9
4. Auto-Discovery of Member RBridges Auto-Discovery . . . . . . . . . . . . . . . . 9 ..............................10
4.1. Discovering Member RBridge for an RBv . . . . . . . . . . . 9 .....................11
4.2. Selection of Pseudo-nickname Pseudo-Nickname for an RBv . . . . . . . . . . . 12 ...................13
5. Distribution Trees and Designated Forwarder . . . . . . . . . . 13 ....................14
5.1. Different Trees for Different Member RBridges . . . . . . . 13 .............15
5.2. Designated Forwarder for Member RBridges . . . . . . . . . 14 ..................16
5.3. Ingress Nickname Filtering . . . . . . . . . . . . . . . . 16 ................................18
6. TRILL Traffic Processing . . . . . . . . . . . . . . . . . . . 17 .......................................19
6.1. Ingressing Native Frames Ingressing . . . . . . . . . . . . . . . . . 17 ..................................19
6.2. Egressing TRILL Data Packets . . . . . . . . . . . . . . . 18 ..............................20
6.2.1. Unicast TRILL Data Packets . . . . . . . . . . . . . . 18 .........................20
6.2.2. Multi-Destination TRILL Data Packets . . . . . . . . . 19 ...............21
7. MAC Information Synchronization in Edge Group . . . . . . . . . 19 ..................22
8. Member Link Failure in an RBv . . . . . . . . . . . . . . . . . . 20 ..................................23
8.1. Link Protection for Unicast Frame Egressing . . . . . . . . 21 ...............24
9. TLV Extensions for Edge RBridge Group . . . . . . . . . . . . . 21 ..........................24
9.1. PN-LAALP-Membership APPsub-TLV . . . . . . . . . . . . . . 22 ............................24
9.2. PN-RBv APPsub-TLV . . . . . . . . . . . . . . . . . . . . . 23 .........................................26
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs . . . . . . . . . . . 24 ......................27
9.4. LAALP IDs . . . . . . . . . . . . . . . . . . . . . . . . . 26 .................................................29
10. OAM Packets . . . . . . . . . . . . . . . . . . . . . . . . . 26 ...................................................29
11. Configuration Consistency . . . . . . . . . . . . . . . . . . 26 .....................................29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 .......................................30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
15. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . . 29
16.2. Informative References . . . . . . . . . . . . . . . . . . 30 Considerations ...........................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................33
Acknowledgments ...................................................34
Contributors ......................................................34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 ................................................35

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 multi-pathing multipathing of both unicast and
multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS]
[RFC7176] link state link-state routing and encapsulating traffic using a header
that includes a hop count. 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 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 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]). (DRNI) [802.1AX]. In this
case, it's it is required that traffic can be ingressed/egressed into/from ingressed into, and egressed
from, the TRILL campus by any of the RBridges for each given VLAN.
These RBridges constitutes constitute an Active-Active Edge (AAE) RBridge group.

With an LAALP, traffic with the same VLAN and source MAC 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 Data packets ingressed by different RBridges, it
learns different VLAN correspondences between a {Data Label and
MAC
address to address} and nickname correspondences continuously when decapsulating the packets
if it has data plane data-plane address learning enabled. This issue is known
as the "MAC flip-flopping" issue, which address flip-flopping"; it makes most TRILL switches behave
badly and causes the returning traffic to reach the destination via
different paths paths, resulting in persistent re-ordering reordering of the frames.
In addition to this issue, other issues issues, such as duplicate egressing
and loop back loopback of multi-destination frames 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, pseudo-nickname instead of its own nickname, nickname as
the ingress RBridge nickname when ingressing frames received on
attached LAALP links. Other methods are possible: for example example, the
specification in this document and the specification in [MultiAttach] [RFC7782]
could be simultaneously deployed for different AAE groups in the same
campus. If the method is [MultiAttach] 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 [MultiAttach]. [RFC7782]. If the
method defined in this document is adopted, all TRILL switches need
to support the Affinity sub-TLV defined in [RFC7176] and [CMT]. [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, etc., can be
reduced.

The main body of this document is organized as follows:

o Section 2
gives 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 gives 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
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; and RBridge.

o Section 9 gives lists the necessary TRILL code points and data
structures for a pseudo-nickname AAE RBridge group.

1.1. Terminology and Acronyms

This document uses the acronyms and terms defined in [RFC6325] and
[RFC7379] and
[RFC7379], as well as the following additional acronyms:

AAE -

AAE: Active-active Edge RBridge group, a group. A group of edge RBridges to
which at least one CE Customer Equipment (CE) node is multiply
attached with an LAALP. AAE is also referred to as edge group "edge group"
or Virtual RBridge "Virtual RBridge" in this document.

Campus -

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 -

CE: Customer Equipment (end station or bridge). The device can be
either physical or virtual equipment.

Data Label - Label: VLAN or FGL.

DF - 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 from 1 to 3 (a) one,
two, or three CEs and 2 (b) two or 3 three RBridges.

E-L1FS -

E-L1FS: Extended Level 1 Flooding Scope [RFC7356].

FGL -

ESADI: End-Station Address Distribution Information.

FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained
Label [RFC7172].

LAALP -

LAALP: Local Active-Active Link Protocol [RFC7379] such as [RFC7379], e.g., MC-LAG
or DRNI.

MC-LAG: Multi-Chassis LAG. Link Aggregation. Proprietary extensions of
Link Aggregation [802.1AX] that can provide an LAALP between one
CE and 2 two or more RBridges.

OE flag -

OE-flag: A flag used by the a member RBridge of an a given LAALP to tell
other edge RBridges of this LAALP whether it this LAALP is willing to
share an RBv with other LAALPs
if they that multiply attach to the same
set of edge RBridges as it. 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).

RBv - virtual RBridge, an

RBv: Virtual RBridge. An alias for active-active "active-active edge RBridge group
group" in this document.

vDRB -

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 "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. Then RB1, RB2, ... RBk then constitute an Active-active Edge (AAE) 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].

----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
+-----+ | +--------+
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1-->(| | |) (| | |) <--LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
+-------+ +-------+

Figure 1 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 So,
every member RBridge of LAALP1 thinks of itself as appointed
forwarder 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 data-plane address learning
enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in
turn cause packet re-ordering reordering in reverse traffic.

Edge RBridges learn Data correspondences between a {Data Label and MAC address to
address} and nickname
correspondences by default via when decapsulating TRILL data Data
packets (see Section 4.8.1 of [RFC6325] [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 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 exactly, precisely,
it represents a group of ports on the edge RBridges providing end
station
end-station service and the service provided to the CE(s) on these
ports, through which the CE(s) are is multiply attached to the TRILL
campus using LAALP(s). Such end station 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 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 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, re-configuration, reconfiguration,
etc. Then 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 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
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, pseudo-node 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 traffic, and its pseudo-
nickname
pseudo-nickname is ignored when determining the distribution tree
root for the TRILL campus [CMT]. So [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 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 exact same set of edge
RBridges via LAALPs, those edge RBridges should be considered as a
single RBv with a single pseudo-nickname.

4. Auto-Discovery of Member RBridges Auto-Discovery

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 of such edge RBridges, 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][rfc7180bis]. [RFC7356] [RFC7780]. Based on the LAALP IDs
advertised by other RBridges, each RBridge can know which edge
RBridges could constitute an AAE group (See (see Section 4.1 for more
details). Then one One RBridge is then elected from the group to allocate an
available nickname (the pseudo-nickname) for the group (See (see
Section 4.2 for more details).

4.1. Discovering Member RBridge for an RBv

Take Figure 2 as an example, where CE1 and CE2 multiply attach to
RB1, RB2 RB2, and RB3 via LAALP1 and LAALP2 LAALP2, respectively; CE3 and CE4
attach to RB3 RB3, and RB4 via LAALP3 and LAALP4 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 2: Different LAALPs to TRILL Campus

RB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership
sub-TLV
APPsub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS
LSPs
FS-LSPs, respectively; RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4};
LAALP4}, and RB4 announces {LAALP3, LAALP4}, respectively.

An edge RBridge is called an LAALP "LAALP related RBridge RBridge" if it has at
least one LAALP configured on an access port. On receipt of the PN-LAALP-
Membership sub-TLVs,
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 sub-TLVs APPsub-TLVs, to decide which RBv(s) it should
join and which edge RBridges constitute each of such RBvs. RBv. Based on the
information received, each of the 4 four RBridges knows the following information: 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

where the OE-flag indicates whether an a given LAALP is willing to share
an RBv with other LAALPs if they that multiply attach to exact the same set of edge
RBridges as it. the given LAALP does.

For an LAALP (for example example, LAALP3), if its OE-
flag 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 bit OE-flag and act as if it was were zero (see
Section 11 on Configuration Consistency). ("Configuration Consistency")).

Otherwise, the LAALP (for example 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 one (value) 1 (see Section 9.1).

In the above table, there might be some LAALPs that attach to a
single RBridge due to mis-configuration misconfiguration or link failure, etc. Those
LAALPs are considered as to be invalid entries. Then each 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 per 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
multi-homed multihomed RBridges. In the case that If several LAALPs have the same number
of RBridges, these LAALPs are then ordered in ascending order
in the proper places of the table table, based on their LAALP IDs
considered as to be unsigned integers. (for (For example, in the above
table, both LAALP1 and LAALP2 have 3 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
(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 that have their whose sets of multi-homed
RBridges contain exactly the same RBridges as that of
LAALP_i LAALP_i,
and take them out of the table. Then Then, appoint RBv_i as the
servicing RBv for those LAALPs.

Step 5: Repeat Step 3-4 Steps 3 and 4 for any LAALPs left left, until all the
valid entries in the table are associated with an RBv.

After performing the above steps, all the 4 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 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
(Designated RBridge)
(referred to in this document as the Designated RBridge of the RBv. Then 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 LSPs FS-LSPs (refer to
Section 9.2 for the relative extended sub-TLVs).

4.2. Selection of Pseudo-nickname 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 to select of selecting a pseudo-nickname for this RBv;
this RBridge is called Designated RBridge of will be the RBv (vDRB) in this
document. vDRB. The winner in the group is the
RBridge with the largest IS-IS System ID considered as to be an unsigned integer, in the group. Then
integer. Then, based on its TRILL IS-IS link state link-state database and the
potential pseudo-nickname(s) reported in the PN-LAALP-Membership sub-TLVs
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
via its E-L1FS FS-LSP(s) (see Section 9.2 and [rfc7180bis]). [RFC7780]). Except as
provided below, the selection of a nickname to use as the
pseudo-nickname follows the usual TRILL rules given in [RFC6325] [RFC6325], as
updated by [rfc7180bis]. [RFC7780].

To reduce the traffic disruption caused by nickname changing, 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 re-using
reusing pseudo-nickname for each of its LAALPs in its LAALP Membership sub-
TLV
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 re-using reusing pseudo-nicknames, the
following is are RECOMMENDED:

o If there are multiple available re-using 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 re-using reusing pseudo-nickname with the smallest value
considered as to be an unsigned integer is chosen.

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

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

Then the

The selected pseudo-nickname is then announced by the vDRB to other
member RBridges of this RBv in the PN-RBv sub-TLV 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
Appointed Forwarder for VLAN x, without changes made for active-
active
active-active connection support, they would all ingress/egress ingress frames into,
and egress frames
into/from from, the TRILL campus for all VLANs. For
multi-destination frames, more than one member RBridges 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 check
on other RBridges; for a multi-
destination multi-destination traffic, more than one RBridges
RBridge egressing it may cause local CE(s) receiving duplication frame. 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, then and another member RBridge will then receive it from
the TRILL campus and egress it to
CEi, which CEi; this will result in loop back loopback
of the frame for CEi. These problems are all described in [RFC7379].

In the following sub-sections, subsections, the first two issues are discussed in
Section
Sections 5.1 and Section 5.2, respectively; the third one 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
multi-destination frames. (Under some circumstances circumstances, they can be unicast
unicast, as specified in [RFC7172].) An RPF Check check, along with other checking
types of checks, is used to avoid temporary multicast loops during
topology changes (Section 4.5.2 of [RFC6325]). The RPF Check check
mechanism only accepts a multi-destination frame ingressed by an
RBridge RBi (say RBi) and forwarded on a distribution tree if it arrives
at another RBridge RBn (say RBn) on the expected port. If arriving 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
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 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 check violation
issue can be fixed. The Coordinated Multicast Trees (CMT) [CMT] document
[RFC7783] proposes such an approach, 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; then all RBridges in the TRILL campus can then calculate RPF Check check
information for RBi on those trees trees, taking the tree affinity
information into account
[CMT]. [RFC7783].

This document uses the approach proposed in [CMT] [RFC7783] to fix the
RPF
Check check violation issue. Please refer to [CMT] [RFC7783] for more
details of the regarding this approach.

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 3: A Topology with Multi-homed Multihomed and Single-homed 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 to, if the packet is
FGL), both RB1 and RB2 will receive it. As each of them thinks it is
the appointed forwarder Appointed Forwarder for VLAN x, without changes made for active-
active
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. Then CE1/CE2 then receives
duplicate copies from RB1 and RB2.

In this document, the Designated Forwarder (DF) for a VLAN is
introduced to avoid the 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 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 which algorithm; this
guarantees that, per VLAN, the same RBridge is elected as the DF per VLAN by
all members of the RBv.

Assuming

If we assume that there are m LAALPs and k member RBridges in an RBv; RBv,
then (1) each LAALP is referred to as LAALPi "LAALPi", where 0 <= i < m, and
(2) each RBridge is referred to as RBj "RBj", where 0 <= j < k, the 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 as to be
an unsigned intger, 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 "LAALP IDi" is the
LAALP ID for LAALPi. The System ID and LAALP ID are considered as
to be byte strings. In the case of a tie, the tied RBridges
are sorted in numerically ascending order by their System IDs
considered as 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 Step Steps 1-3 for the remaining LAALPs until there is a
DF per VLAN per LAALP in the RBv.

For a any multi-destination native frame 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 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 pseudo-nickname 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) to than that
of the incoming port.

For a any multi-destination TRILL Data packet 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 egressing
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,
traffic and egress it back to CE1 if it is the DF for VLAN x on the
port to LAALP1. Then
the The traffic then loops back to CE1 (see Section 3.2
of [RFC7379). [RFC7379]).

To fix the above issue, this document requires an ingress nickname
filtering check is
required by this document. 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 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
passed other checks, such as the appointed forwarder 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; 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 Ingressing

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] [RFC6325], with the following exception. exception:

o If the port is an RBv port, RB1 uses the RBv's pseudo-nickname, 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 (broadcast,
unknown unicast, or Multicast) 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] [RFC6325], with the
following
exceptions. exceptions:

o If the incoming port is an RBv port, RB1 uses the RBv's pseudo-
nickname,
pseudo-nickname instead of one of its regular nickname(s) as the
ingress nickname when doing TRILL encapsulation on the frame.

o For the copies of the frame replicated locally to RBv ports, there
are two cases cases, as follows:

- If the outgoing port(s) is associated with the same pseudo-
nickname
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 Appointed Forwarder
check for the frame's VLAN. That is to say, the copies are
processed on such port(s) 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. The Appointed
Forwarder check, and the copies are not output through the any ports
that failed the DF check (i.e., RB1 is not the DF for the
frame's VLAN on the ports); otherwise, 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 a frame frames received, the MAC address information learned by
observing it, together with the LAALP ID of the incoming port 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 packets, and
Section 6.2.2 specifies the egressing of multi-destination TRILL Data packets egressing.
packets.

6.2.1. Unicast TRILL Data Packets

When receiving a unicast TRILL data Data packet, RBn checks the egress
nickname in the TRILL header 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 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.

Then the

The packet is de-capsulated 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 RBk, (say RBk), it tunnels the native frame to RBk by re-
encapsulating
re-encapsulating it into a unicast TRILL Data packet and sends it
to RBk. RBn uses RBk's regular nickname, nickname instead of the pseudo-
nickname
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 [rfc7180bis]). [RFC7780]). If the hop count 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 as per
Section 4.6.2.4 of [RFC6325], [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 Appointed
Forwarder for the Inner.VLAN (or appointed forwarder 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]
[RFC6325], with the following exception. exception:

o On each RBv port where RBn is the appointed forwarder 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 Designated Forwarder DF check (see Section 5.2) and the Ingress
Nickname Filtering 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.

7. MAC Information Synchronization in Edge Group

An edge RBridge, say RB1 in LAALP1, may have learned a { MAC address,
Data correspondence
between a {Data Label } to and MAC address} and nickname correspondence for a remote host h1
(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. LAALP1 (for example, RB2).
RB2 may not have that correspondence stored. Therefore Therefore, it has to do
the flooding for unknown unicast. Such flooding is unnecessary 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-RI
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
Therefore, it has to flood the traffic out of all its access ports
where it is appointed forwarder 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 unnecessary, since the returning traffic is almost always
expected and RB2 had learned the 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 was 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 is are reachable through the RBv that provides
service to LAALP1, the Topology-id/Nickname Topology-ID/Nickname field of the MAC-RI TLV
SHOULD carry the pseudo-nickname of the RBv RBv, rather than a zero value
or one of the originating RBridge's (i.e., RB2's) regular nicknames.

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 the failure protection in this
scenario.

However, for multi-destination TRILL Data packets, they 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 is 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 Bundle

Figure 4 4: A Topology Multi-Homed CE with Multi-homed and Single-homed CEs a Failed Link

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 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
Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be
tunneled to RB2 after being re-encapsulated (ingress (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). Then RB2 then receives the frame and egresses
it to CE1.

After the 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, 7. It then it restores the MAC entry to its
previous one and downloads it to its data plane fast path 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
[rfc7180bis].
[RFC7780]. It has the following format:

Figure 5 5: PN-LAALP-Membership Advertisement APPsub-TLV
where each LAALP RECORD has the following form:

o PN-LAALP-Membership (2 bytes): Defines the type of this
sub-TLV,
#tbd1. 2.

o Length (2 bytes): the The sum of the lengths of the LAALP RECORDs.

o OE (1 bit): a 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 as
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 Re-using Pseudo-nickname 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
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, it triggers RBn to
perform performs the
"Member RBridges Auto-Discovery" procedure described in Section 4.1. 4.

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-LSP [rfc7180bis]. FS-LSPs [RFC7780]. It has the
following format:

o PN-RBv (2 bytes): Defines the type of this sub-TLV, #tbd2. 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 LLALP LAALP ID Size field below. If
Length is not 3 plus an integer time 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 for 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 in of [802.1AX]). The value in this field is the k
value that appears in the formula for Length above.

o LAALP ID (LAAP (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 with the meaning
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.

Since

Because a PN-RBv APPsub-TLV is distributed as part of the application
link state, state by using the E-L1FS scope [rfc7180bis], FS-LSP [RFC7780], creation, changes in contents to
contents, or withdrawal or creation 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 data-plane fast path logic. At the same time, RBn
claims RBv 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] [CMT]. [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 leant form 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
PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format:

o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this
APPsub-TLV, #tbd3.
sub-TLV, 4.

o Length (2 bytes): the The size of the following LAALP ID. 8 if the
LAALP listed is an MAC-LAG MC-LAG or DRNI.

o LAALP ID (variable): The ID of the LAALP (see Section 9.4).

The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 byte) bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 byte) bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this sub-
TLV, #tbd4.
sub-TLV, 5.

o Length (2 bytes): 0.

This pair of APPsub-TLVs can be carried multiple times in an ESADI
LSP
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 of such LAALPs 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 Topology ID/Nickname the Topology-ID/Nickname field
in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv RBv,
rather than one of the RBn's regular nickname nicknames or zero. Then 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-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. If, after
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, addresses
contained in the following MC-RI TLVs enclosed by the
corresponding pair of boundary APPsub-TLVs, 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.

9.4. LAALP IDs

The LAALP ID identifies an AAE RBridge Group 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 in of [802.1AX]. The
meaning and structure of LAALP IDs of other lengths is are reserved and
may be specified in future documents.

10. OAM Packets

Attention must be paid when generating OAM 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, RBvi. RB1 cannot use RBvi's
pseudo-nickname as the ingress nickname when originating OAM
messages; otherwise 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 RBridge, even though RB1 uses its
regular nicknames as ingress nicknames in its TRILL OAM messages
while 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 for example, suppose as an example. Suppose that RB1 configures VLAN1 and
VLAN2 for the link CE1-RB1, 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 RBx (say RBx)
will learn that CE1's MAC address in VLAN2 is originating from the
RBv. As a result, on the returning return path, remote RBridge RBx may deliver VLAN2 traffic
to RB2. However, RB2 does not have VLAN2 configured on CE1-
RB2 link 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.

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 cause be caused by the
inconsistency,
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], that [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
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 bit 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 RBridge RBridges in an AAE edge group supporting supporting, or all not supporting supporting, OE.

12. Security Considerations

Authenticity for contents transported in IS-IS PDUs is enforced using
regular IS-IS security mechanism mechanisms [IS-IS] [RFC5310].

For security considerations pertain 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 in, and internal management of 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 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 it can exercise
substantial control over the DF election by changing its own
System ID.

For general TRILL Security Considerations, security considerations, see [RFC6325].

13. IANA Considerations

IANA is requested to allocate has allocated four code points tbd1, tbd2, tbd3 and tbd4 from the range below 255 for the 4
four TRILL APPsub-TLVs specified in Section 9 and add added them to the TRILL
"TRILL APPsub-TLV Types registry under IS-IS TLV 251 Application Identifier 1"
registry, as follows:

Type Name Reference
---- -------------------------- ---------------
tbd1 ---------
2 PN-LAALP-Membership [this document]
tbd2 RFC 7781
3 PN-RBv [this document]
tbd3 RFC 7781
4 PN-MAC-RI-LAALP-INFO-START [this document]
tbd4 RFC 7781
5 PN-MAC-RI-LAALP-INFO-END [this document] RFC 7781

14. 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
Pathang, Jon Hudson and Fangwei Hu for their good questions and
comments.

15. Contributing Authors

Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China

Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald E. Eastlake, III
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
Email: d3e3e3@gmail.com

16. References

16.1.

14.1. Normative References

[CMT] T. Senevirathne, J. Pathangi, and J. Hudson, "Coordinated
Multicast Trees (CMT) References

[802.1AX] IEEE, "IEEE Standard for TRILL", draft-ietf-trill-cmt
Work in Progress. Local and metropolitan area
networks - Link Aggregation", IEEE Std 802.1AX-2014,
DOI 10.1109/IEEESTD.2014.7055197, December 2014.

[RFC2119] S. Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC5310] M. Bhatia, V. M., Manral, T. V., Li, et al, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310,
February 2009. 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. 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. 2011,
<http://www.rfc-editor.org/info/rfc6234>.

[RFC6325] R. Perlman, D. Eastlake, D. R., Eastlake 3rd, D., Dutt, S. D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011. 2011,
<http://www.rfc-editor.org/info/rfc6325>.

[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. 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. 2014,
<http://www.rfc-editor.org/info/rfc7172>.

[RFC7176] D. Eastlake, A. Banerjee, A. Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and R. Perlman, A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014. 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.

[RFC7356] Ginsberg, L., Previdi, S., 2014, <http://www.rfc-editor.org/info/rfc7357>.

[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7356, September 2014.

[rfc7180bis] D. Eastlake, et al., draft-ietf-trill-rfc7180bis, work
in progress.

[802.1AX] IEEE, "IEEE Standard for Local 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.

[RFC7783] Senevirathne, T., Pathangi, J., and Metropolitan Area/
networks Link Aggregation", IEEE Std 802.1AX-2014, 24
December 2014.

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

14.2. Informative References

[IS-IS] ISO/IEC 10589:2002, Second Edition, 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. 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.

[MultiAttach] 2014,
<http://www.rfc-editor.org/info/rfc7379>.

[RFC7782] Zhang, M., et al, "TRILL Perlman, R., Zhai, H., Durrani, M., and S.
Gupta, "Transparent Interconnection of Lots of Links
(TRILL) Active-Active Edge Using Multiple MAC
Attachments", draft-ietf-trill-aa-multi-
attach, Work in Progress. RFC 7782, DOI 10.17487/RFC7782,
February 2016, <http://www.rfc-editor.org/info/rfc7782>.

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

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
USA
United States

Email: Radia@alum.mit.edu

Mingui Zhang
Huawei Technologies
Huawei Building, No.156
No. 156 Beiqing Rd.
Beijing, Rd., Haidian District
Beijing 100095
China

Email: zhangmingui@huawei.com

Yizhou Li
Huawei Technologies
101 Software Avenue, Avenue
Nanjing 210012
China

Phone: +86-25-56625409
Email: liyizhou@huawei.com