Subject: Re: [nvo3] draft-rekhter-nvo3-vm-mobility-issues-03.txt as nvo3 WG documen

From: Thomas Narten <[email-masked]>
Date: Mon, 10 Dec 2012 13:46:35 -0500

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/nvo3