Agree with David on the meaning of L2 site. If you read carefully the definition of "L2 site" in the draft (instead of various connotations of L2 site under other context), the definition is very precise and correct for the usage of this document.
Agree with David that "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 ;-)." But most, if not all, data centers today don't have the Hypervisors which can encapsulate the NVo3 defined header. The deployment to all 100% NVo3 header based servers won't happen overnight. One thing for sure that you will see data centers with mixed types of servers for very long time. If NVEs are in the ToR, you will see mixed scenario of blade servers, servers with simple virtual switches, or even IEEE802.1Qbg's VEPA. So it is necessary for NVo3 to deal with the "L2 Site" defined in this draft. Linda Dunbar > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Black, David > Sent: Wednesday, August 22, 2012 2:20 PM > To: [email protected] > Subject: Re: [nvo3] Comments on Live Migration and VLAN-IDs > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
