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

>> Several of the proposal use mechanisms that are equally applicable.  

The question is - are hypervisor and network based encap-decap control
planes identical in all respects? The question is not if some mechanisms
can be common. The question is - can all the mechanisms be common?

As a point of note, the draft you mention doesn't address multicast and
broadcast. It defines a database to lookup unicast addresses through a
new protocol. That mechanism won't work for multicast and broadcast. 

Thanks, Ashish

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
Sent: Friday, January 20, 2012 11:35 AM
To: Ashish Dalela (adalela)
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt

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@joelhalpern.com]
> Sent: Friday, January 20, 2012 10:58 AM
> To: Ashish Dalela (adalela)
> Cc: dc@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@gmail.com]
>> Sent: Friday, January 20, 2012 10:06 AM
>> To: Ashish Dalela (adalela)
>> Cc: dc@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@ietf.org
>> https://www.ietf.org/mailman/listinfo/dc
>>
>