Subject: Re: [nvo3] draft-ietf-nvo3-vm-mobility-issues - Technical WG LC comments

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 17 Sep 2014 23:44:54 +0000

I just sent out a message with much the same concerns that David states
below.  I sent mine before reading this message from David.  I see that we
have both picked up on similar issues (some are exactly the same).  I have
to say that I agree with the additional points that David makes below
compared to my message.

Thanks, Larry

On 9/17/14 12:55 PM, "Black, David" <[email-masked]> wrote:

>I have significant concerns about the contents of this draft (beyond
>the missing security considerations), and don't think it's ready for
>the IESG.
>
>-- Section 2.1 Terminology
>
>   In this document the term "Top of Rack Switch (ToR)" is used to refer
>   to a switch in a data center that is connected to the servers that
>   host VMs.
>
>That's a rather poor choice of terminology, as when there are two or
>more layers of switching in a rack, a switch at the top of the rack
>is not actually a "Top of Rack Switch (ToR)" as defined by this draft.
>Something based on "First Hop" would be better than "Top of Rack" and
>see below on whether this draft is assuming external NVEs.
>
>Nit: In the figure: "DBCR" -> "DCBR" (twice).
>
>I'm concerned about the implied requirement for a DCBR as the means
>of external data center connectivity, as it implies an IP (L3) forwarding
>hop at the data center boundary, and there are multi-data-center
>structures
>in which that does not happen.
>
>I don't see any mention of software switches in hypervisors in this
>section.  I think this draft is assuming that NVEs are external, i.e.,
>not located in the server - e.g., otherwise Section 3.3 doesn't make
>much sense.  If so, that crucial assumption needs to be stated.
>
>The term Closed User Group (CUG), appears to be close to, if not the
>same as "virtual network" - use of the latter term would be
>significantly clearer.
>
>-- Section 3.1  Usage of VLAN-IDs
>
>This appears to be a discussion of background that doesn't state a
>problem, hence does not belong in Section 3 (Problem Statement).
>Perhaps this should be section 2.2 ?
>
>Nit:
>
>   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.
>
>That's true on a per-link basis, but not L2-physical-domain-wide, although
>using constant VLAN IDs domain-wide is a common practice because it's
>simple.  Perhaps the assumption should be stated on a per-link basis
>followed by a "common practice" observation.
>
>I'm missing the point of the 3rd paragraph, specifically the
>"contrast" in this text:
>
>   In other words, the
>   VLAN-IDs used by a tagged VM network interface are part of the VM's
>   state and cannot be changed when the VM moves from one L2 physical
>   domain to another, even though it is possible for an entity, such as
>   hypervisor virtual switch, to change the VLAN-ID from the value used
>   by NVE to the value expected by the VM (in contrast, a VLAN tag
>   assigned by a hypervisor for use with an untagged VM network
>   interface can change).
>
>Both hardware and software switches can add, remove and map VLAN-IDs,
>so the VLAN-ID used by the VM can be limited to the link between the
>VM and the first switch.
>
>I don't understand this sentence:
>
>   If the L2 physical domain is extended to
>   include VM tagged interfaces, the hypervisor virtual switch, and the
>   DC bridged network, then special consideration is needed in
>   assignment of VLAN tags for the VMs, the L2 physical domain and other
>   domains into which the VM may move.
>
>What is meant by "special consideration"?
>
>Nit:
>
>   This document assumes that within a given non-trivial L2 physical
>   domain traffic from/to VMs that are in that domain, and belong to
>   different L2-based CUG MUST have different VLAN-IDs.
>
>Again, per-link + "common practice", see above.
>
>-- Section 3.2 Maintaining Connectivity in the Presence of VM Mobility
>
>Again, I don't see a problem stated here.  There's also significant
>overlap
>between this section and both:
>
>	- Section 3.2 of the problem statement draft, and
>	- Section 3.3 of the framework draft.
>
>What is being added here that isn't already covered in those sections of
>those drafts?
>
>-- Section 3.3 Layer 2 extension
>
>This text is hard to parse:
>
>   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.
>
>I'm missing the point here - two NVEs and an overlay-based encapsulation
>should solve this.  At a, "must become" and "presently" are wrong as the
>interconnect may exist prior to the move.  Also, I think this text
>assumes an external NVE (i.e., not in the server), see above.
>
>There seems to be significant overlap with section 3.4 of the problem
>statement draft, and I'm not clear on what this draft is adding.
>
>-- Section 3.4 Optimal IP Routing
>
>This has massive overlap with Section 3.7 of the problem statement draft.
>I'm not sure what the text in this draft adds beyond what's already in
>the problem statement.
>
>-- Section 3.5 Preserving Policies
>
>This appears to be covered (albeit in less detail) in Section 3.3 of
>the framework draft.
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Distinguished Engineer
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>
>
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3