doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8397.txt b/doc/rfc/rfc8397.txt
new file mode 100644
index 0000000..11503f9
--- /dev/null
+++ b/doc/rfc/rfc8397.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Zhang
+Request for Comments: 8397                               D. Eastlake 3rd
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                               R. Perlman
+                                                                Dell EMC
+                                                                 H. Zhai
+                                                                     JIT
+                                                                  D. Liu
+                                                  China Telecom Co., Ltd
+                                                                May 2018
+
+
+    Transparent Interconnection of Lots of Links (TRILL) Multilevel
+                         Using Unique Nicknames
+
+Abstract
+
+   TRILL (Transparent Interconnection of Lots of Links) 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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8397.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 1]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+Copyright Notice
+
+   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
+   (https://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 ....................................................3
+   2. Acronyms and Terminology ........................................4
+   3. Data Routing ....................................................4
+      3.1. Unicast Routing ............................................4
+      3.2. Multi-destination Routing ..................................5
+           3.2.1. Local Distribution Trees ............................6
+           3.2.2. Global Distribution Trees ...........................6
+   4. Protocol Basics and Extensions ..................................8
+      4.1. Multilevel TRILL Basics ....................................8
+      4.2. Nickname Allocation ........................................9
+      4.3. Nickname Announcements .....................................9
+      4.4. Capability Indication .....................................11
+   5. Mix with Aggregated Nickname Areas .............................11
+   6. Security Considerations ........................................12
+   7. IANA Considerations ............................................13
+   8. References .....................................................13
+      8.1. Normative References ......................................13
+      8.2. Informative References ....................................14
+   Contributors ......................................................15
+   Authors' Addresses ................................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 2]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+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
+   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 TRILL switches at the Level 1 / Level 2 border
+   advertise into the Level 1 area those nicknames are not available for
+   assignment in that area and advertising into the Level 2 area those
+   nicknames that are used by the Level 1 area so that other areas
+   cannot use them anymore.  The advertising of Level 1 nicknames
+   informs the rest of the campus how to reach the nicknames residing in
+   that area.  In this 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.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 3]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+2.  Acronyms and Terminology
+
+   Border RBridge: An RBridge that is located on the border between two
+      or more RBridge areas.
+
+   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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+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 1: An Example Topology for TRILL Multilevel
+
+   Figure 1 is adapted from the example topology of [RFC8243], where S
+   is Source, and D is Destination.
+
+   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.
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 4]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   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.
+
+   -  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 a 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.)
+
+
+
+Zhang, et al.                Standards Track                    [Page 5]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   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 Section 4.5 of [RFC6325].  The sole 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
+   RBridge nicknames 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 advertise 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 sets 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 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.  Figures 2 through 5 illustrate how different RBridges view the
+   global distribution tree.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 6]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+                                RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
+                                 o
+                                /
+                            Rz o
+                              /
+                          Rx o
+                            /
+                      RB27 o
+
+           Figure 2: RB27's View of the Global Distribution Tree
+
+                                RB3,Rk,RB44
+                                 o
+                                /
+                            Re o
+                              /
+                          Rd o
+                            /
+                        Rc o
+                          /
+                      Rb o
+                        /
+                   RB2 o
+                      /
+                  Rz o
+                    /
+                Rx o
+                  /
+            RB27 o
+
+           Figure 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 4: RB3's View of the Global Distribution Tree
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 7]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+                                RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re
+                                 o
+                                  \
+                                   o Rk
+                                    \
+                                     o RB44
+
+           Figure 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:
+
+   -  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 [RFC7356] [RFC7780]).  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].
+
+
+
+Zhang, et al.                Standards Track                    [Page 8]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   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 the 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
+   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 boundaries of
+   multiples of 64 are RECOMMENDED in this document.
+
+   The nickname contention in Level 2 will determine 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 or 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
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 9]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   APPsub-TLV to advertise into the Level 1 area the inclusive range of
+   nicknames that are or are not available for self allocation by the
+   Level 1 RBridges in that area.  Its structure is as follows:
+
+               0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |     Type = 24                                 |
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |     Length                                    |
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |OK|                RESV                        |
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |     Nickname Block 1                          |
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |  ...
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |     Nickname Block K                          |
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+      o  Type: 24 (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
+           of 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.
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 10]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+      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:
+
+             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+             |     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 RBridge 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 outside the scope of this document.
+
+   As specified in Section 4.2.6 of [RFC6325], multiple border RBridges
+   may claim the same nicknames outwardly and/or inwardly.  Other
+   RBridges add those nicknames as if they are attached to all of those
+   border RBridges.
+
+4.4.  Capability Indication
+
+   All border RBridges 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
+   configured 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 planned so that nicknames used in any
+   one unique nickname area and Level 2 are never used in any other
+   areas, including unique nickname areas as well as aggregated nickname
+
+
+
+Zhang, et al.                Standards Track                   [Page 11]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   areas.  In other words, nickname reusage 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 a unique nickname border
+   RBridge.  However, 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 fact 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 were originally sent to 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].
+
+
+
+Zhang, et al.                Standards Track                   [Page 12]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+7.  IANA Considerations
+
+   IANA has registered a new flag bit under the "TRILL-VER Sub-TLV
+   Capability Flags" registry.
+
+         Bit    Description             Reference
+         ---    -----------             ---------
+          5     Able to handle the      RFC 8397
+                NickBlockFlags
+                APPsub-TLV
+
+   IANA has assigned 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
+         ----    ------          ---------
+          24     NickBlockFlags  RFC 8397
+
+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,
+              <https://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,
+              <https://www.rfc-editor.org/info/rfc6325>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc7172>.
+
+   [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
+              D., and A. Banerjee, "Transparent Interconnection of Lots
+              of Links (TRILL) Use of IS-IS", RFC 7176,
+              DOI 10.17487/RFC7176, May 2014,
+              <https://www.rfc-editor.org/info/rfc7176>.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 13]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   [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, <https://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
+              (TRILL): Using Data Labels for Tree Selection for Multi-
+              Destination Data", RFC 7968, DOI 10.17487/RFC7968, August
+              2016, <https://www.rfc-editor.org/info/rfc7968>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [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, "Transparent
+              Interconnection of Lots of Links (TRILL) Single Area
+              Border RBridge Nickname for Multilevel", draft-ietf-trill-
+              multilevel-single-nickname-05, Work in Progress, January
+              2018.
+
+   [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, <https://www.rfc-editor.org/info/rfc5310>.
+
+   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
+              Scope Link State PDUs (LSPs)", RFC 7356,
+              DOI 10.17487/RFC7356, September 2014,
+              <https://www.rfc-editor.org/info/rfc7356>.
+
+   [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+              Ghanwani, A., and S. Gupta, "Transparent Interconnection
+              of Lots of Links (TRILL): Clarifications, Corrections, and
+              Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+              <https://www.rfc-editor.org/info/rfc7780>.
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 14]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   [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>.
+
+Contributors
+
+   Margaret Cullen
+   Painless Security
+   14 Summer St. Suite 202
+   Malden, MA  02148
+   United States of America
+
+   Email: margaret@painless-security.com
+
+Authors' Addresses
+
+   Mingui Zhang
+   Huawei Technologies
+   No. 156 Beiqing Rd., Haidian District
+   Beijing  100095
+   China
+
+   Phone: +86-13810702575
+   Email: zhangmingui@huawei.com
+
+
+   Donald Eastlake 3rd
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA  01757
+   United States of America
+
+   Phone: +1-508-333-2270
+   Email: d3e3e3@gmail.com
+
+
+   Radia Perlman
+   Dell EMC
+   176 South Street
+   Hopkinton, MA  01748
+   United States of America
+
+   Email: radia@alum.mit.edu
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 15]
+
+RFC 8397            TRILL Multilevel Unique Nickname            May 2018
+
+
+   Hongjun Zhai
+   Jinling Institute of Technology
+   99 Hongjing Avenue, Jiangning District
+   Nanjing, Jiangsu  211169
+   China
+
+   Email: honjun.zhai@tom.com
+
+
+   Dongxin Liu
+   China Telecom Co., Ltd
+   109 West Zhongshan Ave, Tianhe District
+   Guangzhou  510630
+   China
+
+   Email: liudx@gsta.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 16]
+