This may be feasible but is it what will get deployed in the hypervisor operational environment?
We need to consider the protocols that garnered acceptance in the cloud networking space as well before deciding on which solution to push down their throat. Florin On Sep 19, 2012, at 12:45 PM, "AshwoodsmithPeter" <[email protected]> wrote: > > Presumably its possible to strip down to the bare minimum BGP required in the > end hosts. Essentially one or a pair of TCP connections would be all that is > required. A lot of the BGP machinery is not required in the end hosts. > > Also just because its called BGP does not mean it is the same BGP instance > that is used for the underlay routing. So full decoupling is not lost because > the same protocol is used for both the underlay and the overlay. > > Peter > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > NAPIERALA, MARIA H > Sent: Wednesday, September 19, 2012 1:10 PM > To: Stiliadis, Dimitrios (Dimitri); Aldrin Isaac > Cc: Thomas Nadeau; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > >> >> Nothing against leveraging BGP. Doing BGP at end-hosts is clearly a >> problem. XMPP is an >> option, but not the only one. > > That's right. > Some providers are looking for a solution where network virtualization > forwarding and control functions are fully decoupled, and where only the > forwarding function (i.e., overlay encapsulation function) is implemented on, > e.g., the application servers. > > Maria > > >> Dimitri >> >> On 9/17/12 12:18 PM, "Aldrin Isaac" <[email protected]> wrote: >> >>> I'm not sure that the dust has fully settled on the matter. >>> http://tools.ietf.org/html/draft-marques-l3vpn-end-system-07 suggests >>> the use of XMPP. The question is whether there is any sound technical >>> reason (versus preferences) why leveraging BGP is problematic. I >>> personally haven't heard a convincing argument. >>> >>> On Mon, Sep 17, 2012 at 12:11 PM, Stiliadis, Dimitrios (Dimitri) >>> <[email protected]> wrote: >>>> May be I missing something here .. but does this suggest running >>>> BGP-EVPN >>>> on the NVE >>>> that is located in the hypervisor? >>>> >>>> Dimitri >>>> >>>> On 9/17/12 8:55 AM, "Thomas Nadeau" <[email protected]> wrote: >>>> >>>>> >>>>> A number of us just published this draft and wanted to bring >> it >>>>> to the >>>>> NVO3 WG's attention. We will be presenting/discussing this draft at >> the >>>>> interim meeting this week as well, but please discuss here on the >> list >>>>> as >>>>> well. >>>>> >>>>> Thanks, >>>>> >>>>> Tom, John, et al >>>>> >>>>> >>>>> A new version of I-D, draft-drake-nvo3-evpn-control-plane-00.txt >>>>> has been successfully submitted by Thomas D. Nadeau and posted to >> the >>>>> IETF repository. >>>>> >>>>> Filename: draft-drake-nvo3-evpn-control-plane >>>>> Revision: 00 >>>>> Title: A Control Plane for Network Virtualized Overlays >>>>> Creation date: 2012-09-16 >>>>> WG ID: Individual Submission >>>>> Number of pages: 12 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-drake-nvo3-evpn-control- >> plane- >>>>> 00 >>>>> .txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-drake-nvo3-evpn-control-plane >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-drake-nvo3-evpn-control-plane-00 >>>>> >>>>> >>>>> Abstract: >>>>> The purpose of this document is to describe how Ethernet >> Virtual >>>>> Private Network (E-VPN) can be used as the control plane for >>>>> Network Virtual Overlays. Currently this protocol is defined >> to >>>>> act as the control plane for Virtual Extensible Local Area >>>>> Network (VXLAN), Network Virtualization using Generic Routing >>>>> Encapsulation (NVGRE), MPLS or VLANs while maintaining their >>>>> existing data plane encapsulations. The intent is that this >>>>> protocol will be capable of extensions in the future to >> handle >>>>> additinal data plane encapsulations and functions as needed. >>>>> >>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
