Read BCP 165. The cost to your protocol is as little as 1 bit and it protects a global resource.
Joe > On Jul 26, 2016, at 12:22 PM, Dino Farinacci <[email protected]> wrote: > > 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
