Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-05 Thread Erik Moe

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


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-05 Thread Ian Wells
I have no problem with standardising the API, and I would suggest that a
service that provided nothing but endpoints could be begun as the next
phase of 'advanced services' broken out projects to standardise that API.
I just don't want it in Neutron itself.

On 5 December 2014 at 00:33, Erik Moe erik@ericsson.com wrote:



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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-04 Thread Ian Wells
On 1 December 2014 at 21:26, Mohammad Hanif 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


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-01 Thread Mathieu Rohon
Hi,


On Sun, Nov 30, 2014 at 8:35 AM, Ian Wells ijw.ubu...@cack.org.uk wrote:
 On 27 November 2014 at 12:11, Mohammad Hanif mha...@brocade.com wrote:

 Folks,

 Recently, as part of the L2 gateway thread, there was some discussion on
 BGP/MPLS/Edge VPN and how to bridge any overlay networks to the neutron
 network.  Just to update everyone in the community, Ian and I have
 separately submitted specs which make an attempt to address the cloud edge
 connectivity.  Below are the links describing it:

 Edge-Id: https://review.openstack.org/#/c/136555/
 Edge-VPN: https://review.openstack.org/#/c/136929 .  This is a resubmit of
 https://review.openstack.org/#/c/101043/ for the kilo release under the
 “Edge VPN” title.  “Inter-datacenter connectivity orchestration” was just
 too long and just too generic of a title to continue discussing about :-(


 Per the summit discussions, the difference is one of approach.

 The Edge-VPN case addresses MPLS attachments via a set of APIs to be added
 to the core of Neutron.  Those APIs are all new objects and don't really
 change the existing API so much as extend it.  There's talk of making it a
 'service plugin' but if it were me I would simply argue for a new service
 endpoint.  Keystone's good at service discovery, endpoints are pretty easy
 to create and I don't see why you need to fold it in.

 The edge-id case says 'Neutron doesn't really care about what happens
 outside of the cloud at this point in time, there are loads of different
 edge termination types, and so the best solution would be one where the
 description of the actual edge datamodel does not make its way into core
 Neutron'.  This avoids us folding in the information about edges in the same
 way that we folded in the information about services and later regretted it.
 The notable downside is that this method would work with an external network
 controller such as ODL, but probably will never make its way into the
 inbuilt OVS/ML2 network controller if it's implemented as described
 (explicitly *because* it's designed in such a way as to keep the
 functionality out of core Neutron).  Basically, it's not completely
 incompatible with the datamodel that the Edge-VPN change describes, but
 pushes that datamodel out to an independent service which would have its own
 service endpoint to avoid complicating the Neutron API with information
 that, likely, Neutron itself could probably only ever validate, store and
 pass on to an external controller.

This is not entirely true, as soon as a reference implementation,
based on existing Neutron components (L2agent/L3agent...) can exist.
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.

 Also, the Edge-VPN case is specified for only MPLS VPNs, and doesn't
 consider other edge cases such as Kevin's switch-based edges in
 https://review.openstack.org/#/c/87825/ .  The edge-ID one is agnostic of
 termination types (since it absolves Neutron of all of that responsibility)
 and would leave the edge type description to the determination of an
 external service.

 Obviously, I'm biased, having written the competing spec; but I prefer the
 simple change that pushes complexity out of the core to the larger but
 comprehensive change that keeps it as a part of Neutron.  And in fact if you
 look at the two specs with that in mind, they do go together; the Edge-VPN
 model is almost precisely what you need to describe an endpoint that you
 could then associate with an Edge-ID to attach it to Neutron.
 --
 Ian.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-01 Thread Ian Wells
On 1 December 2014 at 04:43, Mathieu Rohon mathieu.ro...@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?
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.

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.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-01 Thread Mathieu Rohon
On Mon, Dec 1, 2014 at 4:46 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:
 On 1 December 2014 at 04:43, Mathieu Rohon mathieu.ro...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-12-01 Thread Mohammad Hanif
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.

Thanks,
—Hanif.

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

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

Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

2014-11-29 Thread Ian Wells
On 27 November 2014 at 12:11, Mohammad Hanif mha...@brocade.com wrote:

  Folks,

  Recently, as part of the L2 gateway thread, there was some discussion on
 BGP/MPLS/Edge VPN and how to bridge any overlay networks to the neutron
 network.  Just to update everyone in the community, Ian and I have
 separately submitted specs which make an attempt to address the cloud edge
 connectivity.  Below are the links describing it:

  Edge-Id: https://review.openstack.org/#/c/136555/
 Edge-VPN: https://review.openstack.org/#/c/136929 .  This is a resubmit
 of https://review.openstack.org/#/c/101043/ for the kilo release under
 the “Edge VPN” title.  “Inter-datacenter connectivity orchestration” was
 just too long and just too generic of a title to continue discussing about
 :-(


Per the summit discussions, the difference is one of approach.

The Edge-VPN case addresses MPLS attachments via a set of APIs to be added
to the core of Neutron.  Those APIs are all new objects and don't really
change the existing API so much as extend it.  There's talk of making it a
'service plugin' but if it were me I would simply argue for a new service
endpoint.  Keystone's good at service discovery, endpoints are pretty easy
to create and I don't see why you need to fold it in.

The edge-id case says 'Neutron doesn't really care about what happens
outside of the cloud at this point in time, there are loads of different
edge termination types, and so the best solution would be one where the
description of the actual edge datamodel does not make its way into core
Neutron'.  This avoids us folding in the information about edges in the
same way that we folded in the information about services and later
regretted it.  The notable downside is that this method would work with an
external network controller such as ODL, but probably will never make its
way into the inbuilt OVS/ML2 network controller if it's implemented as
described (explicitly *because* it's designed in such a way as to keep the
functionality out of core Neutron).  Basically, it's not completely
incompatible with the datamodel that the Edge-VPN change describes, but
pushes that datamodel out to an independent service which would have its
own service endpoint to avoid complicating the Neutron API with information
that, likely, Neutron itself could probably only ever validate, store and
pass on to an external controller.

Also, the Edge-VPN case is specified for only MPLS VPNs, and doesn't
consider other edge cases such as Kevin's switch-based edges in
https://review.openstack.org/#/c/87825/ .  The edge-ID one is agnostic of
termination types (since it absolves Neutron of all of that responsibility)
and would leave the edge type description to the determination of an
external service.

Obviously, I'm biased, having written the competing spec; but I prefer the
simple change that pushes complexity out of the core to the larger but
comprehensive change that keeps it as a part of Neutron.  And in fact if
you look at the two specs with that in mind, they do go together; the
Edge-VPN model is almost precisely what you need to describe an endpoint
that you could then associate with an Edge-ID to attach it to Neutron.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev