Subject: Re: [nvo3] draft-ietf-nvo3-hpvr2nve-cp-req Req-12

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Nov 2017 22:06:04 -0400

Hi Dale,

On Sun, Oct 29, 2017 at 10:58 AM, Dale R. Worley <[email-masked]> wrote:
> Looking at draft-ietf-nvo3-hpvr2nve-cp-req-10, there is
>
>    Req-12: The protocol MUST be able to run over L2 links between the
>    End Device and its External NVE.
>
> This seems to envision a scenario where the networking services provided
> to the Tenant Systems are layer 2 (virtualized Ethernet) and it's
> expected that the trunk between the tVNE and the nVNE will be at layer
> 2.

It means that if you happen to have layer 2 links there, the protocol
has to be able to run over them.

> However, logically, the situation seems to be much more general than
> that.  It looks like it's quite possible to do the tVNE/nVNE trunking at
> layer 3.  It also allows provisioning of VN services to the TS at
> multiple layers.  For instance, if the TS VM is a "container", it's
> quite possible that the TS receives only layer 3 services.  And for a
> more service-oriented architecture, the TS network attachment may be at
> layer 4 or higher.
>
> None of these possibilities seem to affect the structure of the
> tVNE/nVNE protocol, other than that the address families of the network
> identifiers passed in the protocol vary.  (These are the identifiers in
> both the "overlay" family, the service provided to the TS, and in the
> "underlay" family, the trunking connection.)

It's likely that a reasonable protocol could be tweaked in various
ways to run over a wide variety of communications services.

> So it seems to me that we could gain considerable generality at little
> cost by changing Req-12 to something like:
>
>    Req-12a: The protocol MUST be configurable to run over links of any
>    particular networking protocol between the End Device and its
>    External NVE.
>
>    Req-12b: The protocol MUST be configurable to support network
>    services at any particular layer to Tenant Systems.

I think mandatory requirements should be minimal, not aspirational. A
mandatory requirement to run over any protocol at any level seems
truly vast, undefined, and unreasonable. I guess if I say I want it to
run over layer 1 DTMF signaling, how to do that would have to be
included in the protocol specification.

> In practice, this only requires that addresses contained in the protocol
> are tagged with address families, or that the configuration of the
> protocol instance is understood to include the address family
> information.

Keeping mandatory requirements to the minimum in no way means they
cannot or will not be exceeded. I would expect the consensus to
support a protocol that ran over the reasonably useful and
anticipatable link types. But I see no reason to change this mandatory
requirement.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Dale