Re: [dc] draft-khasnabish-vmmi-problems-00.txt

Hi Vishwas and all,
EVB like technologies currently only focus on the interaction between 
hypervisor and ToR. The network control plane may not locate only on ToR. 
What's more, the interaction is not happened between hypervisor and its 
connected ToR, but maybe between hypervisor and ToR in other site.

I agree, hypervisor and network based encapsulations are quite different. 
But we could consider the design that ToR has same control plane as 
hypervisor. Then communication between VM and physical server would have 
same control plane.

Regards
Lizhong

--------------------------------------------------------------------------------

From: <vishwas.ietf at gmail.com> 
To: "Joel M. Halpern" <jmh at joelhalpern.com>, "Ashish Dalela (adalela)" 
<adalela at cisco.com> 
Cc: dc at ietf.org 
Date: Thu, 19 Jan 2012 22:20:13 -0800 
In-reply-to: <4F19040B.7000901 at joelhalpern.com> 
List-id: IETF Data Center Mailing List <dc.ietf.org> 

--------------------------------------------------------------------------------
Hi Ashish,

If you look at technologies like EVB you will see the interaction between 
the hypervisor and the network control plane.

_Vishwas

-- Sent from my HP TouchPad

--------------------------------------------------------------------------------
On Jan 19, 2012 10:05 PM, Joel M. Halpern <jmh at joelhalpern.com> wrote: 
Several of the proposal use mechanisms that are equally applicable. For 
a general description of one class of such approaches, look at the dcop 
draft Warren Kumari and I wrote. I am sure that there are other classes 
as well. 

Yours, 
Joel 

On 1/20/2012 12:52 AM, Ashish Dalela (adalela) wrote: 
> Joel, 
> 
> Hypervisor control is in the hypervisor manager. Switch control is in 
> the network control plane. These are parallel silos, that don't 
> interact. 
> 
> Either the hypervisor manager defers control to the network control 
> plane, or the switches defer control to the manager. Or, some new third 
> entity emerges to control both, and both hypervisor and switch defer 
> control to that entity. 
> 
> We can't have separate control models and expect this to work in the 
> same way. 
> 
> Which of these (or other) models you think presents a reasonable 
> approach to reconcile hypervisor control and network control? 
> 
> Thanks, Ashish 
> 
> -----Original Message----- 
> From: Joel M. Halpern [mailto:jmh at joelhalpern.com] 
> Sent: Friday, January 20, 2012 10:58 AM 
> To: Ashish Dalela (adalela) 
> Cc: dc at ietf.org 
> Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt 
> 
> While one can construct strawman hypothesis in whcih there are reasons 
> to have different tunnel control protocols depepnding upon end-point 
> location, equally one can construct reasonably hypothesis in which the 
> same protocol mechanisms work whether the end-point is at the VM, the 
> Hypervisor, the ToR switch, or an aggregation switch. 
> 
> 
> Yours, 
> Joel 
> 
> On 1/20/2012 12:07 AM, Ashish Dalela (adalela) wrote: 
>> 
>> I would not arrive at the conclusion that hypervisor work should or 
>> should not be done in IETF. That's a separate question. VXLAN and 
> NVGRE 
>> are hypervisor based approaches. But, they don't have control planes 
>> (yet). My point is that finding a common map-encap scheme isn't that 
>> hard. The harder part is how to make the hypervisor and network based 
>> map-encap *control planes* work the same way. 
>> 
>> If they don't work the same way, then L2-in-L2, L2-in-L3, L3-in-L3 has 
> a 
>> network flavor and a hypervisor flavor. 
>> 
>> Thanks, Ashish 
>> 
>> 
>> -----Original Message----- 
>> From: Melinda Shore [mailto:melinda.shore at gmail.com] 
>> Sent: Friday, January 20, 2012 10:06 AM 
>> To: Ashish Dalela (adalela) 
>> Cc: dc at ietf.org 
>> Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt 
>> 
>> On 1/19/12 7:26 PM, Ashish Dalela (adalela) wrote: 
>>> Bandwidth needs, but they have the 
>>> same tunnel. How do I distinguish between them based on the tunnel? 
> In 
>>> fact, if the tenant isolation is in the hypervisor, then the 
>> underlying 
>>> network has no clue which tenant needs what policy. 
>> 
>> Well, that's not true. In the case of IPSec we've got SPIs, and 
>> there are similar demultiplexing mechanisms in other technologies. 
>> 
>> But frankly I think that if you're going to distinguish between 
>> tunnel endpoints in the hypervisor and tunnel endpoints in other 
>> sorts of network devices I think you're going to be somewhat 
>> hard-pressed to make the case for working on the former in 
>> the IETF. 
>> 
>> Melinda 
>> _______________________________________________ 
>> dc mailing list 
>> dc at ietf.org 
>> https://www.ietf.org/mailman/listinfo/dc 
>> 
> 
_______________________________________________ 
dc mailing list 
dc at ietf.org 
https://www.ietf.org/mailman/listinfo/dc 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.