Re: [trill] Poll for WG adoption of draft-perlman-trill-smart-endnodes

Hi,Thoms,

Please see my comments inline marked with [HFW].

I am opposed to the WG taking on this document. My reasoning is
simple: this document is not needed and is unlikely ever to be
implemented in a product or see deployment in anything more than a
research setting. The stated motivation behind this document is to
move (offload) the [Dest, RB] mappings an RB maintains into a "smart
endnode", thereby reducing the size of the table in RBs.

//[HFW] Why do you think the document is not to implemented? Just based on 
your inference? Actually, we cooperate with our customers to implement 
TRILL and VxLAN on servers/hypervisors. I think TRILL forwarding is 
extension downside to servers is the tendency. These ideas improve the 
TRILL deployment.

I find the problem motivation and proposed solution direction
uncompelling.

First, today's memory sizes in switching devices is quite large (and
of course getting larger). I just don't see reducing the table size in
RBs as an actual problem that needs solving in practice -- and
especially not by having end hosts take on this responsibility. Do we
have any feedback from actual deployments suggestion RB table sizes
are too limited?

//[HFW]In the cloud data center, there are many servers, and the server 
could be
Virtualized to several VMs, each VM has their MAC, so I think the (MAC, 
nickname) entry for the data center network could be very large.
Now we have not any feedback from actual deployment, because TRILL is not 
widely deployed. But we cannot think that this is not an issue in the 
future.  The RB table issue is needed for discussion.

Second, a host is unlikely to implement this. They have little
motivation to do so.  The cost is implementation/operational
complexity, and the only benefit is it it would support what arguably
would be a low-end and marginal RB product. A better investment would
be to get a better RB.

//[HFW]The VxLAN/NvGRE is developed in vSwitch in many vendors now. I 
wonder if most of the vSwitch implement VxLAN/NvGRE,  does the TRILL 
really need in the aggregation and core switches? So the idea of smart 
endnode could have great benefit for the TRILL deployment. 
Consider the cost, if RBridge support the high capacity table entries, the 
cost for RBridge would be very high. The solution can reduce the cost of 
RBridge indeed.

Up leveling, this document exemplifies a general trend this WG has of
taking on marginal work that has little or no real likelyhood of ever
being used or deployed. I think the WG would focus on getting its (few
remaining) core items completed, and then shutdown until a time that
actual deployment experience results in the need to do additional
work.

//[HFW]This document optimize the performance of edge RB, it is in scope. 
There is a description in charter "The current work of the working group 
is around operational support and additional extensions and optimizations 
of TRILL for the properties of the networks on which it is deployed."
This document is the optimization to TRILL protocol and to improve the 
TRILL deployment.

Bottom line: this work is not needed and the WG should stop taking on work 
that has at best marginal value.
// [HFW]On the contrary, I think we should do more attempts to help the 
deployment of TRILL, rather than just saying no.

Thomas Narten <narten@us.ibm.com> 
发件人:  "trill" <trill-bounces@ietf.org>
2013-11-19 21:49

收件人
Donald Eastlake <d3e3e3@gmail.com>
抄送
"trill@ietf.org" <trill@ietf.org>
主题
Re: [trill] Poll for WG adoption of     draft-perlman-trill-smart-endnodes

> As announced that the TRILL WG meeting yesterday, this is a poll for
> TRILL WG adoption of draft-perlman-trill-smart-endnodes-02.txt. It is
> expected to run through November 24th.

I am opposed to the WG taking on this document. My reasoning is
simple: this document is not needed and is unlikely ever to be
implemented in a product or see deployment in anything more than a
research setting. The stated motivation behind this document is to
move (offload) the [Dest, RB] mappings an RB maintains into a "smart
endnode", thereby reducing the size of the table in RBs.

I find the problem motivation and proposed solution direction
uncompelling.

First, today's memory sizes in switching devices is quite large (and
of course getting larger). I just don't see reducing the table size in
RBs as an actual problem that needs solving in practice -- and
especially not by having end hosts take on this responsibility. Do we
have any feedback from actual deployments suggestion RB table sizes
are too limited?

Second, a host is unlikely to implement this. They have little
motivation to do so.  The cost is implementation/operational
complexity, and the only benefit is it it would support what arguably
would be a low-end and marginal RB product. A better investment would
be to get a better RB.

Up leveling, this document exemplifies a general trend this WG has of
taking on marginal work that has little or no real likelyhood of ever
being used or deployed. I think the WG would focus on getting its (few
remaining) core items completed, and then shutdown until a time that
actual deployment experience results in the need to do additional
work.

Bottom line: this work is not needed and the WG should stop taking on
work that has at best marginal value.

Thomas

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill