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

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Mar 2012 18:38:19 -0400

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
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

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

---

From: [email-masked]
Date: Tue, 27 Mar 2012 12:41:02 +0800

Hi,all

We have discussed that there is back compatibility issue for CMT. Only if 
all the member RBridge of a virtual group support Affinity sub-tlv, the 
CMT can work correctly. If one of the member does't announce the virtual 
RBridge nickname and the Affinity sub-tlv, there may exist RPC check 
failure for the virtual RBridge. The issue that CMT try to solve is not an 
essential and key issue for trill, and CMT should be a optional solution. 
Some RBridges may not implement the feature. I wonder whether the CMT will 
does work actually because of the back compatibility issue.

There is another solution (pseudonode nickname) solves the same issue. I 
suggest we should do further discussion with CMT and compare with the two 
solutions.

Thanks

Donald Eastlake <[email-masked]> 
发件人:  [email-masked]
2012-03-27 06:38

收件人
[email-masked]
抄送

主题
[rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Thanks,
Donald

---

From: Jon Hudson <[email-masked]>
Date: Tue, 27 Mar 2012 11:44:04 +0200

I disagree that this functionality is not essential to TRILL. 

Many customers I have spoken to have been disapointed that multicast does not get the same active/active advantages as unicast in TRILL.

The CMT solution has already seen a very positive response from customers I have explained it to and I am quite excited about eventually implementing this feature.

Even on Twitter yesterday they where people talking about and sharing info on this proposal.

Jon

On Mar 27, 2012, at 6:41 AM, [email-masked] wrote:

> 
> Hi,all 
> 
> We have discussed that there is back compatibility issue for CMT. Only if all the member RBridge of a virtual group support Affinity sub-tlv, the CMT can work correctly. If one of the member does't announce the virtual RBridge nickname and the Affinity sub-tlv, there may exist RPC check failure for the virtual RBridge. The issue that CMT try to solve is not an essential and key issue for trill, and CMT should be a optional solution. Some RBridges may not implement the feature. I wonder whether the CMT will does work actually because of the back compatibility issue. 
> 
> There is another solution (pseudonode nickname) solves the same issue. I suggest we should do further discussion with CMT and compare with the two solutions. 
> 
> Thanks
> 
> 
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 27 Mar 2012 03:12:23 -0700

Hi Hu

CMT draft discuss about backward compatibility  and your assessment of RPF failure when older RBridges present is incorrect.

Additionally I am not clear PN draft can be utilized for the scenario described in the CMT. Per the discussion we have in Taipie, most Data Centers and Enterprise have multi home devices connected to the TRILL edge. They will not let LAN Hello to pass through them because of the LAG bundling at the edge. Please refer to the reference topology in the draft. Hence CMT draft address very crucial deployment scenario.

Thanks

Tissa

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [email-masked]; [email-masked]
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi,all 

Thanks

2012-03-27 06:38 

收件人

[email-masked] 

抄送

主题

		

Thanks,
Donald

---

From: [email-masked]
Date: Tue, 27 Mar 2012 19:18:47 +0800

Hi Tissa

In your CMT draft, if one old RBridge is momitored not supporting 
affinitive-TLV, the CMT function will be disbale in all the TRILL campus. 
In my mind, that's your discussion for backward compatibility in CMT. So 
CMT can not work until all the RBridges support affinitive-TLV.

However, in the PN draft, there is no such backward compatibiltiy. PN 
draft employs pseudo-LSP to announce the pseudo-nickname and members of a 
virtual RBridge. If the pseudo-nickname and the members are configured 
statically by network administors, no hello PDUs are necessary between the 
members of a virtual RB group. So the pseudo-LSP method given in PN draft 
can also work for the scenario described in your CMT draft.

Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <[email-masked]> 
发件人:  [email-masked]
2012-03-27 18:12

收件人
<[email-masked]>, "Donald Eastlake" <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Hu
 
CMT draft discuss about backward compatibility  and your assessment of RPF 
failure when older RBridges present is incorrect.
 
Additionally I am not clear PN draft can be utilized for the scenario 
described in the CMT. Per the discussion we have in Taipie, most Data 
Centers and Enterprise have multi home devices connected to the TRILL 
edge. They will not let LAN Hello to pass through them because of the LAG 
bundling at the edge. Please refer to the reference topology in the draft. 
Hence CMT draft address very crucial deployment scenario.
 
Thanks
Tissa
 
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of [email-masked]
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [email-masked]; [email-masked]
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi,all 

Thanks

收件人
[email-masked] 
抄送

主题

Thanks,
Donald

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Tue, 27 Mar 2012 21:39:24 +0530

Hi Zhai,

Few points:

1) In figure 2 of the CMT draft, the nodes CE1, CE2 etc. treat their links to RB1, RB2… RBk as a LAG. Hence if RB1 sends a TRILL hello frame on this link towards CE1, this will not be received by any of the other RBridges RB2, .. RB4. Hence the concept of AF will not be applicable in this scenario

2)  In the PN draft, only the AF will forward all traffic into and out of this network, and this is because it is regular Ethernet link. But in the CMT draft the links are all LAGs, and hence the traffic (for e.g. broadcast from CE1) is sent to only one of the RB1 and not to all of them.

  So I think the problem space that these two drafts are discussing are different, and the Pseudo Node draft will not be applicable to the LAG active-active load balancing scenarios described in the CMT draft.

Thanks
Jana

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa

In your CMT draft, if one old RBridge is momitored not supporting affinitive-TLV, the CMT function will be disbale in all the TRILL campus. In my mind, that's your discussion for backward compatibility in CMT. So CMT can not work until all the RBridges support affinitive-TLV.

However, in the PN draft, there is no such backward compatibiltiy. PN draft employs pseudo-LSP to announce the pseudo-nickname and members of a virtual RBridge. If the pseudo-nickname and the members are configured statically by network administors, no hello PDUs are necessary between the members of a virtual RB group. So the pseudo-LSP method given in PN draft can also work for the scenario described in your CMT draft.

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345
Email: [email-masked]<mailto:[email-masked]>
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012-03-27 18:12

