Although a common messaging layer is useful, the messaging protocol is just a means of transporting application specific data between the AUTHORITY and the NVE. There might be some room to define "objects" (say a common schema for encapsulation with sub schema for a each specific encapsulation -- ex: label stacking in MPLS) but it must be the application that should define the overall schema/contents of the messages that are exchanged for it's purpose. Let's be careful not to call or treat the messaging part an "application".
Additionally there are plenty of things that are available with BGP that would need to be available as part of the "common capabilities" of a common control-plane message layer including capabilities such as graceful restart (purge or keep state if CP session is lost and for how long), keep-alive/BFD, etc. I hope folks on this list are careful not to disregard (or even worse, to not know) what many years of control-plane engineering have produced in the IETF. Best regards -- aldrin On Tuesday, September 25, 2012, Sunny Rajagopalan wrote: > 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]> >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
