[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

TRILL Working Group                                  Tissa Senevirathne
Internet Draft                                             Les Ginsberg
Intended status: Standard Track                                   CISCO
                                                   Janardhanan Pathangi
                                                                   DELL
                                                             Jon Hudson
                                                                Brocade
                                                             Sam Aldrin
                                                                 HuaWei
                                                          Ayan Banerjee
                                                                  CISCO
                                                        Sameer Merchant
                                                             Consultant


                                                      February 21, 2012
Expires: August 2012



           Default Nickname Based Approach for Multilevel TRILL
                    draft-tissa-trill-multilevel-00.txt


Status of this Memo

   This Internet-Draft is submitted 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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 21, 2012.





Senevirathne           Expires August 21, 2012                 [Page 1]


Internet-Draft             Multilevel TRILL               February 2012


Copyright Notice

   Copyright (c) 2012 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.

Abstract

   Multilevel TRILL allows the interconnection of multiple TRILL
   networks to form a larger TRILL network without proportionally
   increasing the size of the IS-IS LSP DB. In this document, an
   approach based on default route concept is presented. Also,
   presented in the document is a novel method of constructing multi-
   destination trees using partial nickname space. Methods presented in
   this document are compatible with the RFC6325 specified data plane
   operations.

Table of Contents


   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. Solution Overview..............................................4
   4. Operational Overview...........................................5
      4.1. Unicast Forwarding........................................5
      4.2. IS-IS Protocol changes for unicast forwarding.............5
      4.3. MAC Address Learning......................................6
      4.4. Multicast.................................................6
      4.5. Life of Multicast frame...................................9
   5. Area Affinity sub-TLV.........................................10
   6. Nickname acquisition and conflict resolution..................11
      6.1. Nickname Management sub-TLV..............................13
   7. Further optimizations.........................................14
      7.1. Leaking of TRILL IS-IS sub-TLV within areas..............14
      7.2. Identification of Global Trees...........................15
         7.2.1. Global Tree capability sub-TLV......................17
         7.2.2. Global Tree proposal sub-TLV........................17
         7.2.3. Global Tree Identifier sub-TLV......................18


Senevirathne           Expires August 21, 2012                 [Page 2]


Internet-Draft             Multilevel TRILL               February 2012


      7.3. Announcing Group Addresses...............................18
   8. Architecture Elements of Multi-level Multicast framework......21
      8.1. Bootstrap RBridge........................................21
      8.2. Rendezvous Point (RP)....................................22
      8.3. Default Affinity sub-TLV.................................22
      8.4. Area Affinity sub-TLV....................................22
      8.5. TRILL BSR Protocol.......................................22
   9. Security Considerations.......................................22
   10. IANA Considerations..........................................23
   11. References...................................................23
      11.1. Normative References....................................23
      11.2. Informative References..................................23
   12. Acknowledgments..............................................24

1. Introduction

   The TRILL Base Protocol Specification [RFC6325] provides a method
   for forwarding Layer 2 data frames over multiple active links,
   thereby optimizing network bandwidth and resiliency. TRILL requires
   native Layer 2 frames to be encapsulated with the TRILL header.
   TRILL devices (RBridges) are identified with a 16 bit identifier
   called a nickname. The TRILL header contains egress and ingress
   RBridge nicknames. Intermediate RBridges performs forwarding based
   on the egress nickname. TRILL utilize the IS-IS protocol to
   distribute RBridge nicknames.

   TRILL Base Protocol Specification [RFC6325] specifies a tree based
   paradigm to forward broadcast and multicast traffic as well as
   unknown unicast traffic.

   Traditional Layer 2 devices perform forwarding based on MAC
   addresses. As a result, in theory, all of the devices in the network
   are required to learn all of the MAC addresses in the Layer 2
   domain.  This leads to very large forwarding table sizes in the
   devices which limits the size of the layer 2 domain. Forwarding
   within the TRILL network occurs not based on MAC addresses but based
   on the RBridge nicknames. Hence, TRILL based networks have
   significant potential to be the core forwarding plane of very large
   datacenters.

   Large datacenters are often multisite in nature and contain a large
   number of RBridges. TRILL is designed to be a single IS-IS area. As
   the size of the TRILL network grows, the size of the IS-IS LSP
   database grows, leading to network convergence delays and increased
   volatility during transient conditions such as link flaps.




Senevirathne           Expires August 21, 2012                 [Page 3]


Internet-Draft             Multilevel TRILL               February 2012


   As mentioned above TRILL utilizes a tree based forwarding paradigm
   for multi-destination traffic. In large TRILL networks this may lead
   to sub-optimal forwarding. Additionally, entire network wide
   multicasting may lead to network bandwidth inefficiencies and have a
   negative impact on performance.

   In order to support scaling and performance of large TRILL networks,
   it is important to have methods to:

   1. Limit the size of the IS-IS LSP database
   2. Optimize multicast forwarding
   3. Limit the scope of flooding and broadcast traffic

   In this document we propose methods that allow implementing multi-
   level TRILL without any data plane changes as well as meet the above
   design goals.

   Also presented in this document is a novel method of constructing
   multi-destination trees using partial nickname space.

2. Conventions used in this document

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

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. Solution Overview

   Herein we present a high level view of the proposed solution;
   differing the details of the solution to subsequent sections.

   The TRILL campus is divided in to multiple IS-IS L1 Areas
   interconnected by L2 backbone area. The backbone area may be inter-
   connected by an IS-IS K2 area or by some other means. For example,
   one does not preclude a configuration based approach for the L2
   backbone.

   Area border RBridges indicate their ability to reach other areas by
   setting the Attach bit in IS-IS Link State PDU.

   RBridges forward frames destined to RBridges in the area using the
   exact match of nicknames. Frames destined to RBridges outside of the



Senevirathne           Expires August 21, 2012                 [Page 4]


Internet-Draft             Multilevel TRILL               February 2012


   L1 area are forwarded using the default route advertised by the area
   border RBridges.

   Campus wide Multi-destination trees are partitioned in to two parts.
   A backbone tree rooted on the L2 backbone and local trees rooted
   within each L1 area. For campus wide trees the local trees and the
   backbone tree have the same nickname. This avoids the need for
   egress RBridge nickname translation at the border RBridges).

   One of the border RBridges performs connecting its local tree to the
   corresponding backbone tree. The Affinity sub-TLV and Area Affinity
   sub-TLV information facilitate constructing proper RPF states.