收件人

<[email-masked]<mailto:[email-masked]>>, "Donald Eastlake" <[email-masked]<mailto:[email-masked]>>

抄送

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

主题

Hi Hu

Thanks
Tissa

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi,all

Thanks
Donald Eastlake <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012-03-27 06:38

收件人

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

抄送

主题

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked]<mailto:[email-masked]>

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

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 27 Mar 2012 21:11:19 +0000

Yes, CMT is incapable to be incrementally deployed in an RBridges campus. It requires that all RBridges in one campus to be updated to support the Affinity TLV.

Actually, the capability that Multi-Topology TRILL can physically segregate data traffic can be used to solve the same RPFC problem in the active-active multi-homing. And, it can be designed to be well "incrementally deploy-able".

Best regards,
Mingui

________________________________
发件人: [email-masked] [[email-masked]] 代表 [email-masked] [[email-masked]]
发送时间: 2012年3月27日 19:18
到: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; [email-masked]; [email-masked]
主题: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12

收件人

Hi Hu

Thanks
Tissa

Hi,all

Thanks

2012-03-27 06:38

收件人

主题

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 27 Mar 2012 15:50:21 -0700

Mingui

We have had these discussions before and to recapping below for the benefit of the WG mailist:

1.       Multi topology is a complex solution that involve lot more than a single TLV. Using multi-topology to solve this is like taking canon to kill a mosquito

2.       TRILL deployments are in it’s infancy (to the point nonexistent in  deployments)  and these backward compatibility issues you are talking is simply academic at this time. Bringing multi topology to Just to solve that academic scenario is making it more complex than what is required. (Note: we do have backward compatibility mode)

3.       What we need right now is a simpler solution to support active-active edge

4.       Lastly not all people need active-active deployments may *not* even want to run multi-topology. So tying active-active to multi-topology is saying everyone must deploy multi-topology if and when they need active-active solution. Which is non starter in most deployments.

In summary: If you have great ideas on how to use multi-topology to implement active-active edge then that should be followed up as part of the multi-topology. What we need now is a simplified approach that can be present in all deployments. Hence CMT draft can move forward independently.

From: Mingui Zhang [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2012 2:11 PM
To: [email-masked]; Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Best regards,

Mingui

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12 

收件人

抄送

主题

		

Hi Hu 

  
Thanks 
Tissa 

Hi,all 

Thanks

Donald Eastlake <[email-masked] <mailto:[email-masked]> > 
发件人:  [email-masked] <mailto:[email-masked]>  

2012-03-27 06:38 

收件人

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

抄送

主题

  

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked] <mailto:[email-masked]> 

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

---

From: Radia Perlman <[email-masked]>
Date: Tue, 27 Mar 2012 21:52:28 -0700

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

---

From: [email-masked]
Date: Wed, 28 Mar 2012 13:51:54 +0800

Hi Jana, Tissa

The main difference between PN draft and CMT draft as follows:
1) In PN draft, a member RBridge employs pseudo-LSP to carry 
pseudo-nickname and members of a virtual RBridge group,
2) While in CMT draft, Affinity TLV is introduced to carry pseudo-nickname 
and the wanted DTrees by a member RBridge.

> 1) In figure 2 of the CMT draft, the nodes CE1, CE2 etc. treat their 
links to RB1, 
> RB2… RBk as a LAG. Hence if RB1 sends a TRILL hello frame on this link 
towards CE1,
> this will not be received by any of the other RBridges RB2, .. RB4. 
Hence the concept
> of AF will not be applicable in this scenario

In PN draft, TRILL hello is mainly used to find member RBridge and to 
negotiate the pseudo-nickname of a virtual 
RBridge group. For a virtual RBridge group, if its member RBridges and 
pseudo-nickname are configured statically 
by a network administrator, TRILL hellos are not requisite in PN draft. 
Therefore, the idea proposed in PN draft, 
i.e., giving a pseudo-nickname to an RBriges Group and using pseudo-LSP to 
carry information of this RBridge group, 
is also applicable in the CMT scenario (given in figure 2 of CMT draft). 

Furthermore, using pseudo-LSP, instead of a new TLV, can avoid the 
backward compatibility issue.

> 2) In the PN draft, only the AF will forward all traffic into and out of 
this network, 
> and this is because it is regular Ethernet link. But in the CMT draft 
the links are 
> all LAGs, and hence the traffic (for e.g. broadcast from CE1) is sent to 
only one of 
> the RB1 and not to all of them.

Although the PN draft discusses the issues of pseudo-nickname mainly based 
on Ethernet link, the idea of pseudo-nickname 
and employing pseudo-LSP to carry RB Group info is also applicable in 
other scenario, such as LAGs and multi-homing. 
Whether using one member RB or all member RBs to forward traffic for an 
end system, it depends on in which scenario the 
pseudo-nickname is used, but not the different ways to implement the 
pseudo-nickname function between PN draft and CMT draft.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

Janardhanan Pathangi Narasimhan <[email-masked]> 
2012-03-28 00:09

收件人
"[email-masked]" <[email-masked]>, "Tissa Senevirathne 
(tsenevir)" <[email-masked]>
抄送
Donald Eastlake <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai,
 
Few points:
 
1) In figure 2 of the CMT draft, the nodes CE1, CE2 etc. treat their links 
to RB1, RB2… RBk as a LAG. Hence if RB1 sends a TRILL hello frame on this 
link towards CE1, this will not be received by any of the other RBridges 
RB2, .. RB4. Hence the concept of AF will not be applicable in this 
scenario
 
2)  In the PN draft, only the AF will forward all traffic into and out of 
this network, and this is because it is regular Ethernet link. But in the 
CMT draft the links are all LAGs, and hence the traffic (for e.g. 
broadcast from CE1) is sent to only one of the RB1 and not to all of them.
 
  So I think the problem space that these two drafts are discussing are 
