Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

Radia Perlman <radiaperlman@gmail.com> Fri, 24 February 2012 14:56 UTC

Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09B721F87E4 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 06:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.056
X-Spam-Level:
X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tjd7mGbUgTl for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 06:56:06 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 97F8B21F867A for <trill-archive-Osh9cae4@lists.ietf.org>; Fri, 24 Feb 2012 06:56:06 -0800 (PST)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEFir7011516; Fri, 24 Feb 2012 06:15:45 -0800 (PST)
Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEFMH9011485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 06:15:32 -0800 (PST)
Received: by eaad14 with SMTP id d14so1099825eaa.39 for <multiple recipients>; Fri, 24 Feb 2012 06:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t8suXIeYS2LAd39tYQtBCokbkGTH/LDtUbABNa6eJhM=; b=Z2p2hgcirJKqNXvW6XALHFoqd8LCu0Iko4h7Cc4TypGsPm77YFoZ9B2mBpn618GsFs XKRvBUDGn4XG6GQfTOZHFW++rzoilUVb5Ct6t3vlDofTw/6y1ZCG7WqcWYsx9dwL7h2L /FPaF6LVt5IW7vgMjlhaK22I4TRPALz7Q3mYs=
MIME-Version: 1.0
Received: by 10.14.99.2 with SMTP id w2mr1228653eef.69.1330092921304; Fri, 24 Feb 2012 06:15:21 -0800 (PST)
Received: by 10.213.28.14 with HTTP; Fri, 24 Feb 2012 06:15:21 -0800 (PST)
In-Reply-To: <OF39984F87.131AB40B-ON482579AE.0020DCD7-482579AE.00214152@zte.com.cn>
References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <OF39984F87.131AB40B-ON482579AE.0020DCD7-482579AE.00214152@zte.com.cn>
Date: Fri, 24 Feb 2012 06:15:21 -0800
Message-ID: <CAFOuuo7gPT=0W8jC-uKFDXnWzUNEiRYsyjgOqeh-49AmCA9Tyg@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: hu.fangwei@zte.com.cn
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: radiaperlman@gmail.com
Cc: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, rbridge@postel.org, rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1286324913=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org

People have mentioned to me that they are nervous about running out of
nicknames, especially since there are reasonson why they might want to
assign nicknames to hypervisors.  With the alternate approach of allowing
nicknames to be reused in different areas, it makes automatic nickname
assignment much simpler and makes TRILL a lot more scalable.

It does have the downside of requiring mapping of nicknames at the border
RBridges.

And by the way, the affinity TLV can be used for multidestination frames
transiting between level 1 and level 2.

Radia

2012/2/23 <hu.fangwei@zte.com.cn>

>
> Hi, Tissa.
>
> I have several comments about the draft.
>
> (1) in section 4.4 (Multicast), "The scope of global traffic may be
> identified either through VLAN or via finegrain
> label that spans across the entire TRILL campus."
> Vlan and Fine-grain Label is used for service differentiation and
> isolation. I do not quite understand that how to
> use VLAN and fine-grain Lable to identify the traffic scope. The data
> traffic with a given VLAN-x, can
> be forwarded to other end station in the local area, or to the end station
> in remote areas.
>
> (2) nickname allocation
> The nickname management sub-TLV is proposed in the document. I wonder this
> mechanism adds the complication of
> nickname allocation. As the section 1 (introduction) of RFC6325, one of
> the important advantage of TRILL is that
> it avoids the creating subnets of IP address and wasting address. The
> nickname acquisition  method in this draft violates the
> idea of TRILL Basic specification, and reduces the flexibility of nickname
> allocation. As the draft assumed, A1 had
> nickname range of 100-200, A2 has a local nickname range of 201-300. If
> the numbers of A1 area is only 50, so 50
> nicknames in A1 is wasted. As the network growing, the number of some
> areas may exceed the number being allocation
> by Border RBridges. The design and maintaining of nickname ranges for each
> area is a very hard work. Even worst, it
> can not avoid to waste nickname space.
>
> (3) Dynamic ranges
>  The nickname range is divided into two range: local range and dynamical
> range. I wonder the nickname conflict
> resolution can not work if the RBridge get the nickname from the dynamical
> range while the two RBridge belongs to
> different areas. For example, RB1 is in area A1, and RB2 is in area A2. If
> RB1 gets the nickname N1 from dynamic
> range, and it will floods in area A1, and other RBridges in area A1 can
> not get nickname N1 because of nickname
> confliction mechanism, but RB2 in area A2 can not receive the PDU from
> RB1, and it  can also get the nickname N1 from
> dynamical range. So the question is how to avoid the duplication dynamical
> range nickname for different areas.
>
> (4) The risk of running out of nickname maybe a issue for TRILL. The
> number of 2**16 nickname is enough for the current data center,
>  but it maybe not enough in the future, especailly if TRILL over IP ,
> TRILL over MPLS technology or some other data center technologies
>  are deployed, the data center network can be a very lardge network. So i
> think the very important and essential goal of multi-level draft is to save
> nicknames.
>
> Best regards
> Fangwei Hu
>
>
>
>   *"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>*
> 发件人:  rbridge-bounces@postel.org
>
> 2012-02-23 11:55
>    收件人
> <rbridge@postel.org>
> 抄送
>   主题
> [rbridge] Default nickname base approach for multilevel TRILL-
>  draft-tissa-trill-multilevel-00.txt
>
>
>
>
> Dear All
>
> We have submitted draft-tissa-trill-multilevel, present multilevel TRILL
> based on default nickname approach. Additionally we discuss construction of
> multi-destination trees and related RPF in multilevel TRILL. Please could
> you review and comment
>
> Detail of the draft and abstract are below.
>
> Filename:                  draft-tissa-trill-multilevel
> Revision:                  00
> Title:                                   Default Nickname Based Approach
> for Multilevel TRILL
> Creation date:                  2012-02-21
> WG ID:                                   Individual Submission
> Number of pages: 26
>
> 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.
>
>
>
> Thanks
> Tissa
>
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge@postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge