Sunny, Your conclusion is correct. Please provide us with your proposed text. Yakov has told me that we need to include a section describing the implications of the CE/PE being co-located in a single box and this text could be included in it.
Yours irrespectively, John From: [email protected] [mailto:[email protected]] On Behalf Of Sunny Rajagopalan Sent: Monday, September 24, 2012 10:22 AM To: NAPIERALA, MARIA H Cc: Thomas Nadeau; Yakov Rekhter; [email protected]; Aldrin Isaac; Thomas Nadeau; Stiliadis, Dimitrios (Dimitri); [email protected] Subject: [nvo3] BGP + XMPP (was Re: draft-drake-nvo3-evpn-control-plane) I strongly agree with this. XMPP is a query format, not a routing protocol, and is better suited for hypervisor implementations. NVE implementations in hypervisors will find supporting xmpp easy - its just a query format for them, without substantial compute or memory requirements. I prefer the approach in draft-marques-l3vpn-end-system, where NVEs talk to route servers using XMPP, and the router servers act as BGP route reflectors and are tasked with peering with other BGP instances. This approach has a couple of advantages: 1) It reduces the memory and compute requirements of hypervisor NVEs. 2) It makes it easier to replace NVE<->XMPP<->BGP with NVE<->XMPP<->Directory, if needed for certain implementations. Note that BGP goes away only on the NVE; the rest of the network could still possibly run BGP to exchange end point information. The way I read it, draft-drake-nvo3-evpn-control-plane will still work fine if you do NVE<->XMPP<->BGP[EVPN]. However, I would like to see this called out in the draft. -- Sunny From: "NAPIERALA, MARIA H" <[email protected]<mailto:[email protected]>> To: Thomas Nadeau <[email protected]<mailto:[email protected]>>, Yakov Rekhter <[email protected]<mailto:[email protected]>>, Cc: Thomas Nadeau <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Stiliadis, Dimitrios \(Dimitri\)" <[email protected]<mailto:[email protected]>>, Aldrin Isaac <[email protected]<mailto:[email protected]>> Date: 09/24/2012 06:42 AM Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane Sent by: [email protected]<mailto:[email protected]> ________________________________ Tom, decoupling PE control plane from the forwarding function has many advantages but mainly it substantially increases operational scale - PE/control element is able to control multiple (1000+) compute nodes spread across different servers and other devices. The software complexity (e.g., managing policy functions, gathering of operational information like stats, events, diagnostics, etc.) is implemented in the control plane elements only. These reduce overall cost of a data center deployment. In addition, having an open protocol between a control plane and a forwarding plane of a PE allows sending local forwarding rules to forwarding device(s). XMPP is an open standard, light-weight, extendable (can carry various data objects), and flexible protocol known to application environment. Maria > -----Original Message----- > From: Thomas Nadeau [mailto:[email protected]] > Sent: Thursday, September 20, 2012 7:23 PM > To: NAPIERALA, MARIA H; Yakov Rekhter > Cc: [email protected]<mailto:[email protected]>; Stiliadis, Dimitrios (Dimitri); > Aldrin Isaac; Thomas > Nadeau > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > Maria, > > The only issue that is being raised seems to be one of which > control > plane to run, not whether or not we need one. I think everyone agrees > on > that. In the way of BGP versus XMPP, perhaps you could elaborate why > you > think BGP is a bad choice? > > --Tom > > > On 9/20/12 8:41 AM, "NAPIERALA, MARIA H" > <[email protected]<mailto:[email protected]>> wrote: > > >> > >> Do you think that an NVE that implements only XMPP has no control > plane > >> at all ? > > > >It does not implement the (BGP) control plane of the overlay (e.g., > route > >selection should be done on a controller and not on the NVE), and it > >should not directly participate in any other routing protocols. > > > >Maria > >_______________________________________________ > >nvo3 mailing list > >[email protected]<mailto:[email protected]> > >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