different, and the Pseudo Node draft will not be applicable to the LAG 
active-active load balancing scenarios described in the CMT draft.
 
Thanks
Jana

From: [email-masked] [mailto:[email-masked]] On 
Behalf Of [email-masked]
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hu 

  
Thanks 
Tissa 

Hi,all 

Thanks

收件人
[email-masked] 
抄送

主题

Thanks,
Donald

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Wed, 28 Mar 2012 11:57:02 +0530

Hi Zhai,

I think the other point in the pN draft is
The requirement in the PN draft is that we should form a tree with the PN node as the root of the tree. In case we have many LAN links, for e.g. 10, than we would need 10 trees where each tree has the corresponding PN as the root of the tree.
  A similar approach was one of the options considered earlier, but since this would not sale in terms of number of trees, it was felt that the requirement that the PN be the root of the tree would not be possible.

Thanks
Jana

The main difference between PN draft and CMT draft as follows:
1) In PN draft, a member RBridge employs pseudo-LSP to carry pseudo-nickname and members of a virtual RBridge group,
2) While in CMT draft, Affinity TLV is introduced to carry pseudo-nickname and the wanted DTrees by a member RBridge.

> 1) In figure 2 of the CMT draft, the nodes CE1, CE2 etc. treat their links to RB1,
> RB2… RBk as a LAG. Hence if RB1 sends a TRILL hello frame on this link towards CE1,
> this will not be received by any of the other RBridges RB2, .. RB4. Hence the concept

In PN draft, TRILL hello is mainly used to find member RBridge and to negotiate the pseudo-nickname of a virtual
RBridge group. For a virtual RBridge group, if its member RBridges and pseudo-nickname are configured statically
by a network administrator, TRILL hellos are not requisite in PN draft. Therefore, the idea proposed in PN draft,
i.e., giving a pseudo-nickname to an RBriges Group and using pseudo-LSP to carry information of this RBridge group,
is also applicable in the CMT scenario (given in figure 2 of CMT draft).

Furthermore, using pseudo-LSP, instead of a new TLV, can avoid the backward compatibility issue.

> 2) In the PN draft, only the AF will forward all traffic into and out of this network,
> and this is because it is regular Ethernet link. But in the CMT draft the links are
> all LAGs, and hence the traffic (for e.g. broadcast from CE1) is sent to only one of

Although the PN draft discusses the issues of pseudo-nickname mainly based on Ethernet link, the idea of pseudo-nickname
and employing pseudo-LSP to carry RB Group info is also applicable in other scenario, such as LAGs and multi-homing.
Whether using one member RB or all member RBs to forward traffic for an end system, it depends on in which scenario the
pseudo-nickname is used, but not the different ways to implement the pseudo-nickname function between PN draft and CMT draft.

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

Janardhanan Pathangi Narasimhan <[email-masked]<mailto:[email-masked]>>

2012-03-28 00:09

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Tissa Senevirathne (tsenevir)" <[email-masked]<mailto:[email-masked]>>

抄送

Donald Eastlake <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Hi Zhai,

Few points:

Thanks
Jana

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Tissa

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12

收件人

抄送

主题

Hi Hu

Thanks
Tissa

Hi,all

Thanks

2012-03-27 06:38

收件人

抄送

主题

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 28 Mar 2012 15:02:31 +0800

Hi Jana，

In PN draft, it is optional but not necessary to use PN node as root to 
form a DTree. When we wrote the 02 version of PN draft, we had considered 
using PN node as root to form trees, but we found there would not be as 
many trees as PN nodes (or virtual RBridge Groups). So PN node as root is 
only an optional approach. Then another approach is given in PN draft, 
which using PN node as an ordinary node in forming a DTree. 

In the later approach, maybe some the member RBridges of a virtual RBridge 
Group are not attached directly to the PN node in any formed DTree. If 
this happens, we propose such an RBridge should forward (or tunnel) the 
received native traffic to another member RBridge that directly attaches 
to the PN node at least in one DTree. Then the later RBridge ingresses the 
traffic into TRILL campus to avoid failure of RPF check on a remote 
RBridge.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-03-28 14:27

收件人
"[email-masked]" <[email-masked]>
抄送
Donald Eastlake <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "Tissa 
Senevirathne (tsenevir)" <[email-masked]>
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai,
 
I think the other point in the pN draft is
The requirement in the PN draft is that we should form a tree with the PN 
node as the root of the tree. In case we have many LAN links, for e.g. 10, 
than we would need 10 trees where each tree has the corresponding PN as 
the root of the tree.
  A similar approach was one of the options considered earlier, but since 
this would not sale in terms of number of trees, it was felt that the 
requirement that the PN be the root of the tree would not be possible.
 
Thanks
Jana

links to RB1, 
towards CE1, 
Hence the concept 

this network, 
the links are 
only one of 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
"[email-masked]" <[email-masked]>, "Tissa Senevirathne 
(tsenevir)" <[email-masked]> 
抄送
Donald Eastlake <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <
[email-masked]> 
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai, 
  
Few points: 

  
Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hu 

 
Thanks 
Tissa 

Hi,all 

Thanks 

收件人
[email-masked] 
抄送

主题

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 00:23:57 -0700

See in-line

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 12:03 AM
To: Janardhanan Pathangi Narasimhan
Cc: Donald Eastlake; [email-masked]; [email-masked]; [email-masked]; Tissa Senevirathne (tsenevir)
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Jana， 

In PN draft, it is optional but not necessary to use PN node as root to form a DTree. When we wrote the 02 version of PN draft, we had considered using PN node as root to form trees, but we found there would not be as many trees as PN nodes (or virtual RBridge Groups). So PN node as root is only an optional approach. Then another approach is given in PN draft, which using PN node as an ordinary node in forming a DTree. 

In the later approach, maybe some the member RBridges of a virtual RBridge Group are not attached directly to the PN node in any formed DTree. If this happens, we propose such an RBridge should forward (or tunnel) the received native traffic to another member RBridge that directly attaches to the PN node at least in one DTree. Then the later RBridge ingresses the traffic into TRILL campus to avoid failure of RPF check on a remote RBridge. 

