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

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

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: '[e-mail]'
Cc: Donald Eastlake; [e-mail]; Janardhanan Pathangi Narasimhan; [e-mail]; [e-mail]
Subject: RE: RE: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

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: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, March 28, 2012 1:47 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [e-mail]; Janardhanan Pathangi Narasimhan; [e-mail]; [e-mail]
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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: [phone]
Email: [e-mail]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""




"Tissa Senevirathne (tsenevir)" <[e-mail]> 

2012-03-28 16:33 

收件人

<[e-mail]> 

抄送

"Donald Eastlake" <[e-mail]>, <[e-mail]>, "Janardhanan Pathangi Narasimhan" <[e-mail]>, <[e-mail]>, <[e-mail]> 

主题

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: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, March 28, 2012 1:15 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [e-mail]; Janardhanan Pathangi Narasimhan; [e-mail]; [e-mail]
Subject: 答复: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft 
  

See in-line, pls. 



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: [phone]
Email: [e-mail] <mailto:[e-mail]> 
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <[e-mail] <mailto:[e-mail]> > 

2012-03-28 15:23 

 

收件人

<[e-mail] <mailto:[e-mail]> >, "Janardhanan Pathangi Narasimhan" <[e-mail] <mailto:[e-mail]> > 

抄送

"Donald Eastlake" <[e-mail] <mailto:[e-mail]> >, <[e-mail] <mailto:[e-mail]> >, <[e-mail] <mailto:[e-mail]> >, <[e-mail] <mailto:[e-mail]> > 

主题

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


  

 

		





See in-line 
 
From: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, March 28, 2012 12:03 AM
To: Janardhanan Pathangi Narasimhan
Cc: Donald Eastlake; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; 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.   
-------[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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: [phone]
Email: [e-mail] <mailto:[e-mail]> 
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Janardhanan Pathangi Narasimhan <[e-mail] <mailto:[e-mail]> > 

2012-03-28 14:27 

  

 

收件人

"[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> > 

抄送

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

主题

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 

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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: [phone]
Email: [e-mail] <mailto:[e-mail]> 
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 

Janardhanan Pathangi Narasimhan <[e-mail] <mailto:[e-mail]> > 

2012-03-28 00:09 

  

  

 

收件人

"[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "Tissa Senevirathne (tsenevir)" <[e-mail] <mailto:[e-mail]> > 

抄送

Donald Eastlake <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> > 

主题

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: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: [phone]
Email: [e-mail] <mailto:[e-mail]> 
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 

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

2012-03-27 18:12 

  

  

  

 

收件人

<[e-mail] <mailto:[e-mail]> >, "Donald Eastlake" <[e-mail] <mailto:[e-mail]> > 

抄送

[e-mail] <mailto:[e-mail]> , [e-mail] <mailto:[e-mail]>  

主题

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: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft 


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 <[e-mail] <mailto:[e-mail]> > 
发件人:  [e-mail] <mailto:[e-mail]>  

2012-03-27 06:38 

  

  

  

  

 

收件人

[e-mail] <mailto:[e-mail]>  

抄送

	
主题

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



  

  

  

  

  

 

		





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   [phone] (cell)
155 Beaver Street, Milford, MA 01757 USA
[e-mail] <mailto:[e-mail]> 

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


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

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

 
--------------------------------------------------------
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
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge