On Sep 25, 2012:10:51 PM, at 10:51 PM, Aldrin Isaac <[email protected]>
wrote:
> 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
And also to that end, we should note that we are working on such a
"minimum capabilities" appendix section in the next revision of the draft.
--Tom
>
>
>
> 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
