On Fri, May 19, 2017 at 7:34 AM, Sami Boutros <[email protected]> wrote: > > > > > > 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? > 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 >>[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
