Sorry, not convinced. What you point me to is general services that run at a 
session layer. We are talking about using (err, misusing?) UDP for a network 
layer function.

Dino

> On Jul 26, 2016, at 12: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

Reply via email to