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

[[e-mail]]

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]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Tissa Senevirathne (tsenevir)" <[e-mail]> 
2012-03-28 15:23

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






See in-line
 
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, March 28, 2012 12:03 AM
To: Janardhanan Pathangi Narasimhan
Cc: Donald Eastlake; [e-mail]; [e-mail]; 
[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]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""




Janardhanan Pathangi Narasimhan <[e-mail]> 
2012-03-28 14:27 


收件人
"[e-mail]" <[e-mail]> 
抄送
Donald Eastlake <[e-mail]>, "[e-mail]" <
[e-mail]>, "[e-mail]" <[e-mail]>, "
[e-mail]" <[e-mail]>, "Tissa 
Senevirathne (tsenevir)" <[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]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


Janardhanan Pathangi Narasimhan <[e-mail]> 
2012-03-28 00:09 
 


收件人
"[e-mail]" <[e-mail]>, "Tissa Senevirathne 
(tsenevir)" <[e-mail]> 
抄送
Donald Eastlake <[e-mail]>, "[e-mail]" <
[e-mail]>, "[e-mail]" <
[e-mail]>, "[e-mail]" <
[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]] On 
Behalf Of [e-mail]
Sent: Tuesday, March 27, 2012 4:49 PM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; [e-mail]; [e-mail]; 
[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]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

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


收件人
<[e-mail]>, "Donald Eastlake" <[e-mail]> 
抄送
[e-mail], [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]] On 
Behalf Of [e-mail]
Sent: Monday, March 26, 2012 9:41 PM
To: Donald Eastlake
Cc: [e-mail]; [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]> 
发件人:  [e-mail] 
2012-03-27 06:38 
 
  
 


收件人
[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]

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

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