[Answer] Here is the problem: when edge device is multi-homed to multiple RBrdiges using pt-pt links and end device is deploying LAG; RBridges can not see LAN Hellos of each other.  Hence each one of them form a separate PN. Now to avoid RPF violation you have to tunnel traffic. It does not matter how many trees you have, you cannot avoid this. Tunneling Traffic is not RFC 6325 defined data plane behavior and this cannot be considered as the standard solution. 

1.       Use of PN as the root is non scalable

2.       Tunneling is non RFC 6325 dataplane behavior

Hence, whatever the path you take solution proposed in your draft can not be applied to larger deployments with Pt-pt edges. I have no problem with your draft to be discussed as a potential way for LAN. But it is not the solution for multi-homed active-active edge.

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 14:27 

收件人

抄送

Donald Eastlake <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Tissa Senevirathne (tsenevir)" <[email-masked]> 

主题

		

Hi Zhai, 

Thanks 
Jana 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345
Email: [email-masked] <mailto:[email-masked]> 
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Janardhanan Pathangi Narasimhan <[email-masked] <mailto:[email-masked]> > 

2012-03-28 00:09 

收件人

"[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "Tissa Senevirathne (tsenevir)" <[email-masked] <mailto:[email-masked]> > 

抄送

Donald Eastlake <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> > 

主题

  

Hi Zhai, 
 
Few points: 

 
 
Thanks 
Jana 

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345
Email: [email-masked] <mailto:[email-masked]> 
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <[email-masked] <mailto:[email-masked]> > 
发件人:  [email-masked] <mailto:[email-masked]>  

2012-03-27 18:12 

收件人

<[email-masked] <mailto:[email-masked]> >, "Donald Eastlake" <[email-masked] <mailto:[email-masked]> > 

抄送

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

主题

  

Hi Hu 

Thanks 
Tissa 

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft 

Hi,all 

Thanks 

2012-03-27 06:38 

收件人

抄送

主题

  

		

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 28 Mar 2012 16:14:30 +0800

See in-line, pls.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-03-28 15:23

收件人
<[email-masked]>, "Janardhanan Pathangi Narasimhan" 
<[email-masked]>
抄送
"Donald Eastlake" <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

See in-line
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 12:03 AM
To: Janardhanan Pathangi Narasimhan
Cc: Donald Eastlake; [email-masked]; [email-masked]; 
[email-masked]; Tissa Senevirathne (tsenevir)
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Jana， 

In the later approach, maybe some the member RBridges of a virtual RBridge 
Group are not attached directly to the PN node in any formed DTree. If 
this happens, we propose such an RBridge should forward (or tunnel) the 
received native traffic to another member RBridge that directly attaches 
to the PN node at least in one DTree. Then the later RBridge ingresses the 
traffic into TRILL campus to avoid failure of RPF check on a remote 
RBridge. 
[Answer] Here is the problem: when edge device is multi-homed to multiple 
RBrdiges using pt-pt links and end device is deploying LAG; RBridges can 
not see LAN Hellos of each other. 
-------[by Zhai Hongjun]
I don't think Hellos are necessary for PN draft. Hellos are used to find 
member Rbridges and nogotiate psuedu-nickname in a virtual Rbridge group. 
In LAG scenario, pseudo-nickname and members for a virtual RBridge group 
should be configured statically by a network administrator. Based on 
static configuration,   each member Rbdiges in this group will know this 
nickname and all other paterners, therefore  Hellos are not required.
--------

Hence each one of them form a separate PN.
-------[by Zhai Hongjun]
No, not each one member RB needs to form a separate PN. Only one 
Pseudo-LSP is required for a virtual Rbridge Group. The pseudo-nickname 
and all the members of this group will be carried in this LSP.
----------

Now to avoid RPF violation you have to tunnel traffic. It does not matter 
how many trees you have, you cannot avoid this. Tunneling Traffic is not 
RFC 6325 defined data plane behavior and this cannot be considered as the 
standard solution. 
------[by Zhai Hongjun]
If the number trees is less than the mumber of members in a RB group, and 
all the member s are active, tunneling traffic can not be avoided in your 
CMT and my PN draft.
--------

1.       Use of PN as the root is non scalable
------ [by Zhai Hongjun]
PN draft dosen't require PN node as root for forming DTrees. PN node as 
root is only an optional approach.  So the scalabity for this point does 
not exist.
-------

2.       Tunneling is non RFC 6325 dataplane behavior
--------[by Zhai Hongjun]
see the above answer.
--------

Hence, whatever the path you take solution proposed in your draft can not 
be applied to larger deployments with Pt-pt edges.
------- [by Zhai Hongjun]
I don't think so.
--------

 I have no problem with your draft to be discussed as a potential way for 
