Hi Ran,
On 10-11-17 12:19 PM, RJ Atkinson wrote:
On 17 Nov 2010, at 11:39 , Suresh Krishnan wrote:
Another alternative would be to retain your draft,
but edit it along the lines I suggested earlier,
whereby explicit language prohibiting creation of new
extension headers that have either (a) hop-by-hop
or (b) end-to-end nature is added in.
You said that, in your implementation, it is easier for the hardware to
parse a hop-by-hop or destination options rather than an extension
header. But this view is not something I have ever seen expressed in the
past. In fact I have heard exactly the opposite view expressed by other
vendors (and this matches my experience coding them on a network
processor fast path) and that was the inspiration for this draft.
I think this is the bone of contention. If we can quantify the efforts
in one way or another, there will be no ambiguity going forward.
I really appreciate your open-mindedness on this.
No problems. At the end, all we want is a defined extension mechanism
for implementations to follow.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
