Reforwarding in case it did not come through. -Vishwas
On Tue, Jun 26, 2012 at 4:10 PM, Vishwas Manral <[email protected]>wrote: > 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. > > 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. > > > 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. > > 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. > > Typo > -------- > 1. s/ resiliancy/resiliency > 2. s/ trade offs/ tradeoffs > > Thanks, > Vishwas > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
