Then I think we're in semi-violent agreement, as I strongly concur that those
softswitches are important NVE locations.  This is captured in the narten
problem statement draft, but if you have specific text changes to suggest,
please do.

Great.

I do want to see protocol interfaces on both sides of these softswitch NVEs -
VM-facing for attach/detach, etc. and "oracle"-facing for address mapping
lookup.  Designing these as protocol interfaces results in the same structure
of functional interactions when the NVE is offboard on a ToR switch or the like.

I am not sure we need to spend much time on the NVE to VM protocol interface. I think the orchestration either directly or via hypervisor control should be sufficient for VM instantiation as well as you mentioned attach/detach messaging.

NVE-2-oracle and oracle-2-rest_of_the_network I highly agree. But I am not sure if one size will fit all there.

R.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Robert
Raszuk
Sent: Tuesday, June 26, 2012 3:48 PM
To: Black, David
Cc: [email protected]
Subject: Re: [nvo3] Softswitches

Hi David,

Honestly I think we are getting more into implementation then
standardization debate.

What I call a softswitch can be either part of the linux kernel entirely
as a loadable module, can be partially in the kernel and partially in
the user space or if you follow NETMAP's direct memory mapping from
interface to user space could sit completely there.

Examples of softswitches which I am experimenting with is as you said
one from VMWare, the other most popular is OVS, there is LINK released
recently and there is at least few more in the works which would be
partially sitting in the end-system kernel or the kernel and user space.

At least this is what I meant by using the term "embedded".

The main point I think is that the L2/L3 virtualization/separation will
be happening in all of the above cases which share one very important
common characteristic - thay are all residing on the end host.

Best regards,
R.


_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to