Resending last email without nvo3-bounces in the recipient list....
On Tue, Sep 25, 2012 at 11:53 AM, Aldrin Isaac <[email protected]> wrote: > Hi Sunny, > > Although I don't see any reason why BGP cannot be implemented on an > NVE (hypervisor, ToR, etc), I'm beginning to see why something other > than BGP might be an appropriate choice for transporting > network-control data to/from the NVE. The idea of > NVE<->MESSAGING<->AUTHORITY where MESSAGING is standardized and > AUTHORITY can take different forms might indeed be a useful > decoupling. It would probably be appropriate to spend a few cycles to > determine if XMPP is the best choice among available messaging options > (ex: AMQP). > > Once we get past the choice of a common messaging transport, IMHO we > need to be talking a lot more (more sooner than later) about the > network as a set of one or more distributed applications (might be > centralized under one NVO3 domain, but distributed across multiple). > For a distributed application, the AUTHORITY is essentially the sum of > the application instances in that NVO3 domain. This point is being > raised by others but doesn't seem to have "clicked". In this view of > things, E-VPN, RFC 4364, etc would be considered "applications". The > operator can choose one or more of these. The difference between this > notion and what is proposed by others (SDN, openflow, etc) is that the > IETF standardizes applications as well in addition to data-plane > formats, etc. This ensures that operators will have choice to select > a particular implementation of an application (versus a proprietary > application). > > Taking this a little further using E-VPN as an example -- generally > E-VPN is thought of as being an application that is implemented in a > distributed manner at NVE/PE, however there is no rule that says it > can't be implemented in a centralized or hybrid (ex: semi-distributed) > manner (as Maria points out). For example, an E-VPN application > running on a centralized server can implement all the procedures > specified in draft-ietf-l2vpn-evpn on behalf of NVE and either > distribute the resulting forwarding rules to NVE (ex: using openflow > over XMPP, etc) or make the results available for on-demand lookup > (directory mode) by slightly more intelligent NVE. The rules of how > to construct E-VPN L2 VN, however, should remain the same regardless > of whether it's implemented in a distributed, centralized or hybrid > fashion. In this model, it makes more sense to define a provisioning > schema per application (versus a generic all-encompassing schema) -- > in E-VPN the provisioning schema would outline import/export RT and > the schema would need to be defined as part of the specification of > the application (as well as schema for other application specific > data). > > At a data-plane level, NVE that support the E-VPN application should > support certain data-plane constructs as specified in > draft-ietf-l2vpn-evpn such that it is possible for E-VPN instances on > NVE under other AUTHORITY to send frames directly to it (ex: to > maximize network utilization) or otherwise the local AUTHORITY might > direct other AUTHORITY toward interconnecting gateways. Likewise for > other applications. > > Best regards -- aldrin > > > P.S. I'm using AUTHORITY here as I am still struggling with the term > ORACLE. > > > > On Mon, Sep 24, 2012 at 1:22 PM, Sunny Rajagopalan > <[email protected]> wrote: >> 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]> >> To: Thomas Nadeau <[email protected]>, Yakov Rekhter >> <[email protected]>, >> Cc: Thomas Nadeau <[email protected]>, "[email protected]" >> <[email protected]>, "Stiliadis, Dimitrios \(Dimitri\)" >> <[email protected]>, Aldrin Isaac >> <[email protected]> >> Date: 09/24/2012 06:42 AM >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> Sent by: [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]; 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]> 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] >>> >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
