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
