> I agree, at this level we don't need tons of TLV options, but we do
> require some basic protocol extensibility-- so to me at least GRE
> model is reasonable. As I have said several times now, for network
> virtualization we absolutely must have some mechanism to
> validate/authenticate the vnid at the receiver. I think the L2TP
> cookie is a good starting point at least, and I know that I can do

That is why we created the nonce in LISP. It is already there, we don't need an 
extensible header for it. I was told by many service providers that a changing 
24-bit value would be sufficient.

> this simply by appending a 64 bit field in the header like described
> in GUE or maybe defining a TLV in geneve-- still not sure how this
> could work with VXLAN.

It can't as defined other than it sets the N-bit in the header (from LISP) and 
uses the nonce field. But again, we are getting design feature merge conflicts 
and it is being used as a protocol demux.

And allocating a port per protocol is not as bad as you think. There won't be 
that many of them. At leaset we have to discpline ourselves to not create so 
many (unlike what is going on right now).

>> And I mentioned this before at a previous NVO3 meeting. In ~30 years since 
>> the IP header was defined, how much have we, in practice, used IP options.
>> 
> But, how many TCP options have been defined? The reason that we don't

Software dude.

> define new IP options is because nearly all routers assume zero

Hardware dude.

> options for fast path, and so we can never get reasonable forwarding

Right, and why do they do that? The more things you put in the more slower and 
costly hardware gets.

Did you hear Puneet's comment at the mic last week. He is from Broadcom, he has 
the battle scars on his back. He has tons of experience with this. We NEED TO 
LISTEN TO HIM!!!

> performance with new options. Fortunately, we've been able to extend
> TCP to get what we need for the most part, but we have had to make
> concessions because this IP options have been effectively obsoleted (I
> imagine something like ECN might have been done differently if IP
> options were a realistic option).

Dino


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

Reply via email to