I know it's tempting to dive into technology details and micro-optimization, but can we please stay focused.
This is already a rather long thread - and I am strongly hoping to hear from those who aren't championing their own technology. The question is: (1) Should the WG move forward with one standards track encap? I've heard a lot of concern that we just can't do it, that it's too late, etc. I personally feel that neither of these is true. Working Groups do move past these challenging consensus discussions and go on to be successful and have impact. We can always flip a coin - if the solutions are technically equivalent and so is the support. I personally strongly believe that it will be useful for the IETF to have a single standards track solution. Regards, Alia On Tue, Jul 26, 2016 at 3:32 PM, Joe Touch <[email protected]> wrote: > 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
