Hi Marc, I have sent several comments while ago. Wish to see them to be addressed in new version.
Lucy > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > LASSERRE, MARC (MARC) > Sent: Wednesday, January 23, 2013 4:07 AM > To: Melinda Shore; [email protected] > Subject: Re: [nvo3] Some brief comments on draft-ietf-nvo3-framework > > Hi Melinda, > > Thanks for your feedback. I'm about to issue a new revision of the > draft before WG LC. > I'll address your comments in this next revision (some of which had > already been mentioned > to me e.g. clarification between overlay and underlay). > > Your feedback on the security section is more than welcome. Is there > any chance you could send > something within the next couple of days? > > Marc > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Melinda Shore > > Sent: Wednesday, January 23, 2013 12:37 AM > > To: [email protected] > > Subject: [nvo3] Some brief comments on draft-ietf-nvo3-framework > > > > Summary: while there are a few nits and the security > > considerations need to be completely rewritten, there are > > part of the document that are really excellent. One > > persistent issue is that the language is not always clear in > > distinguishing between L2 and L3 transport, and L2 and L3 overlays. > > > > Melinda > > > > -------- > > > > Introduction (section 1), paragraph 3: what does "cope with" > > mean? (also can delete "in order to") > > > > Could use a little more clarity around what's meant by L2 and > > L3 throughout document. Might be useful to distinguish more > > clearly between L2/L3 transport and L2/L3 emulation > > > > 1.2: under ELAN definition, MEF is not defined, recursive definition > > > > 1.3: top-of-rack should be defined in 1.2, as should DC GW > > > > Rewrite last para of 2.1: > > > > Core nodes utilize L3 techniques to interconnect NVE > > nodes in support of the overlay network. These devices > > perform forwarding based on an outer L3 tunnel header, and > > generally do not maintain per-tenant service state. > > However, some applications (e.g., multicast) may require > > control plane or forwarding plane information that > > pertain to a tenant, group of tenants, tenant service, or > > a set of services that belong to one or more nvo3 > > tunnels. When such tenant or tenant service-related > > information is maintained in the core, overlay > > virtualization provides mechanisms to manage that > > information. > > > > 3.1.5.1 second para "Centralized controllers provide a > > facility to maintain global and distribute that state to the > > network [ ... ]" Global ?state? > > > > 4.1 it's not just "miscommunication" that can lead to > > inefficiencies - misconfiguration may, as well. > > > > Don't really understand the point about hash-based load > > balancing. Is the issue hash collisions or something else? > > > > Section 4 is overall really nice. > > > > The security consideration sections needs a rewrite. I keep > > promising to help with that and not be able to find the time, > > but I'll try to get to it in the next few weeks. > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