LAN. But it is not the solution for multi-homed active-active edge.

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
"[email-masked]" <[email-masked]> 
抄送
Donald Eastlake <[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>, "Tissa 
Senevirathne (tsenevir)" <[email-masked]> 
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai, 

Thanks 
Jana 

links to RB1, 
towards CE1, 
Hence the concept 

this network, 
the links are 
only one of 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Zhai, 
 
Few points: 

 
Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

 

收件人
[email-masked] 
抄送

主题

 

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 01:33:12 -0700

You quoted “No, not each one member RB needs to form a separate PN. Only one Pseudo-LSP is required for a virtual Rbridge Group. The pseudo-nickname and all the members of this group will be carried in this LSP.”

Normally PN-LSP  is announced by the DRB, since RBRidges cannot see LAN hellos how does the DRB get elected ?

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 1:15 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; Janardhanan Pathangi Narasimhan; [email-masked]; [email-masked]
Subject: 答复: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 15:23 

收件人

<[email-masked]>, "Janardhanan Pathangi Narasimhan" <[email-masked]> 

抄送

"Donald Eastlake" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 

主题

		

See in-line 

Hi Jana， 

In the later approach, maybe some the member RBridges of a virtual RBridge Group are not attached directly to the PN node in any formed DTree. If this happens, we propose such an RBridge should forward (or tunnel) the received native traffic to another member RBridge that directly attaches to the PN node at least in one DTree. Then the later RBridge ingresses the traffic into TRILL campus to avoid failure of RPF check on a remote RBridge. 
[Answer] Here is the problem: when edge device is multi-homed to multiple RBrdiges using pt-pt links and end device is deploying LAG; RBridges can not see LAN Hellos of each other.   
-------[by Zhai Hongjun] 
I don't think Hellos are necessary for PN draft. Hellos are used to find member Rbridges and nogotiate psuedu-nickname in a virtual Rbridge group.  In LAG scenario, pseudo-nickname and members for a virtual RBridge group should be configured statically by a network administrator. Based on static configuration,   each member Rbdiges in this group will know this nickname and all other paterners, therefore  Hellos are not required. 
-------- 

Hence each one of them form a separate PN. 
-------[by Zhai Hongjun] 
No, not each one member RB needs to form a separate PN. Only one Pseudo-LSP is required for a virtual Rbridge Group. The pseudo-nickname and all the members of this group will be carried in this LSP. 
---------- 

Now to avoid RPF violation you have to tunnel traffic. It does not matter how many trees you have, you cannot avoid this. Tunneling Traffic is not RFC 6325 defined data plane behavior and this cannot be considered as the standard solution. 
------[by Zhai Hongjun] 
If the number trees is less than the mumber of members in a RB group, and all the member s are active, tunneling traffic can not be avoided in your CMT and my PN draft. 
-------- 

1.       Use of PN as the root is non scalable 
------ [by Zhai Hongjun] 
PN draft dosen't require PN node as root for forming DTrees. PN node as root is only an optional approach.  So the scalabity for this point does not exist. 
------- 

Hence, whatever the path you take solution proposed in your draft can not be applied to larger deployments with Pt-pt edges. 
------- [by Zhai Hongjun] 
I don't think so. 
-------- 

 I have no problem with your draft to be discussed as a potential way for LAN. But it is not the solution for multi-homed active-active edge. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 14:27 

收件人

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

抄送

Donald Eastlake <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "Tissa Senevirathne (tsenevir)" <[email-masked] <mailto:[email-masked]> > 

主题

  

Hi Zhai, 

Thanks 
Jana 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 00:09 

收件人

抄送

主题

  

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12 

收件人

抄送

主题

  

		

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

2012-03-27 06:38 

 

收件人

抄送

主题

  

 

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 28 Mar 2012 16:47:00 +0800

>  Normally PN-LSP  is announced by the DRB, since RBRidges cannot see LAN 
hellos how does the DRB get elected ?

I think, DRB can be configured by adiminstrator in LAG scenario. And  
another member  is used to detect the failure of this "DRB". If finding 
DRB failed,  the detecting member RB becomes DRB and annouce new PN-LSPs.

I think, static configurations are required in LAG scenario both in your 
CMT draft and my PN draft.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-03-28 16:33

收件人
<[email-masked]>
抄送
"Donald Eastlake" <[email-masked]>, <[email-masked]>, 
"Janardhanan Pathangi Narasimhan" <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

You quoted “No, not each one member RB needs to form a separate PN. Only 
one Pseudo-LSP is required for a virtual Rbridge Group. The 
pseudo-nickname and all the members of this group will be carried in this 
LSP.”
 
Normally PN-LSP  is announced by the DRB, since RBRidges cannot see LAN 
hellos how does the DRB get elected ?

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 1:15 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; Janardhanan Pathangi 
Narasimhan; [email-masked]; [email-masked]
Subject: 答复: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
<[email-masked]>, "Janardhanan Pathangi Narasimhan" <
[email-masked]> 
抄送
"Donald Eastlake" <[email-masked]>, <[email-masked]>, <
[email-masked]>, <[email-masked]> 
主题
RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

See in-line 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Zhai, 

Thanks 
Jana 

links to RB1, 
towards CE1, 
Hence the concept 

this network, 
the links are 
only one of 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

 

收件人

 

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

  

收件人
[email-masked] 
抄送

主题

  

Thanks,
Donald

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 28 Mar 2012 09:10:28 +0000

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

Cc: [email-masked]

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

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.

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).

------

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: Wed, 28 Mar 2012 02:03:11 -0700

The static configuration required is only the virtual RB nickname.

We discussed earlier in your proposal, to overcome RPF issues we need to either

1.       Have tree rooted on each edge RBridge OR

2.       Tunnel

#1 does not scale #2 a non standard behavior. 

In the CMT if the number of tree are less we can either make a link passive or optionally use tunneling. 

Lets assume we have 200 such virtual RBridges with dual homing in each virtual RBRidge (i.e two RBridges in the block). In the CMT we just need two trees to perform active-active forwarding.

In your case either we need 400 trees (i.e. 2*200) or dataplane upgrade to do tunneling. Both of them in my mind is not going to help.

Additionally Affinity TLV enable so many different other applications beyond active-active forwarding,

If you are still in Paris maybe we can meetup and go over some of the issues.

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 1:47 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; Janardhanan Pathangi Narasimhan; [email-masked]; [email-masked]
Subject: 答复: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

>  Normally PN-LSP  is announced by the DRB, since RBRidges cannot see LAN hellos how does the DRB get elected ? 

I think, DRB can be configured by adiminstrator in LAG scenario. And  another member  is used to detect the failure of this "DRB". If finding DRB failed,  the detecting member RB becomes DRB and annouce new PN-LSPs. 

I think, static configurations are required in LAG scenario both in your CMT draft and my PN draft. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 16:33 

收件人

抄送

"Donald Eastlake" <[email-masked]>, <[email-masked]>, "Janardhanan Pathangi Narasimhan" <[email-masked]>, <[email-masked]>, <[email-masked]> 

