[snip] >>> >> 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). >
PQ> That's my definition as well. [Lucy] I disagree this definition. IMO: The backward compatibility means two things: 1) the new implementations can support both the new and old. 2) the old one does not support new but is able to tell that one does not match what it supports. So it can drop the packet and raise an alert. Lucy >> >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
