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