I would leave BGP as-is and use a simple RPC schema or Instant Messaging Protocol for switch forwarding state.
Maria > -----Original Message----- > From: AshwoodsmithPeter [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 1:44 PM > To: NAPIERALA, MARIA H; Stiliadis, Dimitrios (Dimitri); Aldrin Isaac > Cc: Thomas Nadeau; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > 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
