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