Hi Lucy, See my answers inline.
Marc > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Tuesday, March 05, 2013 4:20 PM > To: LASSERRE, MARC (MARC); Benson Schliesser; [email protected] > Subject: RE: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > Hi Marc, > > Please see inline. > > > -----Original Message----- > > From: LASSERRE, MARC (MARC) > [mailto:[email protected]] > > Sent: Tuesday, March 05, 2013 4:36 AM > > To: Lucy yong; Benson Schliesser; [email protected] > > Subject: RE: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > Lucy, > > > > See my comments below. > > > > Thanks, > > Marc > > > > > -----Original Message----- > > > From: [email protected] > [mailto:[email protected]] On Behalf > > > Of Lucy yong > > > Sent: Monday, March 04, 2013 7:22 PM > > > To: Benson Schliesser; [email protected] > > > Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > > > I read this version and glad to see adding a section for > VM mobility. > > > > > > Some comments: > > > > > > 1) The introduction states that the rationale for using overlay > > > networks in DC is for building multi-tenant data center > networks. It > > > also mentions that a tenant network may consist of one or more > > > virtual networks. However, the architecture and reference > model is > > > focusing on single virtual network overlay architecture > only. It is > > > lack of describing the architecture and model about > multiple virtual > > > networks forming one tenant network, i.e. virtual network overlay > > > interconnections. > > > > The framework draft does not assume that a tenant network only > > consists of a single VN. > > Multiple VNs can belong to a single tenant. > [Lucy] OK, glad that you clarify that. > > > > > > > > Thus, a question to the WG chair, is this the scope for > nvo3 WG? If > > > yes, that is fine and the framework document should make it very > > > clear that the framework document describes architecture > model of a > > > virtual network and only applies to a tenant network if > it consists > > > of one virtual network that may be implemented by either > L2 overlay > > > or L3 overlay. a tenant network that contain more than > one virtual > > > networks is outside scope of this document. If not, we can either > > > have one framework draft to architect both, or we have > two separate > > > documents, one to intra virtual network overlay and another for > > > inter virtual network overlay. > > > > > > Without clarifying this, I am not clear if the framework > document is > > > working on a virtual network over L3 infrastructure or a tenant > > > network over L3 infrastructure. > > > Two are not equivalents. > > > > Can you point to a specific paragraph where it is mentioned > or implied > > that a tenant network can only consist of a single VN? > [Lucy] Figure 3 is the generic reference model and figure 4 > is the model for NVE. Do you think these two reference models > can represent the network virtual overlay for the tenant > systems in the same and different VNs? If yes, please > explain. I only see the former. While these are generic pictures, figure 4 does show that tenant systems are attached via VAPs to specific VNIs. A set of VNIs with the same VN context (eg VNID) represents a VN. A Tenant system with multiple interfaces can attach to different VNIs, hence be part of different VNs. All this would be quite hard to represent in a single figure. Some add'l text might be needed for clarity. > > > > > > > > 2) Figure 2 illustrate a logical service connectivity for > a single > > > tenant. First of all, it should not show L3 infrastructure in the > > > figure at all. Second, I interpret this > > > > How can routing be avoided when VMs attached to different > L2 networks > > have to communicate? > [Lucy] This is not my point. My point is: this is the tenant > network logical topology view. Why does it show underlying L3 > infrastructure between Rtr1 and Rtr2? Tenant has one Routing > domain and three L2 domain. That is what figure should show, right? VMs do not care what is behind the router boundary. But a tenant knows that routers run over an L3 infrastructure even if in its simplest form both rtr1 and rtr2 could be directly connected. Hence, this is logical connectvity as seen by a tenant. > > > > > figure as one tenant network consisting of four virtual networks, > > > three L2 virtual networks and one L3 virtual network. It should > > > point out that VMs on a L2 virtual network may reside on > the same or > > > different servers. The drawing and team LAN make easy to > thing they > > > are physical LANs. In fact they are not. VM on LAN11 and > VM on LAN12 > > > may reside on the same server. Thus it is very important to state > > > them out clearly. Finally, based on my comment 1), it > should clarify > > > what this document address regarding to this figure here. > > > > This is a *logical* and not a physical connectivity view. > > Whether VMs are on the same server or not is irrelevant. > > Traffic between VMs in the same L2 network is still switched (by a > > virtual or physical switch). > > > [Lucy] OK, this is what I picture. Furthermore, the "logical" > also indicate that VM in LAN11 communicate with VM in LAN12 > MUST go through L3 overlay. > > > > > > > > 3) in Section 3.3, "In DC environments utilizing VM > technologies, an > > > important feature > > > is that VMs can move from one server to another > server in the > > > same > > > or different L2 physical domains (within or across > DCs) in a > > > seamless manner." > > > > > > What does the L2 physical domain mean here? Why need to > mention this? > > > > > > > I'm fine with changing the sentence to "In DC environments > utilizing > > VM technologies, an important feature is that VMs can move from one > > server to another server (within or across DCs) in a > seamless manner". > [Lucy] that is good. > > Regards, > Lucy > > > > > > > > Cheers, > > > Lucy > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] > > > On Behalf > > > > Of Benson Schliesser > > > > Sent: Friday, February 22, 2013 6:28 PM > > > > To: [email protected] > > > > Subject: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > > > > > This email begins a two week working group last call for > > > > draft-ietf-nvo3-framework-02. > > > > > > > > Please review the draft and post any comments to the NVO3 list. > > > > > > > > This working group last call will end on Friday 08-March-2013. > > > > > > > > Cheers, > > > > -Benson & Matthew > > > > _______________________________________________ > > > > 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