主题

		

  

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 15:23 

收件人

<[email-masked] <mailto:[email-masked]> >, "Janardhanan Pathangi Narasimhan" <[email-masked] <mailto:[email-masked]> > 

抄送

"Donald Eastlake" <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> > 

主题

  

See in-line 
 
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, March 28, 2012 12:03 AM
To: Janardhanan Pathangi Narasimhan
Cc: Donald Eastlake; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Tissa Senevirathne (tsenevir)
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 14:27 

收件人

抄送

主题

  

Hi Zhai, 

Thanks 
Jana 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 00:09 

收件人

抄送

主题

  

		

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12 

 

收件人

抄送

主题

  

 

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

2012-03-27 06:38 

  

收件人

抄送

主题

  

  

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 28 Mar 2012 17:50:08 +0800

See in-line, pls.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-03-28 17:03

收件人
RE: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

The static configuration required is only the virtual RB nickname.
----[by Zhai]Besides the pseu-nickname, maybe which ports belonging to 
current virtual group on a memnber RB are also required to be configured 
in CMT draft.
 
We discussed earlier in your proposal, to overcome RPF issues we need to 
either
 
1.       Have tree rooted on each edge RBridge OR
2.       Tunnel
#1 does not scale #2 a non standard behavior. 
 ----[by Zhai] PN draft doesn't not require DTree rooted on member RB or 
PN node. The choice of campus-wide DTree roots can be as same as the 
mechanism given in RFC6325.
So the #1 your given does not exist in PN draft. As for the #2 point, I 
think it is the same to CMT draft and PN draft.

In the CMT if the number of tree are less we can either make a link 
passive or optionally use tunneling. 
-----[by Zhai]  I think, for the issue that  mumber of DTree are less than 
member RB in a group,  PN draft can use the same  methods as CMT draft to 
process  this issue in the LAG scenario has no difference in nature, i.e., 
making a link passive or using tunnel. In my mind, these methods have been 
discussed in Radia's previous emails.

Lets assume we have 200 such virtual RBridges with dual homing in each 
virtual RBRidge (i.e two RBridges in the block). In the CMT we just need 
two trees to perform active-active forwarding.
 
In your case either we need 400 trees (i.e. 2*200) or dataplane upgrade to 
do tunneling. Both of them in my mind is not going to help.
-----[by Zhai] Since using PN node as root to form DTree is only optional 
approch in PN draft, I don't think PN draft has  special requirements for 
the selection of DTree roots. Therefore, in your given case, PN draft 
doesn't need so may trees. only two trees are or one tree(if the two 
member RB in a given RB group are connected directly to a DTree) is 
required to perform active-active forwarding.
 
Additionally Affinity TLV enable so many different other applications 
beyond active-active forwarding,
 -----[by Zhai] Without backward compatibility issue, Affinity TLV maybe 
is a good approach.

If you are still in Paris maybe we can meetup and go over some of the 
issues.
---- [by Zhai] I'd like to talk with you about this issue face to face, 
but  I do not attend this IETF meeting.
 
Subject: 答复: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG 
draft

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人
"Janardhanan Pathangi Narasimhan" <[email-masked]>, <

  

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

See in-line 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Zhai, 

Thanks 
Jana 

links to RB1, 
towards CE1, 
Hence the concept 

this network, 
the links are 
only one of 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

 

收件人

 

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

  

收件人

  

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

 

收件人
[email-masked] 
抄送

主题

 

Thanks,
Donald

---

From: "Rohit Watve (rwatve)" <[email-masked]>
Date: Wed, 28 Mar 2012 03:22:46 -0700

Hi Mingui,

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,

PN: YES.
CMT: NO.
MTRA: YES.

PN: NO.
CMT: YES.
MTRA: YES.

PN: NO.
CMT: YES.
MTRA: YES.

Thanks,
Mingui

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

Cc: [email-masked]

still worth doing.

------

Radia

---

From: [email-masked]
Date: Wed, 28 Mar 2012 17:50:08 +0800

See in-line, pls.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

收件人

 

 

 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

  

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

See in-line 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Hi Zhai, 

Thanks 
Jana 

links to RB1, 
towards CE1, 
Hence the concept 

this network, 
the links are 
only one of 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

 

收件人

 

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

  

收件人

  

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

 

收件人
[email-masked] 
抄送

主题

 

Thanks,
Donald

---

From: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Wed, 28 Mar 2012 16:44:27 +0530

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,

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: Wed, 28 Mar 2012 04:03:08 -0700

Hongjun

Few more points, if you use Affinity TLV in your draft you can address #1 and #2 and we all will be happy family.

We do not need to think too much of backward compatibility, such does not exist. We have more TRILL drafts than actual TRILL RBridges out there, I guess that summarize how important is to discuss backward compatibility.

Thanks

Tissa

From: Tissa Senevirathne (tsenevir) 
Sent: Wednesday, March 28, 2012 2:03 AM
To: [email-masked]'
Cc: Donald Eastlake; [email-masked]; Janardhanan Pathangi Narasimhan; [email-masked]; [email-masked]
Subject: RE: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

2.       Tunnel

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 16:33 

收件人

抄送

主题

		

  

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 15:23 

收件人

抄送

主题

  

See in-line 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 14:27 

收件人

抄送

主题

  

Hi Zhai, 

Thanks 
Jana 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 00:09 

收件人

抄送

主题

  

		

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12 

 

收件人

抄送

主题

  

 

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

2012-03-27 06:38 

  

收件人

抄送

主题

  

  

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 04:14:15 -0700

Hi Hongjun

I do not agree with your below statement that having two trees will solve RPF issue in your case, based on various topology configurations, you will end-up PN nickname having connected to both trees through the same physical RBridge. This was the fundamental reason that Affinity TLV was introduced in the first place.

Like I suggested in my other email probably it would be good if you can consider affinity TLV in your solution so you can have flexibility to apply your  framework for both LAN and point-point multi-homed edge.

Thanks

