Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

[Joe Touch <[e-mail]>]

Hi Tom,


On 2/16/2017 4:10 PM, Tom Herbert wrote:
>>> But, as I said this idea creates a new dependency on a control plane
>>> which is TBD. I'm afraid this could be a opening a Pandora's box of
>>> new complexity that the group didn't bargain for...
>> You need a control plane to setup the endpoints of a tunnel anyway.
>> Indicating a fixed set of features for that tunnel is as easy as "use
>> Bob", where "Bob" is defined elsewhere.
>>
> The interaction between the control plane and dataplane will need to
> be explicit in the definition of the protocol as it is in TCP. And
> this method creates new conditions that need to be handled. For
> instance, if Bob says that he'll send option A and then option B, but
> we get a packet from him with option B before option A then what does
> that mean? Is this an error? 
It depends on what we define, but IMO that's a silent drop or - at best
- a rate-limited warning in the log file.

> What if Bob wants to send options A,B,C
> in that order, but Sally wants to only receive them in order C,B,A?
I was using "Bob" to refer to the protocol configuration, the way that
we use strings to refer to such parameterization of more flexible
systems for security algorithms. You're using Bob to refer to an
endpoint, so let's call the protocol configuration we want to use "kiwi".

E.g., see the list of encryption transforms for IKE.

In this case, we could define one required protocol that can easily be
"X with TLVs A, B, C in that order only".

My point is that the protocol used need not be so ossified in its
specification, e.g., the encapsulation protocol could specify TLVs
A,B,C,D,E, and F, and allow any order in general. However, the
complexity of dealing with all possible combinations and orders need not
impact NVO3.

> Whose ordering requirements take precedence?
The same as any negotiation protocol - there's typically an offer and a
counter based on a subset. You say you want "kiwk, orange, or grape" (in
order of preference) and the receiver either picks ONE or refuses.
That's going to have to happen anyway.

> What about middleboxes
> that need to parse TLVs, would they have a say in this negotiation?
Middleboxes don't play by any known rules. They'd have just as much
trouble with TLV ordering and selection as they would with changes from
"don't care" to "care" of bits in bitfields.

> What about options in a multicast packet, what ordering of TLVs would
> be used for those? And so on...

Same issues apply in all cases. TLVs are no different from bitfields.
You need to negotiate what they mean in both cases for all uses.

I'm not arguing for TLVs, just pointing out that the claimed reasons for
picking bitfields over TLVs is nonsense.

Joe