Re: [rbridge] rbridge Digest, Vol 95, Issue 11
"Rohit Watve (rwatve)" <rwatve@cisco.com> Wed, 11 April 2012 01:42 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 6F31321F8504 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Tue, 10 Apr 2012 18:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 ZsidU9w5cJJQ for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Tue, 10 Apr 2012 18:42:01 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4421F8503 for <trill-archive-Osh9cae4@lists.ietf.org>; Tue, 10 Apr 2012 18:42:01 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3B1W7kv021480; Tue, 10 Apr 2012 18:32:09 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3B1VhY1021444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rbridge@postel.org>; Tue, 10 Apr 2012 18:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rwatve@cisco.com; l=27574; q=dns/txt; s=iport; t=1334107912; x=1335317512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5joaKoS3Mo8kb+WlX6PY2qmbCMPcqs+q+7Z7L22GU8A=; b=mIs2UHGfm6ouj3V1fO30ZNlnRnzM5lkEXMA5mkoJRWgtqUcwuZpaYJwp nO8Ba/GKZ8razcQlo5IsD4xMas00FHmwaEQH6nJ4wd2i2f1oJD4AbUkGY QfeEC1gyl3+/g/ofAa9yBNUOHDm0G96ExZDwU131bVr8eqfB07iBre0ZU s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJHehE+rRDoJ/2dsb2JhbABEuT2BB4IJAQEBAwEBAQEPAQcDEwoUFwgBEAcEAgEIEQMBAQELAgQXAQYBIAYKFQkIAQEEARIIEwIEAYdeAwYEAQuaMpZCDYlTiiSGN2MEiFqOI4oogxSBaYMHgTw
X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="39953972"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 11 Apr 2012 01:31:42 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3B1VfZS002880 for <rbridge@postel.org>; Wed, 11 Apr 2012 01:31:42 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 18:31:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 10 Apr 2012 18:31:39 -0700
Message-ID: <CD31C838133B34469D6E01406350E68C0EBC3AF0@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <CBA42651.1DCB8%varshah@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rbridge] rbridge Digest, Vol 95, Issue 11
Thread-Index: Ac0T6034SFljDH1qDkeyJEPPTEibdwDl34CQ
References: <mailman.2693.1333636671.658.rbridge@postel.org> <CBA42651.1DCB8%varshah@cisco.com>
From: "Rohit Watve (rwatve)" <rwatve@cisco.com>
To: "Varun Shah (varshah)" <varshah@cisco.com>, rbridge@postel.org
X-OriginalArrivalTime: 11 Apr 2012 01:31:41.0853 (UTC) FILETIME=[D91064D0:01CD1782]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: rwatve@cisco.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3B1VhY1021444
Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
+1 for making draft-tissa-trill-cmt-00 a WG draft. Thanks Rohit -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Varun Shah (varshah) Sent: Friday, April 06, 2012 4:49 AM To: rbridge@postel.org Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11 +1 for making draft-tissa-trill-cmt-00 a WG draft. Thanks, -Varun On 4/5/12 7:37 AM, "rbridge-request@postel.org" <rbridge-request@postel.org> wrote: > Send rbridge mailing list submissions to > rbridge@postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.postel.org/mailman/listinfo/rbridge > or, via email, send a message with subject or body 'help' to > rbridge-request@postel.org > > You can reach the person managing the list at > rbridge-owner@postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rbridge digest..." > > > Today's Topics: > > 1. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > 2. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Apr 2012 07:28:38 -0700 > From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Ayan Banerjee (ayabaner)" <ayabaner@cisco.com>, > <rbridge@postel.org> > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > +1 vote in support. > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Ayan Banerjee (ayabaner) > Sent: Wednesday, April 04, 2012 11:03 PM > To: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Yes, I believe that this is an important piece of the puzzle and should > be made a WG document. > > Thanks, > Ayan > ==== > > > > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mailman.postel.org/pipermail/rbridge/attachments/20120405/f43f46e 0/atta > chment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 5 Apr 2012 07:36:47 -0700 > From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Mingui Zhang" <zhangmingui@huawei.com>, "Janardhanan Pathangi > Narasimhan" <jana@force10networks.com> > Cc: rbridge@postel.org > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="gb2312" > > Mingui > > I choose only to answer your last question on "MT is already supported in > TRILL". Why are you saying that ? I do not see any RFC or WG document ? > > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Thursday, April 05, 2012 1:53 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Tissa, > > If one tries hard to search, then he will find each solution has its > drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with > you. But, as I had pointed out in my draft, MTRA is capable to be run in the > same campus and uses other solutions in the base topology. However, I need to > pointed out that the reason why there are not many L3 MT is a historical one. > For switches/bridges, especially when they are used in data center networks, > ECMP and multi-path features are highly desired. For the benefit of the WG, I > don't want to mention the names of TRILL pre-standard implementations and > devices that work like TRILL from other SDOs. I think you can find examples > that support MT. We can talk about this problem offline. > > Personally, the WG voting should not be used as a tool to endorse a solution > before WG members are clear that it is workable and there are other competing > solutions working for an overlapping problem space. IMHO, competing solutions > should be merged or adopted as alternatives. Just as that we allow cheap > local-brand cars to run on same roads along with BMWs. Let customers make > choices themselves. > > Before the final WG decision is made, let me outline the winning advantages of > MTRA for the WG members to consider. > 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in > the same campus as transit or edge nodes. The solutions to communicate with > non-MTRA are depicted in the email to Jon, you can find it. > 2. MTRA realizes traffic segregation which guarantees that a LAG link failure > is isolated in a specific topology. > 3. MTRA is able to converge fast when there is a node/link failure of the > aggregation. > 4. If MT is already supported by TRILL, no extra TLVs are needed. > > Thanks, > Mingui > > >> -----Original Message----- >> From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] >> Sent: Monday, April 02, 2012 11:14 PM >> To: Mingui Zhang; Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> You are assuming a lot. >> >> That is: >> >> 1. People will deploy Multi-topology when they need active-active >> forwarding. >> >> 2. It is easy to deploy and people will like it >> >> 3. It is already out there >> >> >> >> #2 you can check % vise how many MT installations there in L3 world. >> >> >> >> Again I would summarize CMT need only one TLV, MT require lot more TLV >> and require major changes to RFC6326 control plane. >> >> >> >> Backward compatibility of control plane in my world is not an issue as we are >> exchanging more emails than really trying to deploy RBridges and there are no >> RBridges there forwarding packets in real networks. >> >> >> >> However, your claim that MT is backward compatible without any tweaks is >> false (Jana has pointed out several times). >> >> >> >> Like I have said, many times before, MT approach you have may be utilized >> for active-active forwarding in MT installations. I will support that >> solution as >> an optimization for MT, certainly I **do not** support it as the only >> solution >> for all active-active deployments. If we agree on that then we have consensus >> and both work can move forward (we need to make progress). If not then we >> can continue to disagree and I request WG chairs to decide via a vote on >> making CMT a WG document. >> >> >> >> >> >> Thanks >> >> Tissa >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Monday, April 02, 2012 7:54 AM >> To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Tissa, >> >> >> >> We know that RBridge Aggregation is used to increase the access capacity >> without upgrade of the RBridges. The motivation is the same as the >> traditional >> LAG: it will help customers to reduce their investment. If active-active >> multi-homing can work well, customers will eager to purchase MT feature. It >> may even act as a factor that promotes MT-TRILL, who knows. >> >> >> >> On the other hand, since MTRA is backward compatible, it allows other >> non-MTRA solutions co-exist in the campus. These solutions work in the base >> topology. These solutions may include tunneling approach. As we know, >> tunneling had been widely used on traditional switches. If there are >> customers who really do not like MT, just use tunneling approach or others. >> >> >> >> However, I don't think that multi-topology is that expensive. I believe you >> have heard of silicons or implementations already support multi-topology >> feature before 2010 when RFC 6325 was published. >> >> >> >> Thanks, >> >> Mingui >> >> >> >> ________________________________ >> >> ??????: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] >> ????????: 2012??4??2?? 0:27 >> ??: Janardhanan Pathangi Narasimhan; Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> I have not seen an answer for the questions below could you please answer >> simple question: >> >> >> >> What is your proposal for active-active for people who do not want to run >> multi-topology ? >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:37 AM >> To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui >> Zhang' >> Cc: 'rbridge@postel.org' >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Small typo correction >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:25 AM >> To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Jana is absolutely correct on the observation below. >> >> >> >> One more point to add, as have indicated earlier >> >> >> >> 1. Not all customer will run multi-topology >> >> 2. You cannot force customers to run multi-topology when they need >> active-active forwarding >> >> 3. What is your solution for customers who *do NOT* want to run >> multi-topology ? >> >> >> >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Janardhanan Pathangi Narasimhan >> Sent: Friday, March 30, 2012 12:30 AM >> To: Mingui Zhang >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Mingui >> >> >> >> When you realize active-active, you are asking for the active-active to be >> setup in a new topology and not the base topology. So these nodes which >> need to talk to the other nodes which are behind non-MT RBridges cannot do >> so any more. >> >> >> >> Specifically for MT to be backward compatible, you need all nodes which >> want to talk to each other part of the base topology. If you do that you >> cannot >> realize active-active. If you put the active-active in a new topology, than >> they >> can no longer talk to nodes on the base topology of non-MT RBridges. >> >> >> >> So yes, MT-TRILL is backward compatible for base topology, but the >> realization >> of active-active with MT ?C TRILL is not backward compatible. That was the >> point I was bringing up. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:15 PM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Jana, >> >> >> >> All RBridges in the campus are in the base topology. MT RBridges can well >> communicate with non-MT RBridges using the base topology. >> >> >> >> I feel that you are arguing that MT-TRILL is not backward compatible. That is >> a >> incorrect judgement. >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??30?? 13:29 >> ??: Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui, >> >> >> >> With MT approach, when two RBridges which had stations talking to each >> other and one of them is converted to MT, then the communication is broken. >> So it does not have backward computability. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:27 AM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Jana, >> >> >> >> Let us assume that I have 20 RBridges in the campus which have end systems >> connected to it, and all of them need to be reachable. So if a few of them >> are >> converted to MTRA RBridges to support active-active, does it mean that >> RBridges which are not yet converted will not be able to anymore see the >> nodes connected to these virtual RBridges? Or am I missing something here? >> >> >> >> ZMG> Although physical reachability can be all to all, it does not mean than >> the end systems will really communicate in an all to all manner. It is >> restricted >> by the VLAN configuration of the campus. Let me give you an example, RB1, >> RB2, RB3 and RB4 have an all to all connection. The access ports of RB1 and >> RB3 are configured as the VLAN for end systems of the Dept of Computer >> Science while the access ports of RB2 and RB4 are configured as another VLAN >> for end systems of the Dept of Literature. End systems from the same >> department can talk with each other. But end systems from two different >> departments will not talk with each other. >> >> >> >> I am not sure if that is practical, and always possible may depend on the >> nodes >> connected and also what controls are available on them >> >> >> >> ZMG> Think about it. When an operator have a LAG connected to a group of >> RBridges, he has to decide which port to plug the cables in. He need enter >> the >> console window to input the command line to configure parameters and start >> the LAG. He also need to configure the tuple used for hashing. >> >> >> >> Thanks, >> >> Mingui >> >> >> >> >> >> >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??30?? 0:49 >> ??: Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui, >> >> >> >> I am slightly confused. >> >> >> >> For the intra-topology scenario, MT unaware RBridges will not appear in a >> specific topology other than the based topology. In other words, MTRA >> RBridges only talks only with MTRA RBridges. Since they all support MT, MTRA >> can work very well among them. In this scenario, MTRA RBridges and old >> RBridges co-exist in the same campus. Therefore, this is a solid example that >> MTRA can be deployed incrementally. Remember, CMT does not allow such >> kind of deployment. >> >> >> >> Let us assume that I have 20 RBridges in the campus which have end systems >> connected to it, and all of them need to be reachable. So if a few of them >> are >> converted to MTRA RBridges to support active-active, does it mean that >> RBridges which are not yet converted will not be able to anymore see the >> nodes connected to these virtual RBridges? Or am I missing something here? >> >> >> >> For the inter-topology scenario, we assume MTRA RBridges have to talk with >> MT unaware RBridges (This is a rigorous assumption.) If operators do want to >> realize such kind of connection, it is reasonable to assume they will accept >> the >> requirement that they need to configure their hashing function to remove >> the possible MAC flip-flop. >> >> >> >> I am not sure if that is practical, and always possible may depend on the >> nodes >> connected and also what controls are available on them >> >> >> >> Thanks >> >> Jana >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: rbridge-bounces@postel.org [rbridge-bounces@postel.org] ???? >> Mingui Zhang [zhangmingui@huawei.com] >> ????????: 2012??3??29?? 18:50 >> ??: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> ????: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Jana, >> >> >> >>> In section 4.1, could you please explain how the frame that is ingressed by >> RB1 through RBv001 is received at RBx? >> >> >> >> Two scenarios are given in Section 4. Section 4.1 talks about the >> intra-topology >> scenario. Here, RBx is not in topology 1 so it is unreachable by RB1. It need >> not >> set up any forwarding path to RBx. >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??28?? 22:52 >> ??: Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui, >> >> >> >> Section 4, does not give backward compatibility. For e.g. in section 4.2 >> multi >> destination frames will be ingressed with two different bridge ID causing MAC >> move, and having to impose restrictions on hashing functions at the external >> node may or may not be acceptable . I am not sure that this can be classified >> as backward compatible since it is not a full solution and can also cause >> frequent MAC flip flops etc. >> >> >> >> In section 4.1, could you please explain how the frame that is ingressed by >> RB1 through RBv001 is received at RBx? >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Wednesday, March 28, 2012 7:15 PM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Jana, >> >> >> >> I think I should answer your question. I am Mingui Zhang. >> >> Please refer to the draft >> http://tools.ietf.org/html/draft-zhang-trill-multi-topo-rpfc-00. Section 4 is >> right for the topic you are interested. As a starter draft on the RPFC using >> Multi-topology. I will be happy to receive your comments. >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??28?? 19:14 >> ??: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne >> (tsenevir) >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Zhai, >> >> >> >> In the Multi-topology case I am not sure what is meant by incrementally >> deployable. Assuming that all the RBridges in the campus do not understand >> MT except for the RBridges which participate in the Virtual RBrodge, it looks >> like this will cause MAC flip flop on the other RBridges and other issues >> since >> all the other RBridges do not understand MT. >> >> >> >> Could you please explain how MT can work in such scenarios? >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Rohit Watve (rwatve) >> Sent: Wednesday, March 28, 2012 3:53 PM >> To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir) >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Mingui, >> >> 5. Fast convergence on failure recovery. We know that resilience is one of >> the >> two main purposes of "aggregation". This dimension discusses whether the >> solution offers a way to do fast failure recovery when there is a failure of >> an >> aggregated RBridge or link. >> >> PN: NO. The new distribution tree need to be recomputed. >> >> CMT: NO. A overall re-configuration is necessary. >> >> MTRA: YES. >> >> CMT does not need reconfiguration. If one Rbridge advertizing affinity tlv >> goes down, the tree can be rooted at the other Egress Rbridge ID advertizing >> affinity tlv. >> >> Also, consider adding following to the comparison table >> >> Number of New TLVs (and resulting complexity) >> >> PN: 3 >> >> CMT: 1 >> >> MTRA: multiple >> >> Thanks >> Rohit >> >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Mingui Zhang >> Sent: Wednesday, March 28, 2012 2:10 AM >> To: Radia Perlman; Tissa Senevirathne (tsenevir) >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Radia, >> >> It is a good idea to list the Pros and Cons of each solution. There are three >> candidate solutions for the same RPFC problem: PN, CMT and MTRA >> (Multi-Topology TRILL for RBridge Aggregation). Let me compare them in the >> following dimensions. >> >> 1. Whether the solution is incrementally deploy-able. >> >> PN: YES. >> >> CMT: NO. >> >> MTRA: YES. >> >> 2. Use only existing silicons. >> >> PN: NO. New silicon is necessary to support "tunneling" or else MAC >> addresses may flip-flop. >> >> CMT: YES. >> >> MTRA: Currently NO. But after multi-topology is supported by TRILL, it is a >> "YES". >> >> 3. Multi-cast traffic up from RBv can be load-balanced. >> >> PN: NO. >> >> CMT: YES. >> >> MTRA: YES. >> >> 4. Multi-cast traffic down to RBv can be load-balanced. >> >> PN: NO. >> >> CMT: YES. >> >> MTRA: YES. >> >> 5. Fast convergence on failure recovery. We know that resilience is one of >> the >> two main purposes of "aggregation". This dimension discusses whether the >> solution offers a way to do fast failure recovery when there is a failure of >> an >> aggregated RBridge or link. >> >> PN: NO. The new distribution tree need to be recomputed. >> >> CMT: NO. A overall re-configuration is necessary. >> >> MTRA: YES. >> >> The following table lists all above comparisons (A jpg version is also >> attached >> just in case.). MTRA is always YES. I think it deserves our follow-up. >> >> +--------+------------+-----------+----------+------------+------------- + >> >> |Solution|Incre-Deploy|Old Silicon|LB Upwards|LB Downwards|Fast >> Converge| >> >> +--------+------------+-----------+----------+------------+------------- | >> >> |PN |YES |NO |NO |NO |NO >> | >> >> +--------+------------+-----------+----------+------------+------------- | >> >> |CMT |NO |YES |YES |YES |NO >> | >> >> +--------+------------+-----------+----------+------------+------------- | >> >> |MTRA |YES |YES(will) |YES |YES |YES >> | >> >> +--------+------------+-----------+----------+------------+------------- + >> >> Thanks, >> >> Mingui >> >> >> >> ??????: rbridge-bounces@postel.org [rbridge-bounces@postel.org] ???? >> Radia Perlman [radiaperlman@gmail.com] >> >> ????????: 2012??3??28?? 12:52 >> >> ??: Tissa Senevirathne (tsenevir) >> >> Cc: rbridge@postel.org >> >> ????: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> It is my understanding that >> >> a) CMT does require changing all the RBs in the campus >> >> b) CMT requires there be at least as many trees as there are active/active >> RBs >> on any link >> >> >> >> Of course, no solution is ideal. It might have been nice to write up all the >> proposed solutions to this and pros/cons. Maybe it's >> >> still worth doing. >> >> >> >> So from memory...other proposals for allowing R1, R2, and R3 to be >> active/active/active on a link: >> >> >> >> First note: regardless of whether their port to the link is in a tree, >> unicast >> works, and they can use the pseudonode >> >> nickname when encapsulating unicast. >> >> >> >> Also, if Ri's port to the link is in at least one tree, Ri can use the >> pseudonode >> nickname for that link when encapsulating >> >> multidestination frames for ingress, and the RPF check will work without any >> problems. >> >> >> >> However, if Ri's port to the link is not in any of the trees, >> >> here were some of the proposed solutions. So, let's say that R1 and R2's >> port to the shared link is in at least one tree, and R3's >> >> port to the link is not in any of the trees, and R3 needs to encapsulate a >> multidestination frame: >> >> >> >> 1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet >> (with >> pseudonode nickname) into the campus. >> >> >> >> Pro: Doesn't affect any RBs other than the ones on the link; backwards >> compatible. Con: more hops, might be difficult >> >> in some implementations for R3 to forward by tunneling, might be difficult >> for >> R2 to accept a tunneled packet. >> >> >> >> 2) R3 could use its own nickname instead of the pseudonode nickname in this >> case >> >> >> >> Pro: Doesn't affect any RBs other than the ones on the link; backwards >> compatible. Con: MAC learning in distant RBs will have >> >> frequent learning changes of the source MAC S between being on the >> pseudonode nickname (whenever S sends unicast, >> >> or multicast through R1 or R2), or being on R3 (when R3 has to encapsulate a >> multidestination frame from S). >> >> >> >> ------ >> >> There might have been some other proposals, but they wound up not to >> work. >> >> >> >> Personally, I don't love the CMT thing because of the two disadvantages I >> mentioned above, but I can live with it. >> >> >> >> Radia >> >> > > > > > ------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > End of rbridge Digest, Vol 95, Issue 11 > *************************************** _______________________________________________ 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
- Re: [rbridge] rbridge Digest, Vol 95, Issue 11 Naveen Nimmu
- Re: [rbridge] rbridge Digest, Vol 95, Issue 11 varshah
- Re: [rbridge] rbridge Digest, Vol 95, Issue 11 Rohit Watve (rwatve)