On 5/19/17, 7:19 AM, "nvo3 on behalf of Tom Herbert" <[email protected] on
behalf of [email protected]> wrote:
>On Thu, May 18, 2017 at 10:50 PM, Erik Nordmark <[email protected]> wrote:
>> On 05/18/2017 01:44 PM, Tom Herbert wrote:
>>>
>>> On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <[email protected]> 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?
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
>[email protected]
>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=
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
