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?
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.
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
