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. 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
