Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
Radia Perlman <radiaperlman@gmail.com> Fri, 24 February 2012 18:03 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 B3FAC21F87E3 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 10:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.068
X-Spam-Level:
X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, 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 lOe7ArbTH-fS for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 10:02:56 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64221F87CF for <trill-archive-Osh9cae4@lists.ietf.org>; Fri, 24 Feb 2012 10:02:56 -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 q1OHNtH5014906; Fri, 24 Feb 2012 09:23:57 -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 q1OHN8uX014498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 09:23:17 -0800 (PST)
Received: by eaad14 with SMTP id d14so1215911eaa.39 for <multiple recipients>; Fri, 24 Feb 2012 09:23:07 -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=MyrhkNr9FwXWIUbK8Mtv+DwUfmD3pqZKvEraaQZUjsE=; b=Wx8Dow+mHc8ZC2Yshrl9KrUXNthEem7+CiCruLelJK2PFtQHwEVF4fh+H83K8AMxai c62N5HBCE0Ri40zlP3rJskdT6EVaABaH+8RAOR+JYtWozWBPtFFxXAhWZFLbOZiwH28I xBDhKFFR7wsxhkOsZ1CNRQ1E5B9IdN2Vb8UpQ=
MIME-Version: 1.0
Received: by 10.14.28.142 with SMTP id g14mr1492859eea.86.1330104187371; Fri, 24 Feb 2012 09:23:07 -0800 (PST)
Received: by 10.213.28.14 with HTTP; Fri, 24 Feb 2012 09:23:06 -0800 (PST)
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com>
References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <OF39984F87.131AB40B-ON482579AE.0020DCD7-482579AE.00214152@zte.com.cn> <CAFOuuo7gPT=0W8jC-uKFDXnWzUNEiRYsyjgOqeh-49AmCA9Tyg@mail.gmail.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> <CAFOuuo6JLo81jga1ktzLRYt0TGxOx_4ke0n-rA3i2urYgN4VOQ@mail.gmail.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com>
Date: Fri, 24 Feb 2012 09:23:06 -0800
Message-ID: <CAFOuuo7ROfqOc_jpwKpU73f3a4S0rSr3XuXA-fn=BKO_fN-Q7A@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: radiaperlman@gmail.com
Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn
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="===============0689288538=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
I assume that all RBridges will need to be in all topologies, so multitopology will not help with nickname exhaustion. Plus you haven't explained how a TRILL packet would be marked as to which topology the packet should be routed according to (other than what I mentioned, which actually eats up nicknames by a factor of the number of topologies supported). Plus, rather than just lumping potential issues into a phrase such as "NAT-like", be explicit about what issues there actually are. I believe the Fulcrum chip would have no problem with translating the nickname fields. And rather than assuming that nickname exhaustion can be solved "some other way", there should be a palatable solution before rejecting a chance to solve it with multilevel. Radia 2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> > Because you can have same nickname for different topology. It is not a > nickname that will identify an RBRidge, it is topology,nickname combination > that will identify an RBRidge. So RB1 can have nickname 1 in topo-1 and RB2 > can have nickname 1 in topo2. Now total nicknames in the campus is 2**16 x > topologies.**** > > ** ** > > Stealing bits to represent topo id is only a workaround there can be (are > ) more elegant ways of doing it that.**** > > ** ** > > Bottom line is we need to look for more creative methods of solving > nickname space issue than doing NAT like behavior. **** > > ** ** > > *From:* Radia Perlman [mailto:radiaperlman@gmail.com] > *Sent:* Friday, February 24, 2012 9:05 AM > *To:* Tissa Senevirathne (tsenevir) > *Cc:* hu.fangwei@zte.com.cn; rbridge@postel.org; > rbridge-bounces@postel.org > > *Subject:* Re: [rbridge] Default nickname base approach for multilevel > TRILL- draft-tissa-trill-multilevel-00.txt**** > > ** ** > > I don't understand how multi-topology helps with the nickname exhaustion > issue. As a matter of fact, the only plausible way of marking a packet for > which topology that has been suggested on the mailing list (I asked a efw > times if there were any other possibilities), was to steal 2 or 3 bits of > the nickname to encode which topology, in effect, making a destination > appear as multiple destinations and multiple forwarding table entries > (which you'd want anyway, for multitopology).**** > > **** > > **** > > Radia**** > > 2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>**** > > Mutli-topology is the answer to increase the nickname space.**** > > **** > > Nickname translation is very similar to NAT, which has it’s own down side, > not to mention special hardware etc. to do the translations, additionally. > We also know from our experience, in IP world NATing is not the most > desired behavior and we live with it. So we should not be going down that > path instead need to look forward from that experience.**** > > **** > > Multi-topology not only address nickname space issue but also enables > various other applications such as overlay topologies, traffic engineering. > **** > > **** > > The draft-tiss-trill-multilevel present approaches that are generic, which > mean it can be applied for multi-topology, or base topology. It utilizes > the fundamentals of IS-IS , such as Area hierarchy for reduction of the > LSP-DB. It utilize affinity TLV concepts to effectively solve > multi-destination issues. **** > > **** > > We should not mix-up between Data center interconnects with data center > node scaling. They are two different and orthogonal issues.**** > > **** > > Objective of multi-level trill is to interconnect different datacenters, > and maintain LSP-DB small as possible to avoid scaling and volatility.**** > > **** > > Increasing nickname space a different requirement and has nothing to do > with data-center interconnects.**** > > **** > > **** > > *From:* Radia Perlman [mailto:radiaperlman@gmail.com] > *Sent:* Friday, February 24, 2012 6:15 AM > *To:* hu.fangwei@zte.com.cn > *Cc:* Tissa Senevirathne (tsenevir); rbridge@postel.org; > rbridge-bounces@postel.org > *Subject:* Re: [rbridge] Default nickname base approach for multilevel > TRILL- draft-tissa-trill-multilevel-00.txt**** > > **** > > 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
- [rbridge] Default nickname base approach for mult… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … hu.fangwei
- Re: [rbridge] Default nickname base approach for … Radia Perlman
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Radia Perlman
- Re: [rbridge] Default nickname base approach for … Radia Perlman
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Donald Eastlake
- Re: [rbridge] Default nickname base approach for … Donald Eastlake
- Re: [rbridge] Default nickname base approach for … Vishwas Manral
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … hu.fangwei
- Re: [rbridge] Default nickname base approach for … hu.fangwei
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Sam Aldrin
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)
- Re: [rbridge] Default nickname base approach for … Sam Aldrin
- Re: [rbridge] Default nickname base approach for … Sam Aldrin
- Re: [rbridge] Default nickname base approach for … hu.fangwei
- Re: [rbridge] Default nickname base approach for … Tissa Senevirathne (tsenevir)