Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
Donald Eastlake <Donald.Eastlake@huawei.com> Fri, 24 February 2012 19:14 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 7BDBF21F86E2 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 11:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level:
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 yJSR22U3vpld for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Fri, 24 Feb 2012 11:14:37 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7921F86CA for <trill-archive-Osh9cae4@lists.ietf.org>; Fri, 24 Feb 2012 11:14:37 -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 q1OIloqS001682; Fri, 24 Feb 2012 10:47:53 -0800 (PST)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OIlOeH001651 for <rbridge@postel.org>; Fri, 24 Feb 2012 10:47:33 -0800 (PST)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADW22957; Fri, 24 Feb 2012 13:47:24 -0500 (EST)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 10:44:50 -0800
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sat, 25 Feb 2012 02:44:54 +0800
From: Donald Eastlake <Donald.Eastlake@huawei.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, Radia Perlman <radiaperlman@gmail.com>
Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
Thread-Index: AQHM8xj4bt2qI1nfQfiYK8zrqzIBUJZM3BiA//+EDXA=
Date: Fri, 24 Feb 2012 18:44:07 +0000
Message-ID: <C5BD54C085F1DB4D9B6B5BFF7ACE182B355A4302@dfweml505-mbx>
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> <CAFOuuo7ROfqOc_jpwKpU73f3a4S0rSr3XuXA-fn=BKO_fN-Q7A@mail.gmail.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com>
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.34.150]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: donald.eastlake@huawei.com
Cc: "rbridge@postel.org" <rbridge@postel.org>, "hu.fangwei@zte.com.cn" <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="===============1662230294=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
See below at <dee3>. From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Tissa Senevirathne (tsenevir) Sent: Friday, February 24, 2012 1:00 PM To: Radia Perlman 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 RBridges do not have to be in all topologies. Why would they should be? <dee3> I would agree that an RBridge does not have to be in all topologies although I think it will be common for some RBridges to be in many topologies. <dee3> I view a nickname as an abbreviation of the 48-bit IS-IS System ID. The differences being that it is shorter, is auto allocated by default, and there can be more than one of them that map to the same System ID so that an RBridge can be the root of more than one distribution tree and so that there could be an egress nickname that uses traffic engineered routing rather than the default least cost routing. Intermediate Systems do not have different System IDs in different topologies, as far as I know. I don’t see how/why they would have different nicknames in different topologies. What is Fulcrum chip ? <dee3> The four merchant silicon manufacturers that I know of that have announced support for TRILL are, in alphabetic order, Broadcom, Fulcrum, Marvel, and Mellanox. (Fulcrum has been acquired by Intel.) Thanks, Donald ========================================== Donald E. Eastlake, 3rd Donald.Eastlake@huawei.com 155 Beaver Street +1-508-333-2270 Milford, MA 01757 USA From: Radia Perlman [mailto:radiaperlman@gmail.com] Sent: Friday, February 24, 2012 9:23 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 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<mailto: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<mailto:radiaperlman@gmail.com>] Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn<mailto:hu.fangwei@zte.com.cn>; rbridge@postel.org<mailto:rbridge@postel.org>; rbridge-bounces@postel.org<mailto: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<mailto: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<mailto:radiaperlman@gmail.com>] Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn<mailto:hu.fangwei@zte.com.cn> Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org<mailto:rbridge@postel.org>; rbridge-bounces@postel.org<mailto: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<mailto: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<mailto:tsenevir@cisco.com>> 发件人: rbridge-bounces@postel.org<mailto:rbridge-bounces@postel.org> 2012-02-23 11:55 收件人 <rbridge@postel.org<mailto: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<mailto:rbridge@postel.org> http://mailman.postel.org/mailman/listinfo/rbridge _______________________________________________ rbridge mailing list rbridge@postel.org<mailto: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)