Tissa

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 28, 2012 2:50 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [email-masked]; Janardhanan Pathangi Narasimhan; [email-masked]; [email-masked]
Subject: 答复: RE: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 17:03 

收件人

抄送

主题

		

The static configuration required is only the virtual RB nickname. 
----[by Zhai]Besides the pseu-nickname, maybe which ports belonging to current virtual group on a memnber RB are also required to be configured in CMT draft. 

1.       Have tree rooted on each edge RBridge OR 
2.       Tunnel 
#1 does not scale #2 a non standard behavior. 
 ----[by Zhai] PN draft doesn't not require DTree rooted on member RB or PN node. The choice of campus-wide DTree roots can be as same as the mechanism given in RFC6325. 
So the #1 your given does not exist in PN draft. As for the #2 point, I think it is the same to CMT draft and PN draft. 

In the CMT if the number of tree are less we can either make a link passive or optionally use tunneling. 
-----[by Zhai]  I think, for the issue that  mumber of DTree are less than member RB in a group,  PN draft can use the same  methods as CMT draft to process  this issue in the LAG scenario has no difference in nature, i.e., making a link passive or using tunnel. In my mind, these methods have been discussed in Radia's previous emails. 

In your case either we need 400 trees (i.e. 2*200) or dataplane upgrade to do tunneling. Both of them in my mind is not going to help. 
-----[by Zhai] Since using PN node as root to form DTree is only optional approch in PN draft, I don't think PN draft has  special requirements for the selection of DTree roots. Therefore, in your given case, PN draft doesn't need so may trees. only two trees are or one tree(if the two member RB in a given RB group are connected directly to a DTree) is required to perform active-active forwarding. 
  
Additionally Affinity TLV enable so many different other applications beyond active-active forwarding, 
 -----[by Zhai] Without backward compatibility issue, Affinity TLV maybe is a good approach. 

If you are still in Paris maybe we can meetup and go over some of the issues. 
---- [by Zhai] I'd like to talk with you about this issue face to face, but  I do not attend this IETF meeting. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 16:33 

收件人

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

抄送

"Donald Eastlake" <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> >, "Janardhanan Pathangi Narasimhan" <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> >, <[email-masked] <mailto:[email-masked]> > 

主题

  

 

Cc: Donald Eastlake; [email-masked] <mailto:[email-masked]> ; Janardhanan Pathangi Narasimhan; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 

See in-line, pls. 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 15:23 

收件人

抄送

主题

  

See in-line 

Hi Jana， 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 14:27 

收件人

抄送

主题

  

		

Hi Zhai, 

Thanks 
Jana 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-28 00:09 

 

收件人

抄送

主题

  

 

Hi Zhai, 

Few points: 

Thanks 
Jana 

Hi Tissa 

Thanks,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

2012-03-27 18:12 

  

收件人

抄送

主题

  

  

Hi Hu 

Thanks 
Tissa 

Hi,all 

Thanks 

2012-03-27 06:38 

  

收件人

抄送

主题

  

  

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 04:42:15 -0700

One more point; if we are listing Pros and Cons, then we also need to associate a priority. 

e.g. control plane backward compatibility is a lower priority while control plane backward compatibility is a higher priority.

To recap: we have more TRILL drafts than actual TRILL RBridges out there in deployments so backward compatibility of control plane is a mere academic thought.

_____________________________________________
From: Rohit Watve (rwatve) 
Sent: Wednesday, March 28, 2012 3:23 AM
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,

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.

PN: NO.
CMT: YES.
MTRA: YES.

PN: NO.
CMT: YES.
MTRA: YES.

Thanks,
Mingui

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

Cc: [email-masked]

still worth doing.

------

Radia

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 04:52:11 -0700

Just want to correct a typo:

Control plane backward compatibility is a lower priority and dataplane backward compatibility is a higher priority.
_____________________________________________
From: Tissa Senevirathne (tsenevir) 
Sent: Wednesday, March 28, 2012 4:42 AM
To: Rohit Watve (rwatve); 'Mingui Zhang'; 'Radia Perlman'
Cc: [email-masked]'
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

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.

PN: NO.
CMT: YES.
MTRA: YES.

PN: NO.
CMT: YES.
MTRA: YES.

Thanks,
Mingui

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

Cc: [email-masked]

still worth doing.

------

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 28 Mar 2012 13:35:18 +0000

Hi Rohit，

Thanks for offering the complementary dimension. Yes, I agree that MT-TRILL requires new TLVs. But in case that MT is already supported by TRILL, this is not a Cons of MTRA any more.

For the Fast Converge dimension. CMT does need to "perform distribution tree assignment algorithm specified in section 5.1" to change the assignment of affinities of aggregated members when there is a failure.

Thanks,
Mingui
________________________________
发件人: Rohit Watve (rwatve) [[email-masked]]
发送时间: 2012年3月28日 18:22
到: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
主题: 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]] 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: Mingui Zhang <[email-masked]>
Date: Wed, 28 Mar 2012 13:45:13 +0000

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,

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: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Wed, 28 Mar 2012 20:22:07 +0530

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,

Thanks,
Mingui

Thanks
Jana

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

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: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Mar 2012 15:01:38 -0700

Mingui

Assuming everyone who need active-active forwarding will and willing to run multi-topology is like assuming all of us engineers are owning BMWs.

Joking aside what we need is a simple solution that works without intricacies of multi-topology. So your argument that we should drop CMT and just use multi-topology is very academic and will have some detrimental effect on adaptation of TRILL.

I rest my arguments with this.

Thanks

Tissa

