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
