Open Stack

On Mon, Dec 1, 2014 at 4:46 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
> On 1 December 2014 at 04:43, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:
>>
>> This is not entirely true, as soon as a reference implementation,
>> based on existing Neutron components (L2agent/L3agent...) can exist.
>
>
> The specific thing I was saying is that that's harder with an edge-id
> mechanism than one incorporated into Neutron, because the point of the
> edge-id proposal is to make tunnelling explicitly *not* a responsibility of
> Neutron.  So how do you get the agents to terminate tunnels when Neutron
> doesn't know anything about tunnels and the agents are a part of Neutron?

by having modular agents that can drive the dataplane with pluggable
components that would be part of any advanced service. This is a way
to move forward on splitting out advanced services.

> Conversely, you can add a mechanism to the OVS subsystem so that you can tap
> an L2 bridge into a network, which would probably be more straightforward.

This is an alternative that would say : you want an advanced service
for your VM, please stretch your l2 network to this external
component, that is driven by an external controller, and make your
traffic goes to this component to take benefit of this advanced
service. This is a valid alternative of course, but distributing the
service directly to each compute node is much more valuable, ASA it is
doable.

>> But even if it were true, this could at least give a standardized API
>> to Operators that want to connect their Neutron networks to external
>> VPNs, without coupling their cloud solution with whatever SDN
>> controller. And to me, this is the main issue that we want to solve by
>> proposing some neutron specs.
>
>
> So the issue I worry about here is that if we start down the path of adding
> the MPLS datamodels to Neutron we have to add Kevin's switch control work.
> And the L2VPN descriptions for GRE, L2TPv3, VxLAN, and EVPN.  And whatever
> else comes along.  And we get back to 'that's a lot of big changes that
> aren't interesting to 90% of Neutron users' - difficult to get in and a lot
> of overhead to maintain for the majority of Neutron developers who don't
> want or need it.

This shouldn't be a lot of big changes, once interfaces between
advanced services and neutron core services will be cleaner. The
description of the interconnection has to to be done somewhere, and
neutron and its advanced services are a good candidate for that.

> --
> Ian.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>