Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
Hi Keshava, Please find my response iniline. Thanks Vikram On Tue, May 19, 2015 at 10:10 PM, A, Keshava keshav...@hp.com wrote: Hi Vikarm 1. What are the use case of “ Dynamic Routing Framework” ? https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing You are thinking of running both IGP and BGP in the same neutron ? Vikram: I didn't get you question. Can you please elaborate. In which kind of scenario we need this ? It is better have more information. We also need to think do we really need IGP with in the cloud, or we only need BGP for external connectivity . In that scenario, we may not go for Routing Framework, and not to complicate things too much. *If some things works well with L2 with in the cloud lets not touch those area. We may need to see where there are real problem.* Vikram Usecase is discussed in https://review.openstack.org/#/c/125401/; 2. What is the use case of “Prefix Clashing” ? You are thinking of running multiple routing protocol and they will learn “same prefix + Route” ? https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol In my opinion, with in the cloud we may not such deployment scenario. Vikram Usecase is discussed in https://review.openstack.org/#/c/180267/; *Let us not mix underlay network with overlay network . Both will go as different solution provider, so different business domain.* This is my thoughts . keshava *From:* Vikram Choudhary [mailto:vikram.choudh...@huawei.com] *Sent:* Wednesday, May 06, 2015 10:45 AM *To:* p...@michali.net; openstack-dev@lists.openstack.org *Cc:* Kalyankumar Asangi *Subject:* Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? Hi Paul, Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion. Please let me know about the IRC channels which we will be following for this discussion. Currently, I am following below BP’s for this work. https://blueprints.launchpad.net/neutron/+spec/edge-vpn https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram *From:* Paul Michali [mailto:p...@michali.net p...@michali.net] *Sent:* 06 May 2015 01:38 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ
Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
Hi Vikarm 1. What are the use case of “ Dynamic Routing Framework” ? https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing You are thinking of running both IGP and BGP in the same neutron ? In which kind of scenario we need this ? It is better have more information. We also need to think do we really need IGP with in the cloud, or we only need BGP for external connectivity . In that scenario, we may not go for Routing Framework, and not to complicate things too much. If some things works well with L2 with in the cloud lets not touch those area. We may need to see where there are real problem. 2. What is the use case of “Prefix Clashing” ? You are thinking of running multiple routing protocol and they will learn “same prefix + Route” ? https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol In my opinion, with in the cloud we may not such deployment scenario. Let us not mix underlay network with overlay network . Both will go as different solution provider, so different business domain. This is my thoughts . keshava From: Vikram Choudhary [mailto:vikram.choudh...@huawei.com] Sent: Wednesday, May 06, 2015 10:45 AM To: p...@michali.net; openstack-dev@lists.openstack.org Cc: Kalyankumar Asangi Subject: Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? Hi Paul, Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion. Please let me know about the IRC channels which we will be following for this discussion. Currently, I am following below BP’s for this work. https://blueprints.launchpad.net/neutron/+spec/edge-vpn https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram From: Paul Michali [mailto:p...@michali.net] Sent: 06 May 2015 01:38 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram *From:* Paul Michali [mailto:p...@michali.net] *Sent:* 06 May 2015 01:38 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Paul, can you elaborate on any DM VPN proposal, I can't find any spec/blueprint about it? Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Paul, can you elaborate on any DM VPN proposal, I can't find any spec/blueprint about it? Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
I think Paul is correctly scoping this discussion in terms of APIs and management layer. For instance, it is true that dynamic routing support, and BGP support might be a prerequisite for BGP VPNs, but it should be possible to have at least an idea of how user and admin APIs for this VPN use case should look like. In particular the discussion on service chaining is a bit out of scope here. I'd just note that [1] seems to have a lot of overlap with group-based-policies [2], and that it appears to be a service that consumes Neutron rather than an extension to it. The current VPN service was conceived to be fairly generic. IPSEC VPN is the only implemented one, but SSL VPN and BGP VPN were on the map as far as I recall. Personally having a lot of different VPN APIs is not ideal for users. As a user, I probably don't even care about configuring a VPN. What is important for me is to get L2 or L3 access to a network in the cloud; therefore I would seek for common abstractions that might allow a user for configuring a VPN service using the same APIs. Obviously then there will be parameters which will be specific for the particular class of VPN being created. I listened to several contributors in the area in the past, and there are plenty of opinions across a spectrum which goes from total abstraction (just expose edges at the API layer) to what could be tantamount to a RESTful configuration of a VPN appliance. I am not in a position such to prescribe what direction the community should take; so, for instance, if the people working on XXX VPN believe the best way forward for them is to start a new project, so be it. The other approach would obviously to build onto the current APIs. The only way the Neutron API layer provides to do that is to extend and extension. This sounds terrible, and it is indeed terrible. There is a proposal for moving toward versioned APIs [3], but until that proposal is approved and implemented extensions are the only thing we have. From an API perspective the mechanism would be simpler: 1 - declare the extension, and implement get_required_extension to put 'vpnaas' as a requirement 2 - implement a DB mixin for it providing basic CRUD operations 3 - add it to the VPN service plugin and add its alias to 'supported_extensions_aliases' (step 2 and 3 can be merged if you wish not to have a mixin) What might be a bit more challenging is defining how this reflects onto VPN. Ideally you would have a driver for every VPN type you support, and then have a little dispatcher to route the API call to the appropriate driver according to the VPN type. Salvatore [1] https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining [2] https://wiki.openstack.org/wiki/GroupBasedPolicy [3] https://review.openstack.org/#/c/136760 On 6 May 2015 at 07:14, Vikram Choudhary vikram.choudh...@huawei.com wrote: Hi Paul, Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion. Please let me know about the IRC channels which we will be following for this discussion. Currently, I am following below BP’s for this work. https://blueprints.launchpad.net/neutron/+spec/edge-vpn https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram *From:* Paul Michali [mailto:p...@michali.net] *Sent:* 06 May 2015 01:38 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help
Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
Hi Paul, Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion. Please let me know about the IRC channels which we will be following for this discussion. Currently, I am following below BP’s for this work. https://blueprints.launchpad.net/neutron/+spec/edge-vpn https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram From: Paul Michali [mailto:p...@michali.net] Sent: 06 May 2015 01:38 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] How should edge services APIs integrate into Neutron?
There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
