On 3/19/14, 8:12 AM, Tom Herbert 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.
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.
Tom,
please note that the VXLAN-GPE draft says that a GPE device must not
send non-ethernet frames to a VXLAN device (Section 4.2), exactly to
avoid the problem you describe.
Also note that the draft is focusing on deployments where VXLAN is
already in use, and GPE is introduced incrementally. Hence the use of
the same UDP port for VXLAN and GPE.
I suspect that in the deployment you describe, one could disambiguate
GPE from VXLAN by using two different destination UDP ports. if you
still want to have backward compatibility the sending GPE device will
have to know the receiver's capability (VXLAN or GPE), and pick the
appropriate destination UDP port.
Regards,
Fabio
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
