> It is not clear to me why an L2-CUG would be tied to a VLAN-ID > in an nvo3 network?
Uhm, it's not, but the draft could be much clearer on this topic. IMHO, the draft uses the term "L2 site" in a rather non-intuitive fashion for nvo3. Here's the definition from Section 2 of the draft: In this document the term "L2 site" refers to a collection of interconnected devices that perform forwarding based on the information carried in the Ethernet header. In a non-trivial L2 site (site that contains multiple forwarding entities) forwarding could be provided by such layer 2 technologies as Spanning Tree Protocol (STP), etc... Note that any multi-chassis LAG is treated as a single L2 site - a given multi-chassis LAG has to be contained within a single L2 site. This document assumes that a layer 2 access domain is an L2 site. It's easy to mis-read that definition and infer than an "L2 site" is a data center, but that's not what's going on. For example, consider the scenario in which the NVEs are located in the hypervisors (and possibly also the DCBRs) - the "L2 site" adjacent to a VM then consists of one or more virtual links in the hypervisor, and none of the physical network components in the data center are part of any "L2 site" (as that term is defined in the text quoted above). Among the interesting consequences for this scenario is that the following requirement (from Section 3.1 of the draft) is far less restrictive than it may initially appear: This document assumes that VMs that belong to the same L2-based CUG, and are in the same L2 site MUST use the same VLAN-ID. If every "L2 site" is a single virtual link within a hypervisor, that requirement is rather easy to meet, especially for virtual links that aren't VLAN-tagged ;-). When the NVEs are in the ToR switches, the "L2 site" may be as small as a single Ethernet link between the physical server and the ToR switch. There's a much longer discussion of this scenario in Section 4.1 of draft-dunbar-nvo3-overlay-mobility-issues-00.txt . In any case, I suggest using a word other than "site" in "L2 site" for clarity. Following up on Ivan's comment about tagged vs. untagged network interfaces in VMs, the first paragraph in Section 3.1 of this draft has an unfortunate mixture of VLAN-IDs assigned by the network/hypervisor with VLAN-IDs used by VMs. While both are VLAN-IDs, their management is sufficiently different that they should be discussed separately. In particular, I suggest splitting the last sentence of that paragraph out into a separate paragraph on VLAN-tagged traffic to/from tagged network interfaces in VMs and providing a longer discussion somewhere earlier that contrasts hypervisor assignment of VLAN-IDs for traffic to/from untagged VM network interfaces with VLAN-ID usage by tagged VM network interfaces. Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Somesh > Gupta > Sent: Wednesday, August 22, 2012 7:07 AM > To: 'Yakov Rekhter'; [email protected] > Subject: Re: [nvo3] Comments on Live Migration and VLAN-IDs > > Hopefully this is not a repeat of something hashed out earlier. > > It is not clear to me why an L2-CUG would be tied to a VLAN-ID > in an nvo3 network? > > Is this document discussing the problem as is today without > the changes nvo3 would bring? If that is the case, fine. > > Thanks > Somesh > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
