On 3/19/14 8:12 AM, "Tom Herbert" <[email protected]> wrote:
>On Wed, Mar 19, 2014 at 3:04 AM, Anton Ivanov (antivano) ><[email protected]> wrote: > >> So all of us who use more generic hardware which has a checksumming algo >> which can be adapted to cope, should now abandon any ideas to improve a >> protocol just because three early examples of technology have been >> designed in a manner which explicitly forces their buyers to upgrade >> later. Right? >> >> Interesting idea. To say the least. >> >Whether you like or dislike how hardware vendors implement their >features is immaterial, the fact is that what they are doing is >correct protocol-wise. It is the proposed change to VXLAN protocol >that is not backwards compatible and can lead to incorrect behavior in >existing implementations. I guess I disagree with your definition of backward compatibility. To me, it means new implementations can support both the new and old (old=backward). It doesn't mean that old implementations can somehow magically support new extensions (new=forward). > >Also, I would point, RX csum is only one example. The general >statement is that any legacy implementation which receives a VXLAN >packet with the new format encapsulating a non-Ethernet frame >potentially misinterprets the packet and experiences bad behavior. If the software on host with an old offload NIC wants to support the new extensions, can't the offloads be turned off so they are not misinterpreted? > >> A. >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
