GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8397

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:
  1. S transmits an Ethernet frame with source MAC = S and destination

MAC = D.

  1. RB27 encapsulates with a TRILL header with ingress RBridge

nickname 27, and egress RBridge nickname 44 producing a TRILL Data

    packet.
  1. 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.
  1. The packet is forwarded through Level 2, from RB2 to RB3, which

has advertised, in Level 2, it owns the nickname 44.

  1. RB3, when forwarding into Area Y, does not change the ingress

nickname 27 or the egress nickname 44.

  1. 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:
  1. 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.
  1. RB2, when flooding the packet in Level 2, uses the segment of the

global distribution tree that resides in Level 2.

  1. RB3, when flooding the packet into Area Y, uses the segment of the

global distribution tree that resides in Area Y.

  1. 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:
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8397.txt · Last modified: 2018/05/31 23:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki