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

[<[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
> Sent: Friday, January 20, 2012 10:58 AM
> To: Ashish Dalela (adalela)
> Cc: [e-mail]
> 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:[e-mail]]
>> Sent: Friday, January 20, 2012 10:06 AM
>> To: Ashish Dalela (adalela)
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dc
>>
>
_______________________________________________
dc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dc