Hi Thomas/ Larry, Thanks for your replies.
> > 1. Abstract - I am not happy with the mention of NIC in the abstract, > what > > happens in case of LOM's. I think we should just state network hardware > > instead of NIC. > > > how about: changing "NIC" to "virtual network interface", i.e: > > NEW: > > The primary functionality required is provisioning virtual > networks, associating a virtual machine's virtual network > interface(s) with the appropriate virtual network, and maintaining > that association as the virtual machine is activated, migrated > and/or deactivated. > > Sounds good to me. The reason I raised the question was I had different notions of LOM, NIC and vNIC. Searching for LOM on google takes you to http://www.networkworld.com/details/826.html and it did not help either. > > > 2. Abstract - I agree with the idea of the statement: > > Use of an overlay-based approach enables scalable deployment on large > > network infrastructures. > > > From the edge perspective however overlays cause scalability limitations, > > however P2P models work well as the edge is not loaded (take the case of > > IPsec tunnels versus MPLS VPN). So I think you may want to clarify the > > statement. > > Not sure what you think I should say instead. I'm not immediately sure > in what dimension you think P2P scales better. I don't know what > assumptions you are making... > > Take an example of 2 dominant VPN technologies - IPsec VPN (overlay) versus the case of MPLS VPN (P2P) services. I was just trying to suggest that we can state that using Overlay's allow the "core network" to scale. It pushed the scale limitations to the edge device however. > > 3. Introduction - We talk about tenant having expectation of > > separation of resources. We however only talk of traffic separation > > in the whole document. Are there other resources we are considering > > here? If so we may want to state them. > > Do you have specifics? I'd like to hear from others on this. I can > imagine some things here, but I'm not at all sure I want to tackle > them now. IMO, the primary focus should be on traffic separation. > > There is work on various features like bandwidth separation etc. My point however was, that we seem to be talking about separation of resources in places, but the only thing we talk about in detail is traffic seperation. I know folks are trying to do interesting work in the IETF CONEX group. > > 4. In the document the assumption seems to be that each end station can > > connect to "a" virtual network. Is that what we intend to state or do we > > also consider connecting to multiple networks - though for each we could > > have a different MAC address? > > Unless others say otherwise, I'd assume that a given interface/VNIC > connects to exactly one VN. A VM can have multiple interfaces > (physical or virtual) if it wants to connect to multiple VNs. This > would be analogous to VPNs today. > > In other words, I think connections to multiple VNs is supported by a > simple model. Is there any reason to go further? > I would agree here. > > > 5. Section 2.1 - In my view Multi-tenancy and elasticity impose different > > requirements and should be treated as different problems. > > How about I change the name of 2.1 as follows: > > Old: > > 2.1. Multi-tenant Environment Scale > > New: > > 2.1. Elastic Provisioning > Sounds good. We could as well have 2 different requirements is what I was alluding to. > > > 8. Section 2.5 - I think another idea should be that we need to allow the > > tenant to do addressing irrespective of the infrastructure, to have clear > > tenant/ provider boundaries. > > How about: > > <section title="Separating Tenant Addressing from Infrastructure > Addressing"> > <t> > It is highly desireable to be able to number the data center > underlay network using whatever addresses make sense for it, > without having to worry about address collisions between > addresses used by the underlay and those used by > tenants. > </t> > > Sounds good to me. > > > 9. Section 2.6, another use case is the fact that there will be > > communication required between devices in the DC and end points in the > > branch/ campus network, which may not support the NVO3 > > functionality. > > Old: > > 2.6. Support Communication Between VMs and Non-virtualized Devices > > Within data centers, not all communication will be between VMs. > Network operators will continue to use non-virtualized servers for > various reasons, traditional routers to provide L2VPN and L3VPN > services, traditional load balancers, firewalls, intrusion detection > engines and so on. Any virtual network solution should be capable of > working with these existing systems. > > > New: > > Not all communication will be between devices connected to > virtualized networks. Devices using overlays will continue to > access devices and make use of services on traditional, > non-virtualized networks, whether in the data center, the public > Internet, or at remote/branch campuses. Any virtual network > solution should be capable of interoperating with existing > routers, VPN services, load balancers, intrusion detection > servics, firewalls, etc. > > > 10. Section 2.7, why would sparsely populated members in a DC be highly > > distributed, as a general characteristic. > > It's not that I'd always expect sparsely populated & highly > distributed in all cases, but with lots of VM migration, even if you > started out with good locality, you'd lose it over time. > > Thus, we need to design for it. > OK. I think we could clarify as above. I agree that could be the case, but for most parts we would have locality in my view. > > > 11. Section 2.7, though the network infrastructure is administered by a > > single domain, in my view the virtual infrastructure should be > independent > > of the physical one and should be operated by the tenant infrastructure. > > Look at the case of Vyatta like routers that can be spun on demand. > > Not necessarily disagreeing. But is there a need for specific text to > talk about this? > You talk about Network infrastructure administered by a single domain. From your answer it seems like underlay physical infrastructure here. Thanks, Vishwas > > > 1. s/ resiliancy/resiliency > > 2. s/ trade offs/ tradeoffs > > OK. > > Thomas > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
