Hi Dimitrios, Just to be clear, I'm not proposing that every implementation of say, RFC 4364, replace BGP with XMPP (or other thing). BGP will continue to work great for many hardware-based NVE and even for implementations of software-based NVE. BGP-based NVE can co-exist with XMPP-based (as an example) NVE that implement E-VPN (as an example). The "backbone" of the E-VPN control plane will remain BGP since things like route distribution at scale, federating AS, etc come for free. In the end if all we end up doing with MESSAGING is what BGP is already used for, then BGP should be the common messaging layer.
It is important for proponents of a common messaging layer to develop a very good argument for it and provide clear evidence of it's value (versus philosophical) and also discuss what may (or may not) be wrong with more than one messaging protocols to co-exist on an NVE for different roles (app-specific, counters, etc). I can see the possible value in the paradigm, but I personally need convincing proof not rants. I also agree that if we're talking about a common messaging layer, we need to discuss what properties a common messaging layer would require. In the case of a basic software NVE (VM host) it's possible that it may not require support for millions of routes if only the ones that are needed for it are produced for it by the application, however NVE on gateways (which may also be software-based in some shops) may require handling of "millions of routes" and this might not be a good place for XMPP and the like. The most important point I'm trying to make, however, is that we can agree on the idea of an APPLICATION such that the WG can discuss a framework in the context of APPLICATIONS, and move forward to standardize a useful and distinct set of these for the purpose of NVO. Best regards -- aldrin On Wed, Sep 26, 2012 at 12:59 AM, Stiliadis, Dimitrios (Dimitri) <[email protected]> wrote: > Aldrin: > > +1 on this and thanks for stating this so clearly. > > On 9/25/12 11:15 AM, "Aldrin Isaac" <[email protected]> wrote: > >>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). > > Exactly. This is the only thing needed. I should note though the > difference between verbose XML based communication (XMPP for example) > and more compact data transfer mechanisms that can match programming > structures (see binary). When we are talking about millions > of VMs and routes and fast communication for route update with minimum > overheads, I am not sure that the overheads of XML outweigh the benefits. > Also, it looks to me that NVE->MESSAGE->AUTHORITY > is more of a point to point communication rather than a pub/sub interface. > > We can also start the JSON vs XML war in this context though, and I am sure > lots of people will have lots of opinions ;) > > Dimitri > >>> >>> 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 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
