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

[Tom Herbert <[e-mail]>]

On Thu, Feb 16, 2017 at 4:20 PM, Joe Touch <[e-mail]> wrote:
> 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.
>

The operational issues we see with TLVs in terms of performance and
DDOS are not aberrations, they are fundamental issues we face in
deployment. Maybe with enough work and new implementation these issues
can be addressed in Geneve, but honestly given the history of similar
protocols in IETF and that of nvo3 I have doubts. It would be great if
I'm proven wrong in this :-).

Thanks for the interesting discussion...

Tom