Joe, let’s agree to disagree. Thanks for the discussion.

Dino

> On Jul 21, 2016, at 4:04 PM, Joe Touch <[email protected]> wrote:
> 
> 
> 
> On 7/21/2016 3:57 PM, Dino Farinacci wrote:
>> 
>>> Port numbers are assigned for entire services, not for each component
>>> nor for each version of a protocol anymore (see the two docs of BCP
>> GUE is a different service than Geneve. They both have different ports, do 
>> they not? 
> Yes, those are completely different.
> 
>> This was our premise with LISP. That if we needed to have a version 2, get a 
>> new UDP port number rather than carry a version number in every packet for 
>> really no good reason. 
> 
> That won't happen, as per BCP 165. You're expected to support versioning
> inside your protocol, not by consuming the port number space.
> 
>> People said you shouldn’t do that. That we can’t allocate ports willy nilly. 
>> Fast forward 8 years. We have new UDP port allocations for VXLAN, VXLAN-GPE, 
>> GUE, and Geneve. And you know there are more.
> Sure - for whole-cloth new services. Applications for incremental
> updates or multiple ports for components of a service are routinely
> rejected.
> 
>> 
>>> 165).  So at best you're just saying that the entire header is redefined
>>> for each version number in the header (which admittedly is just a
>>> two-step check - port and version - rather than a one-step of just port).
>> Yep. But not version. Your port number is your version number.
> Absolutely not. Again, see BCP 165.
> 
> A port number defines a service, not a version thereof.
> 
> ...
>> How long has it been since we created the IPv6 header, and vendors
>> still do not know what to do with the flow field. 
> 
> Until it is - which is happening as we speak to reduce reordering in
> multipath routing.
> 
> We don't deploy new IP protocols every 3 years, but every few years a
> new feature becomes more widely supported. That's the point of
> extensible protocols - to change gradually and incrementally.
> 
> Joe

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to