4. Operational Overview

4.1. Unicast Forwarding

   The TRILL campus is divided in to multiple IS-IS L1 Areas with a
   Layer 2 backbone. (Figure 1).

   The "Attached" bit in IS-IS PDU is used to indicate the advertising
   IS connected to other areas. In this document we propose to leverage
   the "Attached" bit to identify the border RBRidges and forward
   traffic for all un-resolved nicknames to the border RBridges.

   Border RBridges possess the complete nickname space of the TRILL
   campus. Utilizing this information, ingress area border RBRidge
   forward TRILL frames to the egress area border RBridge via the L2
   backbone.

   Egress area border RBridges, forward the frame normally to the
   intended destination in the given L1 Area.

4.2. IS-IS Protocol changes for unicast forwarding

   Support for non zero IS-IS areas for TRILL.

   No new TLV or sub-TLV required.

   Border RBridges advertise LSP with the "Attached" bit set

   L1 Area RBridges are required to advertise TRILL related sub-TLV
   defined in [RFC 6326] with the router capability bit "S" set. The
   capability bit "D" MUST be set to zero (0). This allows leaking L1
   PDU to the L2 backbone area but not to other L1 areas [RFC4971].




Senevirathne           Expires August 21, 2012                 [Page 5]


Internet-Draft             Multilevel TRILL               February 2012


4.3. MAC Address Learning

   Egress RBridge learn remote MAC addresses against the actual
   nickname of the ingress RBRidge.

   As an example: Let's Assume MAC address A is attached to RB1 and MAC
   address B is attached to RB7.

   RB1 receives a frame destined to MAC B. RB1 does not know the
   location of MAC B. However, local policy such as, port or VLAN
   indicates that the frame is of global scope. RB1 transmits the frame
   on global tree "t" as an unknown unicast frame.

   RB7 receives the frame and learn MAC A is associated with RB1. RB7
   programs its forwarding tables such that MAC-A is associated with
   RB1. It also forwards the frame to MAC-B.

   MAC-B responds. RB7 has the association of MAC-A to RB1. Hence, RB7
   forwards the frame to RB1 as a unicast frame, with egress RBridge
   nickname as RB1 and ingress RBridge nickname as RB7.

   The frame follows the normal uicast forwarding process explained
   above and arrives at RB1. RB1, learns the MAC-B association to RB7
   and updates its forwarding tables accordingly. Also, RB1 forwards
   the frame to MAC-A.

4.4. Multicast

   Multicast forwarding has two parts: 1. Construction of the multicast
   trees 2. RPF (Reverse Path Forwarding) check.

   In most of the real world deployments, not all of the traffic is
   required or desired to span across the entire TRILL campus. The
   majority of the traffic tends to have a local scope and some subset
   of traffic to have a global scope.

   The scope of global traffic may be identified either through VLAN or
   via finegrain label that spans across the entire TRILL campus.

   In this document we propose to classify TRILL multi-destination
   trees into two types:

   1. Local trees (trees that have a scope within the local area)
   2. Global trees (trees that have a scope throughout the TRILL campus)





Senevirathne           Expires August 21, 2012                 [Page 6]


