Internet DRAFT - draft-ietf-trill-multilevel-unique-nickname
draft-ietf-trill-multilevel-unique-nickname
TRILL Working Group M. Zhang
Internet Draft D. Eastlake 3rd
Intended Category: Proposed Standard Huawei
R. Perlman
Dell EMC
H. Zhai
JIT
D. Liu
China Telcom Co., Ltd
Expires: September 15, 2018 March 14, 2018
TRILL Multilevel Using Unique Nicknames
draft-ietf-trill-multilevel-unique-nickname-07.txt
Abstract
TRILL routing can be extended to support multiple levels by building
on the multilevel feature of IS-IS routing. Depending on how
nicknames are managed, there are two primary alternatives to realize
TRILL multilevel: the unique nickname approach and the aggregated
nickname approach as discussed in RFC 8243. This document specifies a
unique nickname approach. This approach gives unique nicknames to all
TRILL switches across the multilevel TRILL campus.
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 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 of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Mingui Zhang, et al Expires September 15, 2018 [Page 1]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
Copyright (c) 2018 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
3. Data Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Unicast Routing . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Multi-destination Routing . . . . . . . . . . . . . . . . . 5
3.2.1. Local Distribution Trees . . . . . . . . . . . . . . . 5
3.2.2. Global Distribution Trees . . . . . . . . . . . . . . . 5
4. Protocol Basics and Extensions . . . . . . . . . . . . . . . . 8
4.1. Multilevel TRILL Basics . . . . . . . . . . . . . . . . . . 8
4.2. Nickname Allocation . . . . . . . . . . . . . . . . . . . . 8
4.3. Nickname Announcements . . . . . . . . . . . . . . . . . . 9
4.4. Capability Indication . . . . . . . . . . . . . . . . . . . 11
5. Mix with Aggregated nickname Areas . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The multiple level feature of [IS-IS] can increase the scalability of
TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs some
extensions to support the TRILL multilevel feature. The two most
significant extensions are how TRILL switch nicknames are managed and
how distribution trees are handled [RFC8243].
There are two primary alternatives to realize TRILL multilevel
[RFC8243]. One approach, which is referred to as the "aggregated
Mingui Zhang, et al Expires September 15, 2018 [Page 2]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
nickname" approach, involves assigning nicknames to the areas, and
allowing nicknames to be reused in different areas, by having the
border TRILL switches rewrite nickname fields when entering or
leaving an area. For more description of the aggregated nickname
approach, one can refer to [RFC8243] and [SingleN]. The other
approach, which is referred to as the "unique nickname" approach, is
specified in this document. The unique nickname approach gives unique
nicknames to all the TRILL switches in the multilevel campus, by
having the Level-1/Level-2 border TRILL switches advertise into the
Level 1 area which nicknames are not available for assignment in the
area, and insert into Level 2 area which nicknames are used by this
area so that other areas cannot use them anymore, as well as
informing the rest of the campus how to reach the nicknames residing
in this area. In the document, protocol extensions that support such
advertisement are specified.
Each RBridge in a unique nickname area calculates two types of trees:
local distribution trees and global distributions trees. For multi-
destination traffic that is limited to an area, the packets will be
flooded on a local distribution tree. Otherwise, the multi-
destination packets will be flooded along a global distribution
tree.
In the unique nickname approach, nicknames are globally valid so that
border RBridges do not rewrite the nickname field of TRILL data
packets that transition between Level 1 and Level 2, as border
RBridges do in the aggregated nickname approach. If a border RBridge
is a transit node on a forwarding path, it does not learn MAC
addresses of the TRILL data packets forwarded along this path.
Testing and maintenance operations that originate in one area and
terminate in a different area are also simplified [RFC8243]. For
these reasons, the unique nickname approach might realize simpler
border RBridges than the aggregated nickname approach. However, the
unique nickname approach is less scalable and may be less well suited
for very large campuses.
2. Acronyms and Terminology
Data Label: VLAN or FGL [RFC7172]
IS-IS: Intermediate System to Intermediate System [IS-IS]
RBridge: A device implementing the TRILL protocol.
TRILL: TRansparent Interconnection of Lots of Links or Tunneled
Routing in the Link Layer [RFC6325].
TRILL switch: An alternative name for an RBridge.
Mingui Zhang, et al Expires September 15, 2018 [Page 3]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
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].
3. Data Routing
Area X level 2 Area Y
+-----------------+ +---------------------+ +------------+
| | | | | |
S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D
| 27 | | | | 44 |
| | | | | |
+-----------------+ +---------------------+ +------------+
Figure 3.1: An example topology for TRILL multilevel
Figure 3.1 is adapted from the example topology of [RFC8243].
The routing processes are described in the following two subsections.
3.1. Unicast Routing
The plain RBridge RB27 has a different view of the topology of the
TRILL campus than its border RBridge RB2. For an outward path that
reaches an RBridge not in the same area (say RB44), RB27 calculates
the segment of the path in Area X, the border RBridge RB2 calculates
the segment in Level 2, while the border RBridge to the destination
area, RBridge RB3, calculates the segment from itself to RB44.
Let us say that S transmits a frame to destination D and let us say
that D's location is learned by the relevant TRILL switches already.
These relevant switches have learned the following:
1) RB27 has learned that D is connected to nickname 44.
2) RB2 has learned that nickname 44 is accessible through RB3.
The following sequence of events will occur:
- S transmits an Ethernet frame with source MAC = S and destination
MAC = D.
- RB27 encapsulates with a TRILL header with ingress RBridge
nickname 27, and egress RBridge nickname 44 producing a TRILL Data
packet.
- RB2 has announced in the Level 1 IS-IS instance in Area X, that it
owns all nicknames of other areas, including 44. Therefore, IS-IS
routes the packet to RB2.
Mingui Zhang, et al Expires September 15, 2018 [Page 4]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
- The packet is forwarded through Level 2, from RB2 to RB3, which
has advertised, in Level 2, it owns the nickname 44.
- RB3, when forwarding into Area Y, does not change the ingress
nickname 27 or the egress nickname 44.
- RB44, when decapsulating, learns that S is attached to nickname
27.
3.2. Multi-destination Routing
The scope of Multi-destination routing is defined by the tree root
nickname. A tree with a Level 2 tree root nickname is global and a
tree with Level 1 tree root nickname is local. See Section 4.2 for
the Level 1 and Level 2 nickname allocation.
Border RBridges announce the global trees to be calculated only for
those Data Labels that span across areas. APPsub-TLVs as specified in
Section 3.2 of [RFC7968] will be advertised for this purpose. Based
on the Data Label, an ingress RBridge can determine whether a global
tree or a local tree is to be used for a TRILL multi-destination Data
packet.
If there are legacy TRILL switches that do not understand the APPsub-
TLVs for tree selection, configuration MUST guarantee that Data
Labels [RFC7172] being used globally in Level 2 are disabled on these
legacy TRILL switches (Otherwise, the legacy TRILL switches might use
local trees for multi-destination traffic with a global scope.).
These legacy TRILL switches may use global trees to flood multi-
destination packets with a scope of the local area. Those global
trees MUST be pruned at the border TRILL switches based on Data
Labels.
3.2.1. Local Distribution Trees
The root RBridge RB1 of a local distribution tree resides in the
area. RBridges in this area calculate this local tree based on the
link state information of this area, using RB1's nickname as the
root. Protocol behaviors for local distribution trees have been
specified in 4.5 of [RFC6325]. The only difference is that the local
distribution tree spans this area only. A multi-destination packet
with an egress nickname of the root RBridge of a local tree MUST NOT
be leaked into Level 2 at the border RBridge.
3.2.2. Global Distribution Trees
Within Level 2, the RBridge with the highest tree root priority
advertises the set of global trees by providing a list of Level 2
Mingui Zhang, et al Expires September 15, 2018 [Page 5]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
RBridge nicknames just as defined in Section 4.5 of [RFC6325].
According to [RFC6325], the RBridge with the highest root priority
advertises the tree roots for a Level 1 area. There has to be a
border RBridge with the highest root tree priority in each area so
that it can advertises the global tree root nicknames into the area.
Also, this border RBridge MUST advertise the set of local
distribution trees by providing another set of nicknames. Since
nicknames of global tree roots and local tree roots indicate
different flooding scopes, these two set MUST NOT overlap. If a
border RBridge has been assigned both as a global tree root and a
local tree root, it MUST acquire both a global tree root nickname(s)
and local tree root nickname(s). However, non-border RBridges in an
area do not differentiate between a global tree root nickname and a
local tree root nickname.
Suppose RB3 is the RBridge with the highest tree root priority within
Level 2, and RB2 is the highest tree root priority in Area X. RB2
advertises in Area X that nickname RB3 is the root of a distribution
tree. Figure 3.2 through Figure 3.5 illustrate how different RBridges
view the global distribution tree.
RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
o
/
Rz o
/
Rx o
/
RB27 o
Figure 3.2: RB27's view of the global distribution tree
Mingui Zhang, et al Expires September 15, 2018 [Page 6]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
RB3,Rk,RB44
o
/
Re o
/
Rd o
/
Rc o
/
Rb o
/
RB2 o
/
Rz o
/
Rx o
/
RB27 o
Figure 3.3: RB2's view of the global distribution tree
RB3
o
/ \
Re o o Rk
/ \
Rd o o RB44
/
Rc o
/
Rb o
/
R27,Rx,Rz,RB2 o
Figure 3.4: RB3's view of the global distribution tree
RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re
o
\
o Rk
\
o RB44
Figure 3.5: RB44's view of the global distribution tree
The following sequence of events will occur when a multi-destination
TRILL Data packet is forwarded using the global distribution tree:
Mingui Zhang, et al Expires September 15, 2018 [Page 7]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
- RB27 produces a multi-destination (M bit is one) TRILL Data packet
with ingress RBridge nickname 27 and egress RBridge nickname 3.
RB27 floods this packet using the segment of the global
distribution tree that resides in Area X.
- RB2, when flooding the packet in Level 2, uses the segment of the
global distribution tree that resides in Level 2.
- RB3, when flooding the packet into Area Y, uses the segment of the
global distribution tree that resides in Area Y.
- The multicast listener RB44, when decapsulating the received
packet, learns that S is attached to nickname 27.
4. Protocol Basics and Extensions
4.1. Multilevel TRILL Basics
Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border
RBridges are in both a Level 1 area and in Level 2. They establish
adjacency with Level 1 RBridges as specified in [RFC7177] and
[RFC6325]. They establish adjacency with Level 2 RBridges in exactly
the same way except that (1) for a LAN link the IS-IS Hellos used are
Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link the
Level is configured and indicated in flags in the point-to-point
Hello. The state machines for Level 1 and Level 2 adjacency are
independent and two RBridges on the same LAN link can have any
adjacency state for Level 1 and, separately, any adjacency state for
Level 2. Level 1 and Level 2 link state flooding are independent
using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP,
CSNP, PSNP, FS-LSP, FS-CSNP and FS-PSNP). Thus Level 1 link state
information stays within a Level 1 area and Level 2 link state
information stays in Level 2 unless there are specific provisions for
leaking (copying) information between levels. This is why multilevel
can address the TRILL scalability issues as specified in Section 2 of
[RFC8243].
The former "campus wide" minimum acceptable link size Sz is
calculated as before by Level 1 RBridges (including border RBridges)
using the originatingLSPBufferSize advertised in Level 1 LSP so it is
area local in multilevel TRILL. A minimum acceptable link size in
Level 2, called Sz2, is calculated by the RBridges participating in
Level 2 in the same way as Sz is calculated but using the
originatingLSPBufferSize distributed in Level 2 LSPs.
4.2. Nickname Allocation
Level 2 RBridges contend for nicknames in the range from 0xF000
Mingui Zhang, et al Expires September 15, 2018 [Page 8]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
through 0xFFBF the same way as specified in [RFC6325], using Level 2
LSPs. The highest priority border router for a Level 1 area should
contend with others in Level 2 for blocks of nicknames for the range
from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of 64
boundaries are RECOMMENDED in this document.
The nickname contention in Level 2 will figure out which blocks of
nicknames are available for an area and which blocks of nicknames are
used elsewhere. The NickBlockFlags APPsub-TLV as specified in Section
4.3 will be used by the border RBridge(s) to announce the nickname
availability.
4.3. Nickname Announcements
Border RBridges need to exchange nickname information between Level 1
and Level 2, otherwise forwarding paths inward/outward will not be
calculated. For this purpose, border RBridges need to fabricate
nickname announcements. Sub-TLVs used for such announcements are
specified as follows.
Besides its own nickname(s), a border RBridge MUST announce, in its
area, the ownership of all external nicknames that are reachable from
this border RBridge. These external nicknames include nicknames used
in other unique nickname areas and nicknames in Level 2. Non-border
RBridge nicknames within aggregated nickname areas are excluded.
Also, a border RBridge MUST announce, in Level 2, the ownership of
all nicknames within its area. From listening to these Level 2
announcements, border RBridges can figure out the nicknames used by
other areas.
RBridges in the TRILL base protocol use the Nickname Sub-TLV as
specified in Section 2.3.2 of [RFC7176] to announce the ownership of
nicknames. However, it becomes uneconomic to use this Sub-TLV to
announce a mass of internal/external nicknames. To address this
issue, border RBridges SHOULD make use of the NickBlockFlags APPsub-
TLV to advertise into the Level 1 area the inclusive range of
nicknames that are available or not for self allocation by the Level
1 RBridges in that area. Its structure is as follows:
Mingui Zhang, et al Expires September 15, 2018 [Page 9]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| type = tbd2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|OK| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block K |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: tbd2 (TRILL NickBlockFlags)
o Length: 2 + 4*K where K is the number of nickname blocks.
o OK:
- When this bit is set to 1, the blocks of nicknames in this
APPsub-TLV are associated to the border RBridge's attached
Level 1 area. The APPsub-TLV will be advertised in both Level
1 and Level 2. For nicknames that fall in the ranges or the
nickname blocks, RBridges of Level 2 always route to the
originating border RBridge, just as if this border RBridge
owns these nicknames.
- When this bit is set to 0, it indicates that the nicknames
covered by the nickname blocks are being used in Level 2 or
other areas so that they are not available for use in the
border RBridge's attached Level 1 area. The APPsub-TLV will
be advertised into Level 1 only. For nicknames that fall in
the ranges of the nickname blocks, RBridges of the area
always route to the originating border RBridge, just as if
this border RBridge owns these nicknames. For nicknames in
these ranges, other RBridges will deem that they are owned by
the originating border RBridge. The paths to nicknames that
fall in these ranges will be calculated to reach the
originating border RBridge. TRILL Data packets with egress
nicknames that are neither in these ranges nor announced by
any RBridge in the area MUST be discarded.
o RESV: reserved for future flag allocation. MUST be sent as zero
and ignored on receipt.
o Nickname Block: a starting and ending nickname as follows:
Mingui Zhang, et al Expires September 15, 2018 [Page 10]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| starting nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ending nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] is still
allowed to be used given the above NickBlockFlags APPsub-TLV is being
used.
There might be multiple border RBridges connected to the same area.
Each border RBridges may advertise a subset of the entire
internal/external nickname space in order to realize load balance.
However, optimization of such load balance is an implementation issue
and is out the scope of this document.
As specified in Section 4.2.6 of [RFC6325], multiple border RBridges
may claim the same nicknames outward and/or inward. Other RBridges
add those nicknames as if they are attached to all of those border
RBridges.
4.4. Capability Indication
All border RBridge MUST understand the NickBlockFlags APPsub-TLV. Non
border RBridges in an area should understand the NickBlockFlags
APPsub-TLV. If an RBridge within an area understands the
NickBlockFlags APPsub-TLV, it MUST indicate this capability by
announcing it in its TRILL-VER Sub-TLV. (See Section 7).
If there are RBridges that do not understand the NickBlockFlags
APPsub-TLV, border RBridges of the area MUST also use the traditional
Nickname Sub-TLV [RFC7176] to announce into the area those nicknames
covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose
OK is 0. The available range of nicknames for this area should be
configure on these traditional RBridges.
5. Mix with Aggregated nickname Areas
The design of TRILL multilevel allows a mixture of unique nickname
areas and aggregated nickname areas (see Section 1.2 of [RFC8243]).
Usage of nickname space MUST be planed so that nicknames used in any
one unique nickname area and Level 2 are never used in any other
areas which includes unique nickname areas as well as aggregated
nickname areas. In other words, nickname re-usage is merely allowed
among aggregated nickname areas.
Border RBridges of an aggregated area MUST announce nicknames heard
from Level 2 into their area like just like an unique nickname border
Mingui Zhang, et al Expires September 15, 2018 [Page 11]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
RBridge. But these RBridges do not announce nicknames of their area
into Level 2.
Each border RBridge of the aggregated areas will appear on the global
tree, as specified in Section 4.1, as a single node. The global trees
for unique nickname areas span unique nickname areas and Level 2 but
never reach the inside of aggregated areas.
6. Security Considerations
Since TRILL multilevel uses the existing IS-IS multilevel facilities
[IS-IS], flooding of control traffic for link state information is
automatically confined to a Level 1 area or to Level 2 except (for
limited types of information that can be specifically flagged for
wider flooding). This addresses the TRILL scalability issues as
specified in Section 2 of [RFC8243] and also, except for the wider
flooding case, this confines the scope of the effects of malicious
events that could be communicated through the link state. However,
due to the nature that unique nickname areas share a common nickname
space, border RBridges still have to leak nickname information
between levels. Such leaking means that nickname related events in
one area can affect other areas.
For this purpose, border RBridges need to fabricate the nickname
announcements as specified in Section 4.3. Malicious devices may also
fake the NickBlockFlags APPsub-TLV to announce a range of nicknames.
By doing this, the attacker can attract TRILL data packets that are
originally to reach a bunch of other RBridges. For this reason,
RBridges SHOULD be configured to use the IS-IS Authentication TLV
(10) in the IS-IS PDUs, particularly those containing the
NickBlockFlags APPsub-TLV, so that IS-IS security ([RFC5310]) can be
used to authenticate those PDUs and discard them if they are forged.
If border RBridges do not prune multi-destination distribution tree
traffic in Data Labels that are configured to be area local, then
traffic that should have been contained within an area might be
wrongly delivered to end stations in that Data Label in other areas,
that is, the Data Label would no longer be area local. This would
generally violate security constraints that require traffic to be
delivered only to end stations in that Data Label in a single area.
For general TRILL Security Considerations, see [RFC6325].
7. IANA Considerations
IANA is requested to register a new flag bit under the TRILL-VER Sub-
TLV Capability Flags registry.
Mingui Zhang, et al Expires September 15, 2018 [Page 12]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
Bit Description Reference
--- ----------- ---------
tbd1 Able to handle the [This document]
NickBlockFlags
APPsub-TLV
IANA is requested to assign a new type for the NickBlockFlags APPsub-
TLV from the range available below 256 and add the following entry to
the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application
Identifier 1" registry as follows:
Type Name Reference
---- ------ ---------
tbd2 NickBlockFlags [This document]
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<http://www.rfc-editor.org/info/rfc6325>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, DOI
10.17487/RFC7176, May 2014, <http://www.rfc-
editor.org/info/rfc7176>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, DOI
10.17487/RFC7172, May 2014, <http://www.rfc-
editor.org/info/rfc7172>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7968] Li, Y., Eastlake 3rd, D., Hao, W., Chen, H., and S.
Chatterjee, "Transparent Interconnection of Lots of Links
Mingui Zhang, et al Expires September 15, 2018 [Page 13]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
(TRILL): Using Data Labels for Tree Selection for Multi-
Destination Data", RFC 7968, DOI 10.17487/RFC7968, August
2016, <http://www.rfc-editor.org/info/rfc7968>.
[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.
8.2. Informative References
[SingleN] Zhang, M., Eastlake, D., et al, "Single Area Border RBridge
Nickname for TRILL Multilevel", draft-ietf-trill-
multilevel-single-nickname, Work in Progress.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication",
RFC 5310, DOI 10.17487/RFC5310, February 2009,
<http://www.rfc-editor.org/info/rfc5310>.
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A.,
and H. Zhai, "Alternatives for Multilevel Transparent
Interconnection of Lots of Links (TRILL)", RFC 8243, DOI
10.17487/RFC8243, September 2017, <https://www.rfc-
editor.org/info/rfc8243>.
9. Contributors
Margaret Cullen
Painless Security
14 Summer St. Suite 202
Malden, MA 02148
United States
Email: margaret@painless-security.com
Mingui Zhang, et al Expires September 15, 2018 [Page 14]
INTERNET-DRAFT TRILL Multilevel Unique Nickname March 14, 2018
Author's Addresses
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd., Haidian District
Beijing 100095
China
Phone: +86-13810702575
Email: zhangmingui@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
Radia Perlman
Dell EMC
176 South Street
Hopkinton, MA 01748
United States
Email: radia@alum.mit.edu
Hongjun Zhai
Jinling Institute of Technology
99 Hongjing Avenue, Jiangning District
Nanjing, Jiangsu 211169
China
Email: honjun.zhai@tom.com
Dongxin Liu
China Telcom Co., Ltd
109 West Zhongshan Ave, Tianhe District
Guangzhou 510630
P.R. China
Email: liudx@gsta.com
Mingui Zhang, et al Expires September 15, 2018 [Page 15]
