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

[Erik Nordmark <[e-mail]>]

On 05/18/2017 01:44 PM, Tom Herbert wrote:
> 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?

Repeating the above question since you didn't answer: Do you have any 
concerns about #1 i.e. the ability for the egress NVE to specify the set 
of extensions it supports?


>>
> 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?

For the ordering part (i.e., #2 above) just as the set (#1) it is the 
egress NVE which makes a statement in the control plane.
Hence no conflicts.
But an ingress NVE would need to be capable of including different 
subsets (#1) and different order (#2) when encapsulating to different 
egress NVEs.

    Erik


> 
>> 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
>>
>>
>>
>>
>