Maria, How does your note, below, relate to Matthew's original email?
Irrespectively Yours, John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > NAPIERALA, MARIA H > Sent: Monday, December 10, 2012 1:47 PM > To: Thomas Narten; [email protected] > Subject: Re: [nvo3] draft-rekhter-nvo3-vm-mobility-issues-03.txt as > nvo3 WG document > > I have similar observations about the draft. I understand that the > draft tries to describe a problem statement with layer 2 data center > networks, with an emphasis how it relates to VM mobility. Most of text > in the draft states obvious and known issues with using VLANs. It also > limits the scope to layer 2 CUGs (btw, it introduces yet another > definition of a CUG). > > The subject matter of this draft clearly overlaps with the nvo3 general > problem statement (for which there is already a separate document > accepted by the WG). To avoid any confusion, it would better to merge > all nvo3 problem statement aspects into one document. > > > Maria > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Thomas Narten > > Sent: Monday, December 10, 2012 1:47 PM > > To: Ali Sajassi (sajassi) > > Cc: [email protected]; [email protected]; matthew.bocci@alcatel- > > lucent.com; Yakov Rekhter; [email protected]; [email protected]; > > [email protected]; Luyuan Fang (lufang) > > Subject: Re: [nvo3] draft-rekhter-nvo3-vm-mobility-issues-03.txt as > > nvo3 WG documen > > > > Ali, > > > > I really am having trouble understanding the broader purpose and > scope > > of this document. > > > > First, it talks about CUGs. Previous list discussion seems to confirm > > that a CUG is equivalent to an NVO3 Virtual Network. I.e., it simply > > is another name for describing a networking construct where a set of > > machines (or applications) are allowed to talk to each other. I.e., > > VLANs are an implementation of CUGs. BGP-VPNs are another mechanmism > > for implementating them. > > > > IMO, the concept/definition of CUGs should go into the framework > > document. It is not helpful to be using different terms for what > > (appears to be) the same thing as other defined terms. The best place > > to sort that out is in the framework document. [other documents also > > define/use CUGs and my comment here applies to them as well.] > > > > Second, this document is very L2 focused, and on VLANs in particular. > > It really seems like it comes from the perspective of L2VPN -- that > > is, gluing together different L2 domains across a WAN. There is > > discussion about how VLANs having signficance on one DC may not have > > significance in a different DC (i.e., they administered separately). > > Or that if you move a VM that is using VM-defined C-TAGS, those C- > TAGs > > may not be appropriate in the new location. I agree with all that, > but > > this is very L2 centric. > > > > More to the point, In NVO3, the need for VLANs mostly (if not > totally) > > goes away. It is the NVO3 Context ID (i.e., the NVO3 VN mechanism) > > that provides tenant separation. > > > > > Besides optimal routing that is covered in section 3.4, the draft > > also > > > talks about layer-2 extension and differentiation between VLANs and > > > VLAN-Ids - sections 3.1, 3.2, and 3.3. Although section 3.5 may be > > obvious > > > but it is worth to be noted as well. > > > > Section 3.1 seems to me to be coming from an L2VPN-ish perspective, > > per the comments above. E.g.: > > > > 3.1. Usage of VLAN-IDs > > > > This document assumes that within a given non-trivial L2 physical > > domain traffic from/to VMs that are in that domain, and belong to > > the > > same L2-based CUG MUST have the same VLAN-ID. This document > assumes > > that in different non-trivial L2 physical domains traffic from/to > > VMs > > that are in these domains and belong to the same L2-based CUG MAY > > have either the same or different VLAN-IDs. Thus when a given VM > > moves from one non-trivial L2 physical domain to another, the > VLAN- > > ID > > of the traffic from/to VM in the former may be different than in > the > > latter, and thus can not assume to stay the same. > > > > What is a "non-trivial L2 domain" in NVO3? A significant reason for > > NVO3 is to decouple NVO3 from the underlying L2 domain -- and to > push > > NVEs as far to the edge as possible, i.e., so that the L2 domain > > doesn't matter anymore. > > > > Section 3.2 seems to just say that if you move a VM, you must > maintain > > connectivity, and the VM must continue to be able communicate. I > > agree, but is this the main point being made here? > > > > > Also, this draft talks about the presence of these mobility issues > > not > > > just for intra-DC but also for inter-DC scenarios (and furthermore > > > inter-AS). > > > > IMO, this is mostly obvious, at least the way described in the > > document. > > > > Section 3.3 says: > > > > 3.3. Layer 2 Extension > > > > Consider a scenario where a VM that is a member of a given L2- > based > > CUG moves from one server to another, and these two servers are in > > different L2 physical domains, where these domains may be located > in > > the same or different data centers. In order to enable > communication > > between this VM and other VMs of that L2-based CUG, the new L2 > > physical domain must become interconnected with the other L2 > > physical > > domain(s) that presently contain the rest of the VMs of that CUG, > > and > > the interconnect must not violate the L2-based CUG requirement to > > preserve source and destination MAC addresses in the Ethernet > header > > of the packets exchange between this VM and other members of that > > CUG. > > > > The problem statement document doesn't say much (or anything) about > > inter DC connectivity. That is partly because of the way NVO3 is > > chartered, and partly because it should be self-evident that if you > > have you can move VMs to another DC without there being connectivity > > to that DC. I agree this should be discussed somewhere, but wouldn't > > it be better to just say this in the problem statement, to the degree > > it needs to be said? > > > > > I either don't see these mobility issues been covered in the > problem > > > statement draft or if they have been covered not to this extent. > > Although > > > you may have a concern regarding proliferation of additional > drafts; > > > however, at the same time we don't want to impede the progress > > > either. > > > > Per my other message, I'm concerned that without some careful > thought, > > this WG could easily have plethora of documents that will be > difficult > > for an outsiders (if not the WG!!) to sort through. > > > > Thomas > > > > > So, if it is decided to merge this draft with problem statement > > draft, > > > then the coverage in problem statement draft should be to the same > > extent > > > as this one. Since Yakov is the primary author of this draft, I'd > > like to > > > hear his take. > > > > > > > Cheers, > > > Ali > > > > > > > > On 11/28/12 11:02 AM, "Thomas Narten" <[email protected]> wrote: > > > > > >Yakov, > > > > > > > >Actually, the chairs did respond to your first request. See > > > >http://www.ietf.org/mail-archive/web/nvo3/current/msg01764.html. > > > > > > > >The one response to this I see in the archive said: > > > > > > > >> > Can you and/or your co-authors please comment on the following > > two > > > >> > questions: 1. How does the draft apply to our charter and > > milestones? > > > >> > > > >> WH> it addresses the following part of the charter: > > > >> Support the placement and migration of VMs anywhere within the > > data > > > >> center, without being limited by DC network constraints such as > > the IP > > > >> subnet boundaries of the underlying DC network. > > > > > > > >This seems like a pretty weak justification to me. Not every > > document > > > >related to VM migration will automatically be in scope as an NVO3 > > > >WG document. IMO, this document by itself doesn't really make > sense > > > >as > > a > > > >standalone WG document. > > > > > > > >The document is pretty short. If you skip the > > definitions/background, > > > >the "meat" seems to be section 3.4. This section covers ground > that > > > >the problem statement covers (though could be expanded on, i.e., > to > > > >explicitly also mention the case of in-bound traffic). I.e., see > > > >section 3.7. (And note that the issue can occur within a single > > > >data center, you don't need to have a virtual network span > multiple > > > >data centers as your document seems to focus on.) > > > > > > > >My suggestion would be to have the problem statement expand > section > > > >3.7 to explicitly cover both the ingress and egress cases. > > > > > > > >Thomas > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
