I hope we all understand how edge VPN works and what interactions are 
introduced as part of this spec.  I see references to neutron-network mapping 
to the tunnel which is not at all case and the edge-VPN spec doesn’t propose 
it.  At a very high level, there are two main concepts:

  1.  Creation of a per tenant VPN “service” on a PE (physical router) which 
has a connectivity to other PEs using some tunnel (not known to tenant or 
tenant-facing).  An attachment circuit for this VPN service is also created 
which carries a “list" of tenant networks (the list is initially empty) .
  2.  Tenant “updates” the list of tenant networks in the attachment circuit 
which essentially allows the VPN “service” to add or remove the network from 
being part of that VPN.

A service plugin implements what is described in (1) and provides an API which 
is called by what is described in (2).  The Neutron driver only “updates” the 
attachment circuit using an API (attachment circuit is also part of the service 
plugin’ data model).   I don’t see where we are introducing large data model 
changes to Neutron?  How else one introduces a network service in OpenStack if 
it is not through a service plugin?  As we can see, tenant needs to communicate 
(explicit or otherwise) to add/remove its networks to/from the VPN.  There has 
to be a channel and the APIs to achieve this.


From: Ian Wells <ijw.ubu...@cack.org.uk<mailto:ijw.ubu...@cack.org.uk>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Monday, December 1, 2014 at 4:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
Subject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

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

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.
OpenStack-dev mailing list

Reply via email to