Subject: 答复: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

From: Mingui Zhang <[email-masked]>
Date: Sun, 01 Apr 2012 15:09:09 +0000

Hi Jon,

Please see my comments below.

If I may make one minor point, the last statement is not correct. 

ZMG> Yes, I am happy to hear your comment.

I know of two solutions (one shipping) where default hash parameters are set and where any two cables plugged into the same two RBridges will auto create a LAG.
Not directly pertinent to the conversation at hand, but manual input is not a given. Zero-config is the goal for many of us.

ZMG> I agree with you. I retrieve the statement about hashing. LAG can work without *manual* configuration of hashing function. I give three suggestions to solve this issue.

1. In practice, if vendors providing the CE devices along with the RBridges, they can set the hashing function not using mac_destination ip_destination to determine the outgoing port. 

2. For those non MT RBridges, they can only recognize the base topology. Aggregated RBridges should resort to tunneling approach in order to send multicast traffic to them.

3. RBv001 and RBv010 are advertised as two nicknames besides RBv000 in the base topology. Then non MT RBridges can deem RBv as one RBridge (one ISIS ID) who has three nicknames (RBv000, RBv001 and RBv010). Then non MT RBridges should learn MACs from RBv using a single nickname with the highest priority. Then the MAC flip-flop problem is conquered.

Thanks,
Mingui

发件人: Jon Hudson [[email-masked]]

发送时间: 2012年3月30日 19:56

到: Mingui Zhang

Cc: Janardhanan Pathangi Narasimhan; [email-masked]

主题: Re: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

If I may make one minor point, the last statement is not correct. 

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.

I know of two solutions (one shipping) where default hash parameters are set and where any two cables plugged into the same two RBridges will auto create a LAG.

Not directly pertinent to the conversation at hand, but manual input is not a given. Zero-config is the goal for many of us.

Just a side note.

Jon

On Mar 29, 2012, at 8:56 PM, Mingui Zhang <[email-masked]> wrote:

<!--
@font-face
	{font-family:SimSun}
@font-face
	{font-family:"MS Gothic"}
@font-face
	{font-family:MingLiU}
@font-face
	{font-family:"Cambria Math"}
@font-face
	{font-family:Calibri}
@font-face
	{font-family:Tahoma}
@font-face
	{font-family:Consolas}
@font-face
	{font-family:"\@SimSun"}
@font-face
	{font-family:"\@MS Gothic"}
@font-face
	{font-family:"\@MingLiU"}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:SimSun}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif"}
span.BalloonTextChar
	{font-family:"Tahoma","sans-serif"}
p.msochpdefault, li.msochpdefault, div.msochpdefault
	{margin-right:0in;
	margin-left:0in;
	font-size:10.0pt;
	font-family:SimSun}
span.balloontextchar0
	{font-family:"Tahoma","sans-serif"}
span.balloontextchar00
	{font-family:"Tahoma","sans-serif"}
