Subject: Re: [nvo3] Proposal for some minor amendments of the arch draft

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Tue, 13 May 2014 06:34:31 +0000

Apologies for the delay in the answer.
[snip]

> Pleas suggest specific text changes.  The framework draft already says:
1. Probably a good place will be the end of Section 4, clarification note :

 From NVO3 architecture perspective, for container based lightweight 
virtualization systems (LXC, Solaris Containers, BSD Jail, etc) the Host 
OS is considered to be the hypervisor.

Anywhere else before that is also fine. If this is in section 5 by that 
time it is too late as it has missed 4.1 and 4.2.

2. Remove all "raw" ethernet language from 4.2 and make it more generic. 
You can do the same for LXC (as is), KVM (with our patchsets already in 
the public domain) and UML (with patchsets to go into public domain) 
using hypervisor originated tunnels. This makes a tunnel terminated on a 
kvm or UML vNIC a subcase of 4.2. A host tunnel which has been 
namespaced into a container to look like an Ethernet interface (f.e host 
gre0 described in LXC config as "type phys" and "eth0") falls into the 
same category. This can be considered a split NVE (if the too specific 
language is removed from 4.2).

This is the minimum set of changes which will cover both cases.

A.

>
>         Note that some NVE functions (e.g., data plane and control plane
>         functions) may reside in one device or may be implemented separately
>         in different devices. For example, the NVE functionality could
>         reside solely on the End Devices, or be distributed between the End
>         Devices and the ToRs.
>

[snip]

---

From: "Black, David" <[email-masked]>
Date: Fri, 16 May 2014 00:59:59 -0400

Anton,

1. For the clarification note, somewhere in Section 3.4 looks like a
good place, as that's where the primary discussion that involves
hypervisors is located.

2.  To generalize Section 4.2, the first paragraph uses Ethernet as an
example, which should be ok, although perhaps some editing would help
to make it clearer that it is an example.  OTOH, the last paragraph is
"Specifically" about Ethernet, and that would need to be recast as an
example.

if the above two approaches seem ok, please give us some time to come
back w/specific proposals for text edits.

Thanks,
--David

> -----Original Message-----
> From: Anton Ivanov (antivano) [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2014 2:35 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: Proposal for some minor amendments of the arch draft
> 
>

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Fri, 16 May 2014 07:25:09 +0000

> good place, as that's where the primary discussion that involves

That is mostly orchestration at present. It is probably a better place 
that 4.x.

> "Specifically" about Ethernet, and that would need to be recast as an

This is OK.

> back w/specific proposals for text edits.

Cool. We will probably need to do one more iteration after that as vNIC 
originated tunnels can actually be used directly end to end. In that 
case the NVE itself becomes virtual - there is no need to have a 
physical entity that performs that function.

Personally, I would leave that for later. Once the language in 4.2 
covers tunnels to the vNIC it becomes an obvious extension of 4.2.

A.