Open Stack

On 1 December 2014 at 09:01, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:
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.
>

Right, so a lot rides on the interpretation of 'advanced service' here, and
also 'attachment'.

Firstly, the difference between this and the 'advanced services' (including
the L3 functionality, though it's not generally considered an 'advanced
service') is that advanced services that exist today attach via an
addressed port.  This bridges in.  That's quite a signifcant difference,
which is to an extent why I've avoided lumping the two together and haven't
called this an advanced service itself, although it's clearly similar.

Secondly, 'attachment' has historically meant a connection to that port.
But in DVRs, it can be a multipoint connection to the network - manifested
on several hosts - all through the auspices of a single port.  In the
edge-id proposal you'll note that I've carefully avoided defining what an
attachment is, largely because I have a natural tendency to want to see the
interface at the API level before I worry about the backend, I admit.  Your
point about distributed services is well taken, and I think would be
addressed by one of these distributed attachment types.

> 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.


Well, incorporating a lot of models into Neutron *is*, clearly, quite a bit
of change, for starters.

The edge-id concept says 'the data models live outside neutron in a
separate system' and there, yes, absolutely, this proposes a clean model
for edge/Neutron separation in the way you're alluding to with advanced
services.  I think your primary complaint is that it doesn't define that
interface for an OVS driver based system.

The edge-vpn concept says 'the data models exists within neutron in an
integrated fashion' and, if you agree that separation is the way to go,
this seems to me to be exactly the wrong approach to be using.  It's the
way advanced services are working - for now - but that's because we believe
it would be hard to pull them out because the interfaces between service
and Neutron don't currently exist.  The argument for this seems to be 'we
should incorporate it so that we can pull it out at the same time as
advanced services' but it feels like that's making more work now so that we
can do even more work in the future.

For an entirely new thing that is in many respects not like a service I
would prefer not to integrate it in the first place, thus skipping over
that whole question of how to break it out in the future.  It's an open
question whether the work to make it play nicely with the existing ML2
model is worth the effort or not, because I didn't study that.  It's not
relevant to my needs, but if you're interested then we could talk about
what other specs would be required.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141201/67eb25a3/attachment.html>