Internet-Draft             Multilevel TRILL               February 2012


   Multi-destination traffic of local scope is forwarded using Local
   trees. Multi-destination traffic of global scope is forwarded using
   global trees.

   Construction of global multi-destination trees and performing RPF
   check for such trees requires knowledge of all of the RBridges in
   the entire TRILL campus. In a large TRILL campus, construction of
   such global trees that need information of all RBridges may not only
   lack scalability but also may run in to instabilities during network
   changes. Additionally, when the TRILL campus is divided into
   multiple IS-IS L1 areas, RBridges within an L1 areas do not possess
   reachability information for other areas. Thus, constructing such
   global trees may not be possible.

   In this document we propose an [RFC6325] compatible approach of
   building multicast trees to address the issues mentioned above.

   In the proposed method, global trees (campus wide trees) are
   partitioned in to two instances; a backbone tree instance and set of
   local tree instance per each area.

   Backbone tree - An instance of the tree rooted in the L2 backbone.
   The Backbone tree is represented by the same nickname as the global
   tree.

   Local tree - An instance of a tree per area, per campus wide tree,
   rooted within each area. Each instance of the tree in each area is
   represented by the same nickname as the global tree. (This is
   important to avoid the need for tree translation at the border
   RBridges)

   L2 LSPs advertise the backbone tree.

   L1 LSPs advertise the corresponding local-tree within each area.

   One of the L1-L2 area border RBridges in an given area is assigned
   the role of Rendezvous Point (RP) for the specific local tree (more
   details are presented in section 8. ).

   Each RP functions as the plumb between the global tree and local
   tree. Both the trees have exactly the same nickname.

   RP An RP advertises affinity to the rest of the campus for the
   specified tree by using the Affinity sub-TLV [trillcmt]. In the
   Affinity TLV associated nickname MUST be specified as zero to
   indicate the Affinity is related to default route. We refer to this



Senevirathne           Expires August 21, 2012                 [Page 7]


Internet-Draft             Multilevel TRILL               February 2012


   usage of Affinity TLV as the default Affinity sub-TLV in the rest of
   the document.

   Each RBridge in the local L1 area builds its multi-destination SPF
   tree as specified in [RFC6325] and [trillcmt]. RPF checks are
   performed as specified in [RFC6325] and [trillcmt]. Additionally,
   RPF checks for default nicknames (i.e. all unknown nicknames to the
   local L1 area) are performed per the association specified by the
   default Affinity sub-TLV.

   Additionally, each RP on behalf of the local Area it is representing
   for multi-cast tree Tx, advertises Area Affinity-TLV towards the L2
   backbone area. The Area Affinity TLV, include the L1 Area ID of the
   associated area. The Area Affinity TLV, notifies RBridges in the L2
   area to enable the RPF check to accept nicknames in the associated
   L1 area from the announcing RP. The Area Affinity TLV allows greater
   scaling of the IS-IS LSP DB. If Affinity TLV contains all of the
   nicknames the IS-IS PDU size increases. Use of the Area Affinity
   sub-TLV to summarize the entire area in a single sub-TLV, limits the
   size of the LSP DB as well as PDU size. (Please see below for the
   structure of the Area Affinity sub-TLV).




         L1 Area A1            L2 Backbone            L1 Area A2
     +------------------+   +----------------+   +-----------------+
     |                 RB2  |                |  RB5                |
     |                +---+ |                | +---+               |
     |             o---o   o---o             o--o   o--o           |
     |   RB1          |   | |                | |   |        RB7    |
     |  +---+         +---+ |                | +---+       +---+   |
     |o-o   |               |                |   |         |   |   |
     |  |   o--o      +---+ |                | +---+    o--o   o-o |
     |  +---+         |   | |                | |   |       +---+   |
     |             o---o   o---o            o--o   o--o            |
     |                +---+ |                | +---+               |
     |                 RB3  +----------------+  RB6                |
     +-----------------+                         +-----------------+


                         Figure 1 Sample Topology







Senevirathne           Expires August 21, 2012                 [Page 8]


Internet-Draft             Multilevel TRILL               February 2012


         L1 Area A1            L2 Backbone              L1 Area A2
     +-------------------+   +----------------+    +-----------------+
     |    - t -          |   |     - t -      |    |        t        |
     |   |   \  \        |   |    /  |   \    |    |      - |-       |
     |   |    \  \       |   |   /   |    \              /  | \      |
     |   |     \  ----o RB2 o----   /|\    ----o RB5 o--    |  \     |
     |   |      \      (RP)  |     /   \      | (RP)        /   \    |
     |   o       \       |   |    /     \     |    |        /     o  |
     |            \-     |   |   /       \    |    |      /      RB7 |
     |  RB1        ---o RB3  |  /         \   |          /           |
     |                     X---o           \      t-----             |
     |                   |   |              ----X RB6                |
     +-------------------+   +----------------+     +----------------+

     -t-  Tree root for tree t
     --o  Port that accept multicast traffic for the tree "t"
     --X  Ports that do not accept multicast traffic for the tree "t"

                         Figure 2 Logical Topology



   Above Figure 1 depicts a sample Topology, Figure 2 depicts the
   corresponding logical topology. Local multicast trees and the global
   multicast trees have the same nickname "t". "X" denote the branches
   of the multicast tree that are not used for multicast traffic
   reception or transmission.  L1 RBridges, RB1, RB7 install RPF check
   based on the default Affinity TLV. L1 area border RBridges MUST not
   install the default RPF check on L2 interfaces, instead they MUST
   honor the Area Affinity TLV and install explicit RPF checks. Strict
   RPF check on area border RBridges are mandatory to prevent transient
   loops during topology changes.

