I am in favor of publishing the three encaps as informational. As Tom explained, questions asked in the room were perhaps misinterpreted at the time, which is clear from the list now with many people who were present in the room clearly favoring publishing the three options.
Nevertheless, if one option has to be picked, I strongly hope coins don't play a role in it. :) Best, Vina From: nvo3 <[email protected]<mailto:[email protected]>> on behalf of Alia Atlas <[email protected]<mailto:[email protected]>> Date: Tuesday, July 26, 2016 at 12:42 PM To: Joe Touch <[email protected]<mailto:[email protected]>> Cc: Tom Herbert <[email protected]<mailto:[email protected]>>, "Michael Smith (michsmit)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Matthew Bocci <[email protected]<mailto:[email protected]>>, "Paul Quinn (paulq)" <[email protected]<mailto:[email protected]>>, Dino Farinacci <[email protected]<mailto:[email protected]>>, Jesse Gross <[email protected]<mailto:[email protected]>>, "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Consensus call on encap proposals 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]<mailto:[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]<mailto:[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]<mailto:[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
