Hi, Aldrin I agree & share your thoughts below. I picked XMPP just because it seems to be the one most talked about here, any messaging format that is open will do.
Note that something similar happens today in PE routers - the control plane is usually running on a separate CPU from the forwarding plane, but the messaging between the two is proprietary. Making the messaging format open allows for the control plane to be implemented in different ways depending on the scenario. This is important because in some networks it might make sense to have a directory-based name resolution, and BGP based end location distribution would make sense in others. As you pointed out, these two could even co-exist, (for example if you run one application over the short haul and another over the long haul). In such a hybrid application scenario, the directory could talk to both, local NVEs and the BGP route reflectors using XMPP, with the directory being the entity that uploads endpoint information into the BGP route reflector. To take this one step further, if you define the messaging [XMPP] format generically, you should be able to use the encapsulation method of your choice (MPLS, NVGRE, VXLAN) as well. This gives us a system with a completely decoupled control and forwarding plane. -- Sunny From: Aldrin Isaac <[email protected]> To: Sunny Rajagopalan/Santa Clara/IBM@IBMUS, Cc: "NAPIERALA, MARIA H" <[email protected]>, Thomas Nadeau <[email protected]>, Yakov Rekhter <[email protected]>, "[email protected]" <[email protected]>, Thomas Nadeau <[email protected]>, "Stiliadis, Dimitrios (Dimitri)" <[email protected]>, [email protected] Date: 09/25/2012 08:54 AM Subject: Re: [nvo3] BGP + XMPP (was Re: draft-drake-nvo3-evpn-control-plane) 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
