Hi Vishwas, I've included some responses below. - Larry
From: Vishwas Manral <[email protected]<mailto:[email protected]>> Date: Tuesday, June 26, 2012 4:10 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Thomas Narten <[email protected]<mailto:[email protected]>>, Murari Sridharan <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>>, Cisco Employee <[email protected]<mailto:[email protected]>>, Dinesh Dutt <[email protected]<mailto:[email protected]>> Subject: [nvo3] draft-narten-nvo3-overlay-problem-statement Hi guys, I looked at the draft and here are my first pass comments: 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. I don't understand your concern. My understanding is the term NIC covers all physical form factors and is more about the functionality. e.g. see this definition of NIC on wikipedia which includes LOM: http://en.wikipedia.org/wiki/Network_interface_controller 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. 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. 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? 5. Section 2.1 - In my view Multi-tenancy and elasticity impose different requirements and should be treated as different problems. 6. Section 2.2 - Besides retaining IP/ MAc, we also need to retain the port numbers, assume TCP. 7. Section 2.2 - We talk about "today" IP address based on ToR. I think we should state in traditional DC etc. Also it should go before we talk about VM/ vMotion etc. 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. Isn't that covered in section 2.2? 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. 10. Section 2.7, why would sparsely populated members in a DC be highly distributed, as a general characteristic. To take advantage of available compute resources at the time of placement or VM migration for resource optimization. 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. I think this might be addressed by expanding section 3 point 1 to include not just separation between virtual networks but also between virtual networks and the underlying infrastructure. Typo -------- 1. s/ resiliancy/resiliency 2. s/ trade offs/ tradeoffs Thanks, Vishwas
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
