On 16/05/14 05:59, Black, David wrote: > 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.
That is mostly orchestration at present. It is probably a better place that 4.x. > > 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. This is OK. > > if the above two approaches seem ok, please give us some time to come > 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. > > 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
