Subject: [nvo3] Role of control plane in draft-dt-nvo3-encap-01

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 May 2017 13:03:23 -0400

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 May 2017 13:44:00 -0700

On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <[email-masked]> wrote:
>
> Tom,
>
> I'm trying to make sure we capture the discussion about the control plane
> accurately.
>
> 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
> 2. The egress NVE being able to control the order of the extensions in the
> packet.
>
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?

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 May 2017 22:50:42 -0700

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

> 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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 May 2017 07:19:07 -0700

On Thu, May 18, 2017 at 10:50 PM, Erik Nordmark <[email-masked]> wrote:
>>> classical
>>> the
> 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.

> 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

>>> the

---

From: Sami Boutros <[email-masked]>
Date: Fri, 19 May 2017 14:34:40 +0000

>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
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>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=

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 May 2017 08:00:26 -0700

> Not sure, I get that, why wouldn’t an NVE be capable to specify the set of
I don't have any concerns of the NVE's ability to specify a set of
extensions it want to support.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 May 2017 13:30:47 -0700

Tom,

Sounds like it makes sense to at least clarify the draft to capture the 
set and the order as separate items.
The we can recommend that control planes add a way to carry the set.
And mark the ordering part as an item for further study.

Thanks,
   Erik