Hi, we really like the idea to address the SFC use-case in Neutron working group. We would be happy to work with the community to work out the way to consume service-chains via standardized neutron-api and provide use-cases and blueprints. Some initial ideas on the use-case can be found in the following etherpad [1].
Keshava, we think that it would be ideal to have two type of use-cases: one which you described below (“dynamic” one) with the usage of IETF-defined header but also one “static” one where the whole chain can be pre-provisioned by the orchestrator via Neutron-API w/o usage of classifier and header extensions. [1] https://etherpad.openstack.org/p/kKIqu2ipN6 Kind regards/Mit freundlichen Grüßen Yuriy Babenko Von: A, Keshava [mailto:keshav...@hp.com] Gesendet: Donnerstag, 8. Januar 2015 07:19 An: mest...@mestery.com; OpenStack Development Mailing List (not for usage questions) Betreff: Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining! Yes, I agree with Kyle decision. First we should define what is Service. Service is within OpenStack infrastructure ? or Service belongs to NFV vNF/Service-VM ? Based on that its Chaining needs to be defined. If it is chaining of vNFs(which are service/set of services) then it will be based on ietf ‘service header insertion’ at the ingress. This header will have all the set services that needs to be executed across vNFV, will be carried in each of the Tennant packet. So it requires coordinated effort along with NFV/Telco working groups. keshava From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, January 07, 2015 8:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining! On Wed, Jan 7, 2015 at 6:25 AM, <lv.erc...@zte.com.cn<mailto:lv.erc...@zte.com.cn>> wrote: Hi, I want to confirm that how is the project about "Neutron Services Insertion, Chaining, and Steering" going, I found that all the code implementation about service insertion、service chaining and traffic steering list in JunoPlan were Abandoned . https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan and I also found that we have a new project about GBP and group-based-policy-service-chaining be located at: https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-abstraction https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining so I'm confused with solution of the service chaining. We are developing the service chaining feature, so we need to know which one is the neutron's choice. Are the blueprints about the service insertion, service chaining and traffic steering list in JunoPlan all Abandoned ? Service chaining isn't in the plan for Kilo [1], but I expect it to be something we talk about in Vancouver for the Lxxx release. The NFV/Telco group has been talking about this as well. I'm hopeful we can combine efforts and come up with a coherent service chaining solution that solves a handful of useful use cases during Lxxx. Thanks, Kyle [1] http://specs.openstack.org/openstack/neutron-specs/priorities/kilo-priorities.html BR Alan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> 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