From: Mingui Zhang [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 6:35 AM
To: Rohit Watve (rwatve); Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Rohit，

Thanks,

Mingui

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: [email-masked]
Date: Thu, 29 Mar 2012 12:53:54 +0800

Hi Jana

In my mind，Mingui Zhang has two drafs about Multi-topology for TRILL. I 
think he can give you a detail explanation about your question.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2012-03-28 19:14

收件人
"Rohit Watve (rwatve)" <[email-masked]>, Mingui Zhang 
<[email-masked]>, Radia Perlman <[email-masked]>, "Tissa 
Senevirathne (tsenevir)" <[email-masked]>
抄送
"[email-masked]" <[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

Behalf Of Rohit Watve (rwatve)
 
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

 

 

 
2) R3 could use its own nickname instead of the pseudonode nickname in 
this case

------

Radia

---

From: [email-masked]
Date: Thu, 29 Mar 2012 13:56:34 +0800

See in-line,pls.

Thanks,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

Mingui Zhang <[email-masked]> 
发件人:  [email-masked]
2012-03-28 17:10

收件人
Radia Perlman <[email-masked]>, "Tissa Senevirathne (tsenevir)" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

PN: YES.
CMT: NO.
MTRA: YES.

PN: NO. New silicon is necessary to support "tunneling" or else MAC 
addresses may flip-flop.
----[Zhai Hongjun] I do not agree to this result. In PN, "tunneling" of 
taffice is not necessary. If each member RB in an RB group can get a DTree 
,PN works well on existing silicon . If an member can not get any DTree, 
it can remain passive. In the both cases, PN can use the existing 
silicons. So we should not give such a result to PN at this point.
CMT: YES.
MTRA: Currently NO. But after multi-topology is supported by TRILL, it is 
a "YES".

PN: NO.
----[Zhai Hongjun] In PN draft, whether using one member RB or all member 
RBs to forward traffic for an end system, it depends on in which scenario 
the pseudo-nickname is used. Because of the AF, only one RB forward 
multi-cast traffic on a shared link. But in LAG, the concept of AF is not 
required, so load-balance of multi-cast traffic is OK for PN.
CMT: YES.
MTRA: YES.

PN: NO.
----[Zhai Hongjun] See answer to #3.
CMT: YES.
MTRA: YES.

Thanks,
Mingui

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

Cc: [email-masked]

still worth doing.

------

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 29 Mar 2012 10:50:44 +0000

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
到: Mingui Zhang

Hi 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, 29 Mar 2012 14:46:55 +0000

Hi Jana,

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.

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,
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,

Thanks,
Mingui

Hi 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: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Thu, 29 Mar 2012 22:19:25 +0530

Hi Mingui,

I am slightly confused.

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?

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]<mailto:[email-masked]> [[email-masked]] 代表 Mingui Zhang [[email-masked]]

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, 29 Mar 2012 18:56:36 +0000

Hi Jana,

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

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

Hi 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: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Fri, 30 Mar 2012 10:59:47 +0530

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,

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: Fri, 30 Mar 2012 06:45:14 +0000

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

Hi 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: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Fri, 30 Mar 2012 13:00:19 +0530

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,

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: Fri, 30 Mar 2012 07:43:32 +0000

Hi Jana,

Have you forgotten the tunneling approach? In order to enable the communication between MTRA RBridges and non-MT RBridges, we can always resort to the tunneling approach to redirect the aggregated traffic to the only parent of RBv on the distribution tree of the base topology for delivery.

I did not mention tunneling since I like simple solutions. I think Section 4.2 of my draft did offer another simpler solution to allow us to enable the communication between MRTA RBridges and non-MT RBridges. I insist on this solution until operators tell me it is not workable.

So, of course MRTA is backward compatible.

Thanks,
Mingui
发送时间: 2012年3月30日 15:30

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: Janardhanan Pathangi Narasimhan <[email-masked]>
Date: Fri, 30 Mar 2012 13:18:51 +0530

Hi Minghi,

With tunneling all approaches are backward compatible, including CMT.

Thanks
Jana

From: Mingui Zhang [mailto:[email-masked]]
Sent: Friday, March 30, 2012 1:14 PM
To: Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Jana,

Thanks,
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: Fri, 30 Mar 2012 07:56:09 +0000

Hi Jana,

The beauty of MTRA is that aggregated members can determine themselves whether to use tunneling or not according to the egress RBridges. For MT egress RBridges, they need not do tunneling.

As long as there is only one old RBridge in the campus, CMT does not work. In order to be backward compatible using tunneling, CMT just simply disappears totally. There is no CMT anymore.

Thanks,
Mingui
发送时间: 2012年3月30日 15:48

Hi Minghi,

Thanks
Jana

Hi Jana,

Thanks,
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: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 30 Mar 2012 01:25:03 -0700

Jana is absolutely correct in the observation on 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 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

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: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 30 Mar 2012 01:36:56 -0700

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.

3.       What is your solution for customers who *do NOT* want to run multi-topology ?

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: Fri, 30 Mar 2012 15:06:57 +0530

Hi Mingui,

The tunneling is only for multi-destination frames and not for unicast frames. Hence not sure what you are referring to here as tunneling based on egress RBridge.

When you say CMT disappears, I am assuming you mean that we will have to do tunneling for all multi-destination frames. Much the same as what we would have to do with MT when one non-MT RBridge exists.

Thanks
Jana

From: Mingui Zhang [mailto:[email-masked]]
Sent: Friday, March 30, 2012 1:26 PM
To: Janardhanan Pathangi Narasimhan
Cc: [email-masked]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Jana,

Thanks,
Mingui

Thanks
Jana

Hi Jana,

Thanks,
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: Fri, 30 Mar 2012 09:42:59 +0000

Hi Jana,

ZMG> Not exactly. In CMT, even you do not need to communicate with non-CMT RBridges, the CMT cannot be used if non-CMT RBridges exist in the campus. Non-CMT RBridges even cannot appear as transit RBridges. As you know, the trees will not be calculated according to the affinity TLV by these RBridges.

Thanks,
Mingui

发送时间: 2012年3月30日 17:36

Hi Mingui,

Thanks
Jana

Hi Jana,

Thanks,
Mingui

Thanks
Jana

Hi Jana,

Thanks,
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: Jon Hudson <[email-masked]>
Date: Fri, 30 Mar 2012 13:56:03 +0200

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 c…

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