[V1 0/5] support VXLAN-GPE header fields(flags, rsvd0 and rsvd1) matching

[Thomas Monjalon]

19/02/2024 20:50, Stephen Hemminger:
> On Fri, 12 Jan 2024 10:02:05 +0200
> Gavin Li <gavinl at 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?