> Actually I do not see that those two are need to be decoupled. Linux
> kernel with some additional enhancement module can act as NVE. Tenants
> are just connected to the NVE over normal bridge interfaces by the
> co-located hypervisor.
The salient question is not what's possible, but what's actually being
done ("running code"), as nvo3 can't succeed if it requires major
hypervisor rewrites.
Linux is not the system that supports hypervisors. The Cisco Nexus
1000V softswitches are examples where there is a strong decoupling
and that softswitch is available for at least two non-Linux hypervisors,
suggesting similar decoupling in the system architectures for those
hypervisors.
Thanks,
--David
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Robert
> Raszuk
> Sent: Tuesday, June 26, 2012 3:04 PM
> To: Black, David
> Cc: [email protected]; [email protected]
> Subject: Re: [nvo3] call for adoption: draft-narten-nvo3-overlay-problem-
> statement-02
>
> David,
>
> > Robert,
> >
> > We need to distinguish "hypervisor" as manager of the VM from the
> > embedded "softswitch" as a networking component. The l3vpn-end-systems
> > draft proposes XMPP for communication that would be between the hypervisor
> > (as or on behalf of the Tenant End System [TES]) and the NVE.
>
> Actually I do not see that those two are need to be decoupled. Linux
> kernel with some additional enhancement module can act as NVE. Tenants
> are just connected to the NVE over normal bridge interfaces by the
> co-located hypervisor.
>
> My reading of l3vpn-end-systems is that XMPP is used between the NVE and
> the "oracle" and NVE = to kernel module = analogy to softswitch (but the
> last is a bit too broad of a term these days).
>
> I am sure Pedro can authoritatively clarify that.
>
> > and I wonder whether one wants to be parsing XML to deal with every
> > event in such a storm.
>
> There is no storm I envision to happen. By proper filtering of required
> only information to be delivered by given host the filtering happens on
> the oracle instead. RT-Constrain seems perfect to address that task here.
>
> Rgs,
> R.
>
>
> > The mention
> > of OSPF in this thread has been for NVE access to address mapping
> information
> > from the "oracle", and this would be different from use of OSPF to route
> > traffic on the underlying network (using the outer IP addresses in an
> > nvo3 encapsulation).
> >
> > Please keep these use cases separate as they have rather different
> > characteristics and requirements. IEEE VDP is also a candidate protocol
> > for the NVE-TES communication. One thing that is of some concern to me
> > about XMPP is that there are attach/detach storms (e.g., call center VDI
> > startup when all the workers show up at the start of the shift), and I
> > wonder whether one wants to be parsing XML to deal with every event in
> > such a storm.
> >
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Robert Raszuk [mailto:[email protected]]
> >> Sent: Tuesday, June 26, 2012 2:45 PM
> >> To: Black, David
> >> Cc: [email protected]; [email protected]
> >> Subject: Re: [nvo3] call for adoption: draft-narten-nvo3-overlay-problem-
> >> statement-02
> >>
> >> Hi David,
> >>
> >> > My comment is that (IMHO, your O will likely be different), OSPF seems
> >>> to be a more reasonable candidate for hypervisor softswitch implementation
> >>> by comparison to BGP.
> >>
> >> IMHO neither of those is a good idea if we are talking about choice of
> >> vehicle to carry control plane propagation to hypervisor.
> >>
> >> I am of the opinion that XMPP as proposed in l3vpn-end-systems draft is
> >> a much better choice there.
> >>
> >>> If the "oracle" were based on a routing protocol or protocols for
> >> information
> >>> distribution with OSPF being in use closest to the NVEs, I could see an
> >> approach
> >>> where the NVEs directly participate in OSPF. OTOH, my preference would be
> >>> to put OSPF on network nodes and use some other protocol to do the address
> >>> mapping lookups from the NVEs to the network nodes, because this preserves
> >> OSPF's
> >>> current scaling properties/expectations wrt the scale of the physical
> >> network.
> >>> In contrast, OSPF in softswitches turns every server into an OSPF
> >> participant,
> >>> thereby changing OSPF's scaling properties wrt the physical network
> >> infrastructure
> >>> by at least an order of magnitude.
> >>
> >> My take is that while "oracle(s)" can participate in dynamic routing
> >> towards the core (data center and or wan) on the other side it would be
> >> much more convenient to ask them to speak the language which hosts are
> >> the most familiar with. Extensible xml schema seems at least as one
> >> possible candidate there. I am sure there could be more, but that a good
> >> start I think.
> >>
> >> Rgs,
> >> R.
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