4.5. Life of Multicast frame.

   RB1 ingresses multicast frames of global scope to global tree "t".
   The multicast frame traverses the tree "t" and arrives at RBridges
   RB2 and RB3. RB2 is the Rendezvous Point (RP) for tree "t" for Area
   A1. RB2 forward the frame to backbone multicast tree "t" as well as
   to the other local ports. RB3 is not the RP for tree "t" for area
   A1. Hence, it forwards the frame to local ports but does not forward
   along the backbone multicast tree "t".

   The multicast frame traverses along the backbone tree "t" and
   arrives at Area A2 border RBridges RB5 and RB6. The RB6, which is
   not the Rendezvous Point (RP) for backbone tree "t" for Area A2,
   accepts multi-destination frames arriving on L2 interface and only


Senevirathne           Expires August 21, 2012                 [Page 9]


Internet-Draft             Multilevel TRILL               February 2012


   forwards to other applicable L2 interfaces. Non RP RBridges do not
   forward multi-destination frames arriving on global tree on L1 area
   interface. RB5, the RP for the Area A2 for the multicast tree "t",
   contains the RPF check to accept frames from others areas on tree
   "t" on its L2 area interface. Hence, RB5, accept the multicast frame
   from tree "t" and forward along the local tree "t" and its local
   ports.

   The multicast packet traverses along the local tree "t" in Area A2
   and arrive at RB7. RB7 contains RPF check installed based on the
   Default Affinity TLV for tree "t", to receive multicast traffic for
   tree "t" that arrives from the RP facing interface. RB7 accepts the
   multicast frame arriving on local tree "t" with ingress RBridge
   nickname RB1 and performs applicable forwarding as specified in
   [RFC6325].

   RB6 is an Area border RBRidge for Area A2, but not RP for the area.
   RB6 receives the multicast frame through the local tree "t". Non RP
   area border RBridges for RPF and multi-destination forwarding
   purposes function like a L1 area RBridge. RB6, honors the default
   Affinity TLV received from RB5 for local multicast tree "t". Hence,
   it installs RPF check to accept all nicknames (default nickname) for
   tree "t" from the L1 Area interface pointing towards RB5.

   RB6 accepts the incoming multicast frame along tree "t" with the
   ingress RBridge nickname RB1 and performs applicable forwarding to
   locally attached ports. RB6, which is a non RP for tree "t" for area
   A2, MUST not forward the multicast frame to the global tree "t".

5. Area Affinity sub-TLV

   Area Affinity sub-TLV is a sub-TLV under IS-IS Router capability TLV
   and contains the following structure.
















Senevirathne           Expires August 21, 2012                [Page 10]


