19/02/2024 20:50, Stephen Hemminger: > On Fri, 12 Jan 2024 10:02:05 +0200 > Gavin Li <gav...@nvidia.com> wrote: > > > Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header > > fields. This patch series add support for flags and reserved field 0 and > > 1. > > > > Below is the VXLAN-GPE header defined in the lasted draft. > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R|R|Ver|I|P|B|O| Reserved |Next Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VXLAN Network Identifier (VNI) | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Would recommend against implementing anything in a draft RFC. > Things can change. Learned the hard way when doing VXLAN driver for Linux. > The hardcoded port value in the Linux VXLAN driver is wrong because it matched > the draft RFC (got changed in final version). Because of strict compatibility > requirements the Linux driver could not be changed to the correct value.
The problem is that standardization may be slow. Would it be acceptable without any compatibility guarantee?
