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 protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
