Now, let’s think about this. Why waste 4-bits or a byte for every single packet when the UDP port number can be your version number. That UDP port number has to be in every single packet anyways.
Why keep the port number the same and change the version number when the same cost of product change will occur. To save UDP port numbers? What if people wanted to filter v1 versus v2, doing it with a UDP port number is a simpler and already deployed way to differentiate services. Now those middle boxes have to look even deeper into the header? Lets be practical, Dino > On Jul 26, 2016, at 12:13 PM, Joe Touch <[email protected]> wrote: > > > > On 7/26/2016 11:59 AM, Michael Smith (michsmit) wrote: >> Agreed. Given that considerable time has past since the initial decision >> and as long as we are re-visiting it, why not adopt VXLAN ? It has seen >> considerable deployment and implementation. Its format is compatible with >> LISP which serves to provide a common frame format for L2 and L3 overlays. >> One issue raised in the meeting was that VXLAN is an independent track >> RFC. I may be naïve, but this seems fairly easy to remedy. Worst case, >> call it something else, change the UDP port number (I’m not aware of any >> hardware implementations that couldn’t handle changing the port number), > > All recent assignments are *required* to support in-band versioning, so > at worst a version number bump would be sufficient. > > Joe > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
