I have seen emails suggesting that adding protocols to hypervisor implementations is considered to be business as usual.
Yours irrespectively, John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Balus, Florin Stelian (Florin) > Sent: Wednesday, September 19, 2012 11:33 AM > To: AshwoodsmithPeter > Cc: Thomas Nadeau; Aldrin Isaac; Stiliadis, Dimitrios (Dimitri); > NAPIERALA, MARIA H; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > 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- > plan > >>>>> e > >>>>> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