Internet-Draft             Multilevel TRILL               February 2012


      +-+-+-+-+-+-+-+-+
      |Type=AREA-AFF  |                (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                (1 byte)
      +---------------+
      | Area-ID-Length|                (1 byte)
      +---------------+---------------+
      | Area ID                       |  (variable 1..13)
      .                               .
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | number of trees               |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |tree-num of 1st preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |tree-num of 2nd preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                               .
      +-------------------------------+
      |tree-num of Nth preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3 Area Affinity TLV structure

     o Type: AREA-AFF, (TBD).

     o Length: variable. Length is 1 + length of Area ID + 2*n, where
        n is the number listed tree numbers.

     o Area-ID : (variable length) Is the IS-IS Area ID. Length can be
        1-13 bytes long.

     o Number of trees : number of trees for which association
        (affinity) being announced.

     o  Tree-num of preferred root: The tree Number of the multicast
        tree.

     Area-affinity conflicts MUST be resolved using methods specified
     in [trillcmt].

6. Nickname acquisition and conflict resolution

   In the proposed method, nicknames of RBridges in remote L1 areas are
   not advertised into the local L1 area by area border RBridges.
   However, L2 backbone RBridges and L1-L2 border RBridges contain the
   nicknames used by all the RBridges in the campus. We propose to


Senevirathne           Expires August 21, 2012                [Page 11]


Internet-Draft             Multilevel TRILL               February 2012


   introduce a new IS-IS sub-TLV under Router capability TLV to
   distribute available nickname space. New IS-IS sub TLV is Nickname
   Management sub-TLV.

   Nickname Management sub-TLV is announced by the area border RBridges
   in to the local L1 area with Router capability bits D set to one and
   S set to one. Nickname Management sub-TLV is announced in to L2 area
   by the area border RBridges with S and D bit clear. These settings
   ensure Nickname Management TLV is confined to the local L1 area L2
   area and does not leak to other L1 areas.

   Nickname Management sub-TLV instance announced in to the local area,
   contains two sets of ranges. Local nickname ranges and dynamic
   nickname ranges. Local nickname ranges are one or more sets of
   ranges that network administrator has configured on the border
   RBridges. Multiple local nickname ranges allow network administrator
   to configure multiple sets of non contiguous nickname ranges.

   L1 area RBridges SHOULD, first, select a nickname or nicknames from
   the local ranges.

   If entire local nickname space has exhausted (i.e. taken up by other
   RBridges), then L1 are RBridges SHOULD select a nickname or
   nicknames from the dynamic ranges.

   It is recommended that RBridges use different nickname priorities to
   differentiate nickname acquired by different methods. Nickname
   priorities are assigned based on the acquisition method such that
   configured nicknames have highest priority, followed by nicknames
   derived from the local range, followed by nicknames derived from the
   dynamic range.

   Dynamic ranges are derived by the area border RBridges based on the
   local nickname ranges of its and other areas. As an example let's
   assume area A1 has local nickname range of 100-200, A2 has a local
   nickname range of 201-300. Then the dynamic range is from 1-99 and
   301 to 65471 (0xFFBF). Nickname values 0 and 0xFFC0 to 0xFFFF are
   reserved and MUST not be included in the dynamic nickname ranges.

   Nickname Management sub-TLV instance announced in to the L2 backbone
   area, contains only the local nickname ranges. Local nickname ranges
   of each area allow other areas to derive applicable dynamic ranges
   to announce in to the corresponding L1 area.






Senevirathne           Expires August 21, 2012                [Page 12]


Internet-Draft             Multilevel TRILL               February 2012




6.1. Nickname Management sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type=NICK-MGMT |                (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                (1 byte)
      +---------------+
      | Area-ID-Length|                (1 byte)
      +---------------+---------------+
      | Area ID                       |  (variable 1..13)
      .                               .
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NL            |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |starting nickname for l-range 1|  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |end nickname for l-range 1     |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |starting nickname for l-range n|  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |end nickname for l-range n     |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ND            |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |starting nickname for d-range 1|  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |end nickname for d-range 1     |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |starting nickname for d-range n|  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |end nickname for d-range n     |  (2 bytes)
      +-------------------------------+


              Figure 4 Nickname Management sub-TLV structure

     o Type: NICK-MGMT, (TBD).





Senevirathne           Expires August 21, 2012                [Page 13]


Internet-Draft             Multilevel TRILL               February 2012


     o Length: variable. Length is 1 + length of Area ID + 1+2*2*NL +
        1 + 2*2*ND, where NL is the number local ranges and ND is
        number of dynamic ranges.

     o Area-ID : (variable length) Is the IS-IS Area ID. Length can be
        1-13 bytes long.

     o NL : number of local nickname ranges.

     o ND : number of dynamic ranges.

     o Starting nickname for l-range n: starting nickname of the local
        range n.

     o End nickname for l-range n: End nickname of the local range n.

     o Starting nickname for d-range n: starting nickname of the
        dynamic range n.

     o End nickname for d-range n: End nickname of the dynamic range
        n.

    NOTE: Multiple instances of the nickname management sub-TLV MAY be
   included. Nickname management sub-TLV has usage in non multi-level
   deployments as well. Nickname management sub-TLV allows
   administrator to control nickname acquisition by RBridges.

7. Further optimizations

   RFC6325 allows multiple instance of nickname sub-TLV. If more
   specific forwarding is required, for some critical RBridges, such
   nicknames MAY be advertised in a separate Router capability TLV,
   with S bit set. So it leaks to all L1 areas.

7.1. Leaking of TRILL IS-IS sub-TLV within areas

   At the boundary nodes, the following information needs to be leaked
   from the Level-1 database to the Level-2 database. The nickname TLVs
   that are learned from all nodes within the same site needs to be
   redistributed to the Level-2 database. All such redistributed
   nickname TLVs will have the root priority set to 0. Note, that all
   border area nodes will announce this TLV into the Level-2 database.
   As a result, all Level-2 nodes will be able to see the reachability
   of all other nodes. This enables unicast traffic flow. With respect
   to multicast, redistributed nicknames are not to be used in the root
   election for global trees. The roots of the global trees will be
   from the set of nicknames that are in the Level-2 database. Once the


Senevirathne           Expires August 21, 2012                [Page 14]


Internet-Draft             Multilevel TRILL               February 2012


   roots have been identified, these nicknames need to be leaked back
   to the Level-1 areas. Calculation of multi-destination trees are
   presented in section 7.2.

7.2. Identification of Global Trees

   It is expected only a sub-set of traffic requires a global reach
   (inter Area). Majority of the traffic will be of local scope (intra
   area). Scope of the traffic can be identified either based on VLAN
   or fine-grain label. Traffic of global scope is forwarded using
   global trees. The trees of global scope may be indentified:

   1. By means of configuration
   2. By means of multi-destination tree announcements sub-TLV.

   Point number 2 above requires further clarifications. We propose to
   introduce 3 new sub-TLV under IS-IS router capability TLV to
   advertise global multi-destination trees. These new sub-TLV are
   listed below. Format of the new sub-TLVs are presented in section
   7.2.1. to 7.2.3.

     o The Global Tree capability sub-TLV
     o The Global Tree proposal sub-TLV
     o The Global Tree identifier sub-TLV

   Each RBridge announces two sets of capabilities; global tree
   capabilities and local tree capabilities. It announces, maximum
   number of global distributions trees it can compute. RBridges
   utilize Global Tree sub-TLV for the purpose of announcing its global
   tree capability. RBridges announce local tree capabilities using The
   Tree sub-TLV [RFC6326]. Global tree space is disjoint from the local
   tree space and MUST not have any effect on each other. Please refer
   to [RFC6325] for the process of how local trees are derived. In this
   section we present how the total number of global trees needed is
   calculated and identification of nickname of each tree root.

   Each area border RBridge, using the global tree sub-TLV received
   from RBRidges in its local area, derives the number of trees the
   area can support. The number of global trees "s", a local area can
   support is the fewest number of global trees that an RBridge in
   local area can support. Area border RBridges advertise in to the
   backbone, using the global Tree capability sub-TLV, the number of
   trees "s" that the given area can calculate. Global Tree capability
   sub-TLV announced in to the L2 backbone are advertised with "S" and
   "D" flags of Router Capability TLV set to 0. This prevent them
   leaking to L1 areas.



Senevirathne           Expires August 21, 2012                [Page 15]


Internet-Draft             Multilevel TRILL               February 2012


   Rbridges in the L2 backbone calculate the number of global trees the
   campus can calculate. This number "i" is the fewest number of global
   trees among all areas.

   Each RBridge in the L2 backbone using Global Tree proposal sub-TLV
   advertise the number of trees it want other RBridges in the L2
   backbone to calculate. RBridges in the L2 backbone identifies number
   of global trees they need to calculate based on the number of trees
   "k" advertised by the highest priority RBridge in the L2 backbone.

   The L2 area RBridge with the highest priority advertises set of
   nicknames for the global tree roots. These tree roots are selected
   based on tree root priority announced by L2 backbone RBridges.
   Global Tree Identifier sub-TLV is used for the purpose.

   BSR RBRidge of each L1 area advertises nicknames of global tree
   roots using Global Tree Identifier sub-TLV in to the corresponding
   local area. BSR also advertises the number of Global trees k the
   local area needs to calculate using Global tree proposal sub-TLV.

   RBridges in the local area contain only nicknames of the local area.
   Global Tree Identifier sub-TLV announced by the BSR contains
   nicknames that are unknown to the local L1 area RBridges. How do
   local RBridges calculate it SPF ?

   Global Tree Identifier sub_TLV contain nickname of the global trees
   ordered in ascending order. Default Affinity TLV announced by RP
   RBridge contains the tree-id(s) that it is an RP. Tree-id k in the
   Default affinity TLV corresponds to nickname k in the Global Tree
   Identifier. RBRidges in the local L1 area calculate its SPF tree
   assuming the tree-k is rooted at the RP RBridge announcing the
   Default affinity sub-TLV for that tree.

   Global Tree proposal sub-TLV and Global Tree Identifier sub-TLV MUST
   only be advertised by BSR. Sub-TLV from highest priority RBRidge is
   chosen, in the event of multiple RBridges advertising conflicting
   sub-TLVs.












Senevirathne           Expires August 21, 2012                [Page 16]


Internet-Draft             Multilevel TRILL               February 2012


7.2.1. Global Tree capability sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type = GL-TREES|                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |  Length       |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Maximum trees able to compute |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5 Global Tree Capability sub-TLV

   Type: Router Capability sub-TLV type, TBD

   Length: 2.

   Maximum trees able to compute: An unsigned 16-bit integer indicates
   maximum number of global trees the announcing RBridge able to
   compute.

7.2.2. Global Tree proposal sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type = GL-TR-PR|                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |  Length       |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Maximum trees to compute      |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6 Global Tree Proposal sub-TLV

   Type: Router Capability sub-TLV type, TBD (GL-TR-PR)

   Length: 2.

   Maximum trees to compute: An unsigned 16-bit integer indicates
   maximum number of global trees the announcing RBridge wants area
   RBRidges to calculate.










Senevirathne           Expires August 21, 2012                [Page 17]


Internet-Draft             Multilevel TRILL               February 2012


7.2.3. Global Tree Identifier sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type=GLTR-RT-IDs|               (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Starting Tree Number         |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (K-th root)      |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (K+1 - th root)  |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (...)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 7 Global Tree Identifier sub-TLV

   Type: Router Capability sub-TLV type, set to TBD (GLTR-RT-IDs).



   Length: 2 + 2*n, where n is the number of nicknames listed.



Starting Tree Number: This identifies the starting tree number ofthe
nicknames that are trees for the domain.  This is set to 1 for the sub-
TLV containing the first list.  Other Tree-Identifiers sub-TLVs will
have the number of the starting list they contain. In the event a tree
identifier can be computed from two such sub-TLVs and they are
different, then it is assumed that this is a transient condition that
will get cleared.  During this transient time, such a tree SHOULD NOT
be computed unless such computation is indicated by all relevant sub-
TLVs present.

Nickname: The nickname at which a distribution tree is rooted.



7.3. Announcing Group Addresses

   Group Address announcements facilitate optimization of multicast
   forwarding. [RFC6326] and [rfc6326bis], define series of sub-TLV to
   announce various flavors of Group addresses. These sub-TLVs are
   encapsulated in Group Address TLV (142). We propose to define new


Senevirathne           Expires August 21, 2012                [Page 18]


Internet-Draft             Multilevel TRILL               February 2012


   set of sub-TLV under Group Address TLV to carry Group Address
   announcements applicable to Global trees. IS-IS Group Address TLV
   (142) does not have flags to control the scope of the TLV. Hence,
   explicit, sub-TLV definitions are required to indentify group
   announcements that have global scope.

   New sub-TLV numbers are required for the following.

     o Group MAC Address Sub-TLV
     o Group IPv4 Address Sub-TLV
     o Group IPv6 Address Sub-TLV
     o Group Labeled MAC Address Sub-TLV
     o Group Labeled IPv4 Address Sub-TLV
     o Group Labeled IPv6 Address Sub-TLV

   Above sub-TLVs as defined in [RFC6326] and [rfc6326bis] applies to
   all trees within the TRILL campus. New sub-TLV definitions include
   flexibility to define the applicable multicast trees. This
   flexibility allows applications to further optimize multicast
   pruning per multicast tree basis.

   New group address sub-TLV will be named as below and they have
   common TLV header as defined in Figure 8.

     o Group MAC Address-multicast tree Sub-TLV
     o Group IPv4 Address-multicast tree Sub-TLV
     o Group IPv6 Address-multicast tree Sub-TLV
     o Group Labeled MAC Address-multicast tree Sub-TLV
     o Group Labeled IPv4 Address-multicast tree Sub-TLV
     o Group Labeled IPv6 Address-multicast tree Sub-TLV



















Senevirathne           Expires August 21, 2012                [Page 19]


Internet-Draft             Multilevel TRILL               February 2012


    +-+-+-+-+-+-+-+-+
    |Type=G-ADDR-TR |                  (1 byte)
    +-+-+-+-+-+-+-+-+
    |   Length      |                  (1 byte)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  RESV |     Topology-ID       |  (2 bytes)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | number of trees               |  (2 bytes)
    +-------------------------------+
    | nickname of kth tree          |  (2 bytes)
    +-------------------------------+
    | nickname of k+1 tree          |  (2 bytes)
    +-------------------------------+
    .                               .
    |                               |
    +-------------------------------+
    | nickname of (k+n) tree        |  (2 bytes)
    +-------------------------------+
    |  RESV |  VLAN ID/Label        |  (2 or 3 bytes)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Num Group Recs |                  (1 byte)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   GROUP RECORDS (1)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   GROUP RECORDS (m)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 8 Common structure of Group-Address-multicast tree sub-TLVs

     o Type: G-ADDR-TR, (TBD). Defines sub-TLV for

          o Group MAC Address-multicast tree Sub-TLV
          o Group IPv4 Address-multicast tree Sub-TLV
          o Group IPv6 Address-multicast tree Sub-TLV
          o Group Labeled MAC Address-multicast tree Sub-TLV


     o Length: Applicable length of the sub-TLV in bytes. Excludes
        length of G-ADDR-TR and Length fields.

     o Topology ID: 2 byte identifier of the topology instance id.




Senevirathne           Expires August 21, 2012                [Page 20]


Internet-Draft             Multilevel TRILL               February 2012


     o Number of trees: Number of tree nicknames included in the sub-
        TLV. The nicknames included in the sub-TLV MUST be sorted in
        ascending order.

     o Nickname of kth tree: 2 byte nickname of the kth tree to which
        this Group address-tree announcement applies.

     o VLAN ID/Label: Either 4bit reserved followed by 12bit VLAN ID
        or 24bit finegrain label. Please see [rfc6326bis] for details.

     o Num Grp Recs: Number of Group Records to follow.

     o Group Record: Contents of the Group Records depend on the G-
        ADDR-TR definition and identical to their counterparts defined
        in [rfc6326bis].



8. Architecture Elements of Multi-level Multicast framework

     o Bootstrap RBridge

     o Rendezvous Point (RP)

     o Default Affinity sub-TLV

     o Area Affinity sub-TLV

     o RP Election Protocol



   Five main elements of the multi-level multicast framework are listed
   above. Functional overviews of the elements are discussed below.
   Details, such as state machines, PDU format, etc, will be presented
   in later versions of this document.

8.1. Bootstrap RBridge

   Each Area has one more area border RBridges between the Area and the
   L2 backbone area. For each area one of its area border RBridges is
   elected as the Bootstrap RBridge.

   Border RBridges communicate with each other using the TRILL BSR
   protocol. Each border RBridge has a configured priority to be a
   Bootstrap RBridge with system-ID as the tie breaker. The RBridge
   with the highest priority become the bootstrap RBridge for the area.


Senevirathne           Expires August 21, 2012                [Page 21]


Internet-Draft             Multilevel TRILL               February 2012


   Bootstrap RBRidge selects the Rendezvous Point (RP) RBridges and
   assign each RP a set of trees for which RP will function as the
   gateway between the local and global multicast trees. To avoid loops
   and/or packet duplication the set of trees MUST only be allocated to
   one and only one RP.

8.2. Rendezvous Point (RP)

   Rendezvous Point (RP) RBridge performs the function of gateway (or
   acts as a point of plumbing) between the local multicast tree and
   the corresponding global multicast tree rooted in the L2 backbone
   area.

   Bootstrap RBridge designates one of the border RBridges (including
   itself) as the RP for a set of (mutually exclusive) trees.

   Each border RBridge, using TRILL BSR protocol, announces its desire
   to be an RP. The desire to be an RP is a configurable option and
   enabled by default to be an RP.

8.3. Default Affinity sub-TLV

   Default Affinity sub-TLV is announced by each RP to inform the
   RBridges in the L1 Area the association of the default nickname to a
   set of trees through the announcing RP [trillcmt].

   RBridges in the L1 area, based on the Default Affinity sub-TLV
   installs the RPF check for default nickname for the specified tree
   "t" on an interface facing towards the announcing RP.

8.4. Area Affinity sub-TLV

   The Area Affinity sub-TLV announced by each RP to inform the
   RBridges in L2 backbone Area the association of local L1 Area
   nicknames to a set of trees through the announcing RP (Figure 3).

   RBridges in the L2 backbone area or has interfaces to the L2
   backbone area, based on the Area Affinity sub-TLV, installs the RPF
   check for the nicknames in the indicated L1 Area, for the specified
   tree "t", on an interface facing towards the announcing RP.

8.5. TRILL BSR Protocol

9. Security Considerations

   TBD



Senevirathne           Expires August 21, 2012                [Page 22]


Internet-Draft             Multilevel TRILL               February 2012


10. IANA Considerations

   IANA is requested to add the Area Affinity sub-TLV, Nickname
   Management sub-TLV, Global Tree capability sub-TLV, Global tree
   proposal sub-TLV, Global tree Identfier sub-TLV as sub-TLVs under
   Router capability TLV.

11. References

11.1. Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
             Syntax Specifications: ABNF", RFC 2234, Internet Mail
             Consortium and Demon Internet Ltd., November 1997.

   [RFC4971] Vasseur, JP, et.al, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Advertising Router
             Information ", RFC 4971, July 2007.

   [RFC6325] Perlman, R., et.al, "Routing Bridges (RBridges): Base
             Protocol Specification", RFC 6325, July 2011.

   [trillcmt]Senevirathne, T., et.al, "Coordinated Multicast Trees
             (CMT)for TRILL", Work in Progress, January 2012.

   [RFC4971] Vasseur, JP, et.al, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Advertising Router
             Information", RFC 4971, July 2007.

11.2. Informative References

   [RFC6326] Eastlake, D, et.al, "Transparent Interconnection of Lots
             of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.

   [rfc6326bis] Eastlake, D, et.al, "Transparent Interconnection of
             Lots of Links (TRILL) Use of IS-IS", Work in Progress,
             draft-eastlake-isis-rfc6326bis-04.txt, January 2012.

   [trillml] Perlman, R., et.al, "RBridges: Multilevel TRILL", Work in
             Progress, draft-perlman-trill-rbridge-multilevel-03.txt,
             October 2011.





Senevirathne           Expires August 21, 2012                [Page 23]


Internet-Draft             Multilevel TRILL               February 2012


12. Acknowledgments

   We wish to thank Leonard Tracy, Dinesh Dutt and Ashok Ganesan for
   reviewing and providing constructive feedback.

   This document was prepared using 2-Word-v2.0.template.dot.











































Senevirathne           Expires August 21, 2012                [Page 24]


Internet-Draft             Multilevel TRILL               February 2012


Authors' Addresses

   Tissa Senevirathne
   CISCO Systems
   375 East Tasman Drive
   San Jose CA 95134

   Phone: 408-853-2291
   Email: tsenevir@cisco.com

   Les Ginsberg
   CISCO Systems
   510 McCarthy Blvd.
   Milpitas CA 95035

   Phone: 408-527-7729
   Email:ginsberg@cisco.com

   Janardhanan Pathangi
   Dell/Force10 Networks
   Olympia Technology Park,
   Guindy Chennai 600 032

   Phone: +91 44 4220 8400
   Email: Pathangi_Janardhanan@Dell.com

   Jon Hudson
   Brocade
   130 Holger Way
   San Jose, CA 95134 USA

   Email: jon.hudson@gmail.com

   Sam Aldrin
   Huawei Technologies
   2330 Central Express Way
   Santa Clara, CA 95951

   Email: aldrin.ietf@gmail.com

   Ayan Banerjee
   CISCO Systems
   425 East Tasman Drive
   San Jose CA 95134

   Phone: 408-527-0539
   Email: ayabaner@cisco.com


Senevirathne           Expires August 21, 2012                [Page 25]


Internet-Draft             Multilevel TRILL               February 2012





   Sameer Merchant
   Consultant

   Email: Sameer.merchant@gmail.com










































Senevirathne           Expires August 21, 2012                [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/