On 11/4/14 4:39 PM, Tom Herbert wrote:
On Tue, Nov 4, 2014 at 3:46 PM, Erik Nordmark <[email protected]> wrote:
On 10/26/14 1:20 PM, Tom Herbert wrote:
On Fri, Oct 24, 2014 at 5:44 PM, Erik Nordmark <[email protected]> wrote:
It would be good for the NVO3 WG to have a clear understanding of what
data
needs to be carried with each encapsulated frame. That helps determine
how
flexible and extensible the packet format needs to be.
The experience with extensibility for protocols that are in the dataplane
(be it IPv4 options, IPv6 extension headers, TRILL options, etc) is that
they don't tend to get implemented in hardware. And the dataplane
protocols
tend to have a mixture of hardware and software implementations - which
is
different than TCP which is mostly software.
I don't believe this is always true. We have verified that at least
two NICs and one switch chip are capable of parsing any combination of
keyid, sequence number, and checksum fields in GRE for the purposes of
calculating a flow hash on the inner header. In fact, we've been able
to overload the sequence number and checksum fields for our own
options in lieu of HW not supporting a general L3 extensibility
mechanism (like IP options).
Tom,
I was referring to the case when the IETF defines some options/extensions
mechanism. Those don't tend to get implemented in hardware.
Your example is where some existing hardware parser can be reused for some
other purpose by overloading or redefining existing protocol fields. I've
seen that elsewhere as well. But that doesn't refute the point about lack of
hardware implementations for options/extensions.
I suspect there are several devices that implement keyid option in GRE
and nvgre (for VNID).
But the VNID isn't an optional extension so it is quite natural that
hardware that implements nvgre would implement it.
The issue we see is with IETF standardizing some optional option; in
general hardware implementations do not support those.
In any case, the requirements document probably
needs to expound upon what the hardware requirements of the dataplane
are, especially if such requirements will potentially place
constraints on other requirements (like extensibility).
I definitely don't think (re)using existing hardware should trump other
requirements.
But it would be nice (desirable) if a new protocol (with good support
for extensibility) can be implemented using existing silicon, even if
that silicon can't handle the extensions themselves. That facilitates
incremental deployment.
Regards,
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
