One reason for trying to get an more complete API into Neutron is to have a 
standardized API. So users know what to expect and for providers to have 
something to comply to. Do you suggest we bring this standardization work to 
some other forum, OPNFV for example? Neutron provides low level hooks and the 
rest is defined elsewhere. Maybe this could work, but there would probably be 
other issues if the actual implementation is not on the edge or outside Neutron.

/Erik


From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: den 4 december 2014 20:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

On 1 December 2014 at 21:26, Mohammad Hanif 
<mha...@brocade.com<mailto:mha...@brocade.com>> wrote:
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?

Well, you have attachment types, tunnels, and so on - these are all objects 
with data models, and your spec is on Neutron so I'm assuming you plan on 
putting them into the Neutron database - where they are, for ever more, a 
Neutron maintenance overhead both on the dev side and also on the ops side, 
specifically at upgrade.

How else one introduces a network service in OpenStack if it is not through a 
service plugin?

Again, I've missed something here, so can you define 'service plugin' for me?  
How similar is it to a Neutron extension - which we agreed at the summit we 
should take pains to avoid, per Salvatore's session?
And the answer to that is to stop talking about plugins or trying to integrate 
this into the Neutron API or the Neutron DB, and make it an independent service 
with a small and well defined interaction with Neutron, which is what the 
edge-id proposal suggests.  If we do incorporate it into Neutron then there are 
probably 90% of Openstack users and developers who don't want or need it but 
care a great deal if it breaks the tests.  If it isn't in Neutron they simply 
don't install it.

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.

Agreed.  I'm suggesting it should be a separate service endpoint.
--
Ian.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to