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 protected]] > Sent: Tuesday, May 13, 2014 2:35 AM > To: Black, David > Cc: [email protected] > Subject: Re: Proposal for some minor amendments of the arch draft > > > 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] _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
