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.
> >>> >> 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://www.ietf.org/mailman/listinfo/nvo3