span.emailstyle20
	{font-family:"Calibri","sans-serif";
	color:#1F497D}
span.emailstyle23
	{font-family:"Calibri","sans-serif";
	color:#1F497D}
span.EmailStyle25
	{font-family:"Calibri","sans-serif";
	color:#1F497D}
.MsoChpDefault
	{font-size:10.0pt}
@page WordSection1
	{margin:1.0in 1.0in 1.0in 1.0in}
-->

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 [[email-masked]]

发送时间: 2012年3月30日 0:49

到: Mingui Zhang

Cc: 
[email-masked]

主题: 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

发件人:

[email-masked] [[email-masked]]
代表 Mingui Zhang [[email-masked]]

发送时间: 2012年3月29日
 18:50

到: Janardhanan
 Pathangi Narasimhan

Cc: 
[email-masked]

主题:
答复: [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 [[email-masked]]

发送时间: 2012年3月28日
 22:52

到: Mingui
 Zhang

Cc: 
[email-masked]

主题: 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:[email-masked]]

Sent: Wednesday, March 28, 2012 7:15 PM

To: Janardhanan Pathangi Narasimhan

Cc: 
[email-masked]

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 [[email-masked]]

发送时间: 2012年3月28日
 19:14

到: Rohit
 Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)

Cc: 
[email-masked]

主题: 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:

[email-masked] [mailto:[email-masked]]
On Behalf Of Rohit Watve (rwatve)

Sent: Wednesday, March 28, 2012 3:53 PM

To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)

Cc: 
[email-masked]

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: 
[email-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang

Sent: Wednesday, March 28, 2012 2:10 AM

To: Radia Perlman; Tissa Senevirathne (tsenevir)

Cc: 
[email-masked]

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
 
发件人:

[email-masked] [[email-masked]]
代表
Radia Perlman [[email-masked]]
发送时间: 2012年3月28日
 12:52
到: Tissa Senevirathne (tsenevir)
Cc: 
[email-masked]
主题: 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

[email-masked]

http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sun, 1 Apr 2012 09:27:49 -0700

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: [email-masked]'
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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Janardhanan Pathangi Narasimhan
Sent: Friday, March 30, 2012 12:30 AM
To: Mingui Zhang
Cc: [email-masked]
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 – TRILL is not backward compatible. That was the point I was bringing up.

Thanks

Jana

From: Mingui Zhang [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi Narasimhan
Cc: [email-masked]
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

________________________________

发送时间: 2012年3月30日 13:29
Cc: [email-masked]

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:[email-masked]] 
Sent: Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathangi Narasimhan
Cc: [email-masked]
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.

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

________________________________

Cc: [email-masked]

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. 

Thanks

Jana

Thanks,

Mingui

________________________________

发件人: [email-masked] [[email-masked]] 代表 Mingui Zhang [[email-masked]]
发送时间: 2012年3月29日 18:50
到: Janardhanan Pathangi Narasimhan
Cc: [email-masked]
主题: 答复: [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

________________________________

发送时间: 2012年3月28日 22:52
Cc: [email-masked]

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.

Thanks

Jana

Cc: [email-masked]

Hi Jana, 

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 [[email-masked]]
发送时间: 2012年3月28日 19:14
到: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
主题: 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.

Thanks

Jana

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rohit Watve (rwatve)
Sent: Wednesday, March 28, 2012 3:53 PM
To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
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. 

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.

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Wednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
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.

PN: YES.

CMT: NO.

MTRA: YES.

CMT: YES.

PN: NO.

CMT: YES.

MTRA: YES.

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. 

MTRA: YES. 

Thanks,

Mingui

发件人: [email-masked] [[email-masked]] 代表 Radia Perlman [[email-masked]]

发送时间: 2012年3月28日 12:52

Cc: [email-masked]

still worth doing.

------

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 02 Apr 2012 14:53:51 +0000

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) [[email-masked]]
发送时间: 2012年4月2日 0:27
到: Janardhanan Pathangi Narasimhan; Mingui Zhang
Cc: [email-masked]
主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

Small typo correction

Cc: [email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Janardhanan Pathangi Narasimhan
Sent: Friday, March 30, 2012 12:30 AM
To: Mingui Zhang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

Thanks
Jana

Cc: [email-masked]<mailto:[email-masked]>

Hi Jana,

Thanks,
Mingui
________________________________
发件人: Janardhanan Pathangi Narasimhan [[email-masked]]
发送时间: 2012年3月30日 13:29
到: Mingui Zhang
Cc: [email-masked]<mailto:[email-masked]>
主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Hi Mingui,

Thanks
Jana

Cc: [email-masked]<mailto:[email-masked]>

Hi Jana,

Thanks,
Mingui

________________________________
发件人: Janardhanan Pathangi Narasimhan [[email-masked]]
发送时间: 2012年3月30日 0:49
到: Mingui Zhang
Cc: [email-masked]<mailto:[email-masked]>
主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Hi Mingui,

I am slightly confused.

Thanks
Jana

Thanks,
Mingui
________________________________
发件人: [email-masked]<mailto:[email-masked]> [[email-masked]] 代表 Mingui Zhang [[email-masked]]
发送时间: 2012年3月29日 18:50
到: Janardhanan Pathangi Narasimhan
Cc: [email-masked]<mailto:[email-masked]>
主题: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Hi Jana,

Thanks,
Mingui
________________________________
发件人: Janardhanan Pathangi Narasimhan [[email-masked]]
发送时间: 2012年3月28日 22:52
到: Mingui Zhang
Cc: [email-masked]<mailto:[email-masked]>
主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Hi Mingui,

Thanks
Jana

Cc: [email-masked]<mailto:[email-masked]>

Hi Jana,

Thanks,
Mingui
Cc: [email-masked]<mailto:[email-masked]>

Thanks
Jana

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rohit Watve (rwatve)
Sent: Wednesday, March 28, 2012 3:53 PM
To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

MTRA: YES.

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Wednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

PN: YES.

CMT: NO.

MTRA: YES.

CMT: YES.

PN: NO.

CMT: YES.

MTRA: YES.

PN: NO.

CMT: YES.

MTRA: YES.

MTRA: YES.

Thanks,

Mingui

发件人: [email-masked]<mailto:[email-masked]> [[email-masked]] 代表 Radia Perlman [[email-masked]]

发送时间: 2012年3月28日 12:52

Cc: [email-masked]<mailto:[email-masked]>

still worth doing.

------

Radia

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 2 Apr 2012 08:14:27 -0700

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:[email-masked]] 
Sent: Monday, April 02, 2012 7:54 AM
To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa,

Thanks,

Mingui

Hi Mingui

Small typo correction 

Hi Mingui

Thanks

Jana

Hi Jana, 

Thanks,

Mingui

Hi Mingui,

Thanks

Jana

Hi Jana, 

Thanks,

Mingui

Hi Mingui,

I am slightly confused. 

Thanks

Jana

Thanks,

Mingui

Hi Jana, 

Thanks,

Mingui

Hi Mingui,

Thanks

Jana

Hi Jana, 

Thanks,

Mingui

Hi Zhai,

Thanks

Jana

Hi Mingui,

MTRA: YES.

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Wednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

PN: YES.

CMT: NO.

MTRA: YES.

CMT: YES.

PN: NO.

CMT: YES.

MTRA: YES.

PN: NO.

CMT: YES.

MTRA: YES.

MTRA: YES. 

Thanks,

Mingui

发送时间: 2012年3月28日 12:52

Cc: [email-masked]

still worth doing.

------

Radia

---

From: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Mon, 2 Apr 2012 21:15:05 +0530

Hi Tissa,

a) In terms of control plane states and work, I think MT is much more heavy and also if all elements have to be in all topologies (for the sake of active-active), that would increase the states on all nodes

So I agree with you that yes MT may be usable as active-active solution, but it would be wrong to say that MT is a better active-active or should be mainly used for active-active mode.

Thanks
Jana

From: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
Sent: Monday, April 02, 2012 8:44 PM
To: Mingui Zhang; Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

You are assuming a lot.
That is:

Thanks
Tissa

Hi Tissa,

Thanks,
Mingui

Small typo correction

Hi Mingui

Thanks
Jana

Hi Jana,

Thanks,
Mingui

Thanks
Jana

Hi Jana,

Thanks,
Mingui

I am slightly confused.

Thanks
Jana

Thanks,
Mingui

Thanks,
Mingui

Thanks
Jana

Hi Jana,

Thanks,
Mingui

Thanks
Jana

Hi Mingui,

MTRA: YES.

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Wednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

PN: YES.

CMT: NO.

MTRA: YES.

CMT: YES.

PN: NO.

CMT: YES.

MTRA: YES.

PN: NO.

CMT: YES.

MTRA: YES.

MTRA: YES.

Thanks,

Mingui

发送时间: 2012年3月28日 12:52

still worth doing.

------

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 05 Apr 2012 08:53:00 +0000

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

   > Sent: Monday, April 02, 2012 11:14 PM
   > 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
   > 
   > 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
   > 
   > 
   > 
   > From: [email-masked] [mailto:[email-masked]] On
   > Behalf Of Janardhanan Pathangi Narasimhan
   >   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 – TRILL is not backward compatible. That was the
   > point I was bringing up.
   > 
   > 
   > 
   > Thanks
   > 
   > Jana
   > 
   > 
   > 
   > 
   > 
   > All RBridges in the campus are in the base topology. MT RBridges can well
   > communicate with non-MT RBridges using the base topology.
   > 
   > 
   > 
   > 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
   > 
   > 
   > 
   > 
   > 
   > 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
   > 
   > 
   > 
   > 
   > 
   > 
   > 
   > 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
   > 
   > 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
   > 
   > 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.
   > 
   > 
   > 
   > 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
   > 
   > 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.
   > 
   > 
   > 
   > 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.
   > 
   > 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.
   > 
   > 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.
   > 
   > 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.
   > 
   > 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.
   > 
   > 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.
   > 
   > 
   > 
   > 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
   > 
   > 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
   > 
   > Pro: Doesn't affect any RBs other than the ones on the link; backwards
   > compatible.  Con: more hops, might be difficult
   > 
   > 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,
   >

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 5 Apr 2012 07:36:47 -0700

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:[email-masked]] 
Sent: Thursday, April 05, 2012 1:53 AM
To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa,

