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
