Somesh, You are correct that this description does imply that TOR has physical links to the server which host the VMs.
We will find out a way to change the wording to include the Virtual links case. Thanks, Linda > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Somesh Gupta > Sent: Friday, August 24, 2012 4:28 PM > To: [email protected] > Subject: Re: [nvo3] Comments on Live Migration and VLAN-IDs > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
