Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01

[Tom Herbert <[e-mail]>]

On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <[e-mail]> wrote:
>
> Tom,
>
> I'm trying to make sure we capture the discussion about the control plane
> accurately.
>
> On 04/15/2017 03:19 PM, Tom Herbert wrote:
>>
>> - I do not believe this is at all plausible. 1) This could only help
>> the endpoints and not intermediate devices. As point out two sentences
>> below transit nodes may need to process extensions. 2) This creates an
>> a dependency between data plane and control plane that is at odds with
>> the requirement for control plane independence (section 2.1 of Geneve
>> draft) 3) This would entail a serious design and implementation effort
>> that would likely only be ready long after the dataplane has been
>> deployed. 4) This creates new problems for interoperability, for
>> instance two devices could support same set of options but can't
>> interoperate because they need different orderings.
>
>
> First of all, the intermediate devices would always have a harder time,
> especially as they might be of an older vintage than the NVEs; the classical
> ossification problem caused by things in the middle.
>
> The draft suggests
>    The Geneve draft could specify that the subset and order of option
>    TLVs should be configurable for each remote NVE in the absence of a
>    protocol control plane.
> thus there is a way to get this off the ground.
>
> I don't think it would be hard to specify how this is carried in an IETF
> standard control plane such as EVPN.
>
> Note that there are two places where the control plane can help.
> 1. The egress NVE only needing to deal with the subset of the defined
> extensions that it implements.
> 2. The egress NVE being able to control the order of the extensions in the
> packet.
>
> Are your concerns only about the second?
>
It's not clear to me how negotiated ordering helps, nor how to resolve
conflicting ordering constraints between to nodes: e.g. for options
A,B,C I might want to send them in order ABC, but maybe you can only
receive them as CBA. Who wins?

> I think for concerns about the amount of headers the hardware can parse, the
> first one is the key one. And it also handles the somewhat esoteric case of
> an egress NVE only supporting one extension.
>
> Thus if the WG thinks the ordering (for egress NVEs which support two or
> more extensions) is not important then WG can remove the ordering part while
> keeping the subset part.
>
It always makes sense to send the minimal amount of information and no
more, but endpoint negotiation doesn't take intermediate nodes into
account and they might drop packets if their parsing buffer is
exceeded. This is a generic problem that is not specific to
encapsulation, for instance extension headers can push things over the
limit. To that end I proposed a "Headers too long" ICMP error in 6man
to provide a feedback signal.

Tom

>    Erik
>
>
>
>