I see the following in the draft "We say that an L2 site contains a given VM (or that a given VM is in a given L2 site), if the server presently hosting this VM is connected to a ToR that is part of that site."
and it seems to be at odds with "L2 site" being a virtual link in the hypervisor. Or maybe it is just my ability to understand :-) Somesh > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Linda Dunbar > Sent: Friday, August 24, 2012 2:11 PM > To: Black, David; [email protected] > Subject: Re: [nvo3] Comments on Live Migration and VLAN-IDs > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
