I agree with Maria's assessment and comments from Thomas. > Do you support adoption of this draft as-is (yes/no)?
No. > If no, would you support adoption of this draft with changes, > and if so, what (e.g. more Layer 3 content)? Possible .. however such evaluation needs to be made when such changes are done .. not before. At this point the draft simply does not focus on practical issues so I am not sure what technical purpose it's adoption may serve. > If no, should all of the VM mobility problem statement be added to the > NVO3 problem statement draft? I think having single problem statement document is helpful. Rgs, R. On Mon, Dec 10, 2012 at 10:47 PM, NAPIERALA, MARIA H <[email protected]> wrote: > 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
