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

[Tom Herbert <[e-mail]>]

On Fri, May 19, 2017 at 7:34 AM, Sami Boutros <[e-mail]> wrote:
>
>
>
>
>
> On 5/19/17, 7:19 AM, "nvo3 on behalf of Tom Herbert" <[e-mail] on behalf of [e-mail]> wrote:
>
>>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.
>
> Not sure, I get that, why wouldn’t an NVE be capable to specify the set of
> Extensions it support?
>
I don't have any concerns of the NVE's ability to specify a set of
extensions it want to support.

> Thanks,
>
> Sami
>>
>>>
>>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>_______________________________________________
>>nvo3 mailing list
>>[e-mail]
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=o-PlsWullzzWQ-0KCJSX46anwVXVyMF9dg80UDgScZA&s=1qGNWNtbytQZXrTSRn6Gm49QmBEParIlBAVi-eVZTVM&e=