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

[Tom Herbert <[e-mail]>]

On Thu, May 18, 2017 at 10:50 PM, Erik Nordmark <[e-mail]> wrote:
> 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?
>
I'm sorry, I thought I answered the question below.  No to that.

>
>>>
>> 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.
>
Sounds like a lot of complexity to me without a well defined benefit.
I'd suggest investigating some specific examples and implementation to
evaluate whether a negotiated ordering can be helpful and to whom.

Tom

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