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

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 Nov 2013 14:01:33 -0500

Hi,

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.

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

---

From: [email-masked]
Date: Tue, 19 Nov 2013 11:27:34 +0800

Thanks for Donald.

As the co-author of the draft, I support the adoption.

The draft addresses the problem of the size and freshness of the endnode 
learning table in edge RBridge, and reduces the mac address table in the 
switch of the LAN attached to that RBs, by allowing the endnode to 
encapsulate TRILL frame and become a smart endnode. The smart endnode uses 
the edge RBridge's nickname. So there is no additional nickname consumed 
in this document.

Regards.
Fangwei

Donald Eastlake <[email-masked]> 
发件人:  [email-masked]
2013-11-08 03:01

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[trill] Poll for WG adoption of draft-perlman-trill-smart-endnodes

Hi,

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]
_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Nov 2013 08:49:11 -0500

> 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

---

From: [email-masked]
Date: Wed, 20 Nov 2013 15:30:36 +0800

Hi,Thoms,

Please see my comments inline marked with [HFW].

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

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

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

//[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 <[email-masked]> 
发件人:  "trill" <[email-masked]>
2013-11-19 21:49

收件人
Donald Eastlake <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [trill] Poll for WG adoption of     draft-perlman-trill-smart-endnodes

Thomas

---

From: Radia Perlman <[email-masked]>
Date: Tue, 19 Nov 2013 23:37:45 -0800

As a coauthor, I support adoption as a WG document.  It would clearly be
useful, and, as with any technology, it's possible it won't be implemented,
but it's also possible it would be.  Some implementers have expressed
interest in implementing it.

Radia

---

From: [email-masked]
Date: Wed, 20 Nov 2013 16:16:04 +0800

I have read the draft, and support for workgroup adoption. 
The solution in this draft alleviates the pressure of edge RB, which will 
reduce the cost of deploying TRILL.
And as it describes the deployment in hypervisor scenario, it improves the 
deployment of TRILL.

Thanks,
Ting

收件人

主题

Hi,

Thanks,
Donald