Hello Tom et al., >> 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.
Not a contradiction to Erik's statement. He said "tend to" which I think is a fair statement. It's not black/white, if your hardware is a fully programmable NP then you have a chance for later changes - assuming you still have memory/cycles left. If your hardware is an ASIC, typically a pipeline of functional blocks, then you may be bound to what was foreseen during the ASIC design phase. > 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). There is a difference between "not supporting" and "not capable to support". With NICs you may be actually lucky wrt the hardware used. Nevertheless, I think it's not what Erik is highlighting: that the discussion is still a bit vague what the "base" functionality should be, what extensions we can already foresee, what extensions or details we can postpone even when this means the ASIC-based equipment (like a good number of switches on the market) will not handle it in hardware (until an ASIC re-spin). Regards, Marc _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
