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