Thanks,
Mingui

   > Behalf Of Rohit Watve (rwatve)
   > Behalf Of Mingui Zhang

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 06 Apr 2012 03:18:07 +0000

Tissa,

That is why I use an "If" to start that sentence. When you referred to it, you omitted that word.

I believe multi-topology is very important to TRILL and customers. We are going to work on it in the near future. If you ever looked at the individual drafts submitted for this WG, you would find there was a draft http://tools.ietf.org/html/draft-eastlake-trill-rbridge-multi-topo-02. I believe it was written up for making multi-topology TRILL a reality.

Thanks,
Mingui

   > Sent: Thursday, April 05, 2012 10:37 PM
   > 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 ?
   > 
   > 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.
   > 
   > 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.
   >    > 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 ?
   >    >
   >    >
   >    >
   >    > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan';
   > 'Mingui
   >    > Zhang'
   >    > Cc: [email-masked]'
   >    > 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 ?
   >    >
   >    >
   >    >
   >    > I feel that you are arguing that MT-TRILL is not backward compatible.
   > That is a
   >    > incorrect judgement.
   >    >
   >    >
   >    >
   >    > Thanks,
   >    >
   >    > Mingui
   >    >
   >    > 发件人: [email-masked] [[email-masked]] 代
   > 表
   >    > Mingui Zhang [[email-masked]]
   >    > 发送时间: 2012年3月29日 18:50
   >    > >In section 4.1, could you please explain how the frame that is ingressed
   > by
   >    > RB1 through RBv001 is received at RBx?
   >    >
   >    >
   >    >
   >    > In section 4.1, could you please explain how the frame that is ingressed
   > by
   >    > RB1 through RBv001 is received at RBx?
   >    >
   >    >
   >    >
   >    > Thanks
   >    >
   >    > Jana
   >    >
   >    >
   >    >
   >    >
   >    >
   >    > 到: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa
   > Senevirathne
   >    > (tsenevir)
   >    > Cc: [email-masked]
   >    > MTRA: Currently NO. But after multi-topology is supported by TRILL, it is
   > a
   >    > "YES".
   >    >
   >    > |PN      |YES         |NO         |NO        |NO
   > |NO
   >    > |
   >    > |CMT     |NO          |YES        |YES       |YES
   > |NO
   >    > |
   >    > 发件人: [email-masked] [[email-masked]] 代
   > 表
   >    > b) CMT requires there be at least as many trees as there are
   > active/active RBs
   >    > on any link
   >    >
   >    >
   >    >
   >    > multidestination frames for ingress, and the RPF check will work without
   > any
   >    > problems.
   >    >
   >    >
   >    >
   >    > 1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet
   > (with
   >    > pseudonode nickname) into the campus.
   >    >
   >    >
   >    >
   >    > 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
   >    >
   >    >
   >    >
   >    > or multicast through R1 or R2), or being on R3 (when R3 has to
   > encapsulate a
   >    > multidestination frame from S).
   >    >
   >    >
   >    >
   >    > ------
   >    >
   >    > Personally, I don't love the CMT thing because of the two disadvantages
   > I
   >    > mentioned above, but I can live with it.
   >    >
   >    >
   >    >
   >    > Radia
   >    >
   >    >

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 6 Apr 2012 19:59:38 -0700

Mingui

My last response on this subject:

Basic point being: Not all customers going to run multi-topology. We need a solution for people who do not use multi-topology. Your solution does not work for the people who do not want to run MT.

Having few drafts does not indicate any readiness of a solution nor acceptance of it nor deployment by all customers.

I rest my case!.

Thanks
Tissa

-----Original Message-----
From: Mingui Zhang [mailto:[email-masked]] 
Sent: Thursday, April 05, 2012 8:18 PM
To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Tissa,

Thanks,
Mingui