Open Stack

Hi Yuriy Babenko,

Thanks for sharing information.

I also have similar personal thoughts with various options as mentioned below.
Ofcourse the ietf service chaning meathod have lot open question we needs to discuss further. This is percived by NFV working group also.
Please take a look of hybrid meathod (option-3) as mentioned below also.


[cid:image006.png at 01D0318C.BC1D1770]

Service-VM:-

a.     This Service-VM will be devleoped by the individuals or it will be part of the commnity.

b.    These Service-VM needs to support, multiple Services A,B,C with in a ServiceVM (vNF1) (because of performance & business scenario)
Then it is required to chain those Services statically, or dnamically  based on the Tennant
requirement.
Since these VMs are  developed by the individuals, chainnig these Services using Neutron controller will be challenging  ? How can openstack know which are the Services running in that VM ?


There are 3 method to solve this issues.

Meathod-1:  Static Meathod.
Meathod-2 : Dynamic meathod, by adding the Service-chian header.
Meathod-3:  Hybrid. Static + Dynamic meathod.


Meathod-1: Static Meathod.

Requirement:
Community should defind and develop the Standard Service-API-LIB (Like socket layer. Each Service-VM should attach this LIB.
Then using these Service API, Openstack controller (any) can program the Service’s inside the Service-VM according the service Chain.


[cid:image007.png at 01D0318C.BC1D1770]


Meathod-2: Dynamic Meathod – using the Service Chain Header (IETF).


1.     Service Layer(Archestration Layer) should provide the Service Information (Service, Next/Prev Service, Type, Priotiy, Action .. etc) to Openstack Neutron Controller.

2.     Neutron Controller to program the SFF(Compute node/OVS) to attach all the Service header and each service  IP address .. as per IETF.

3.     Service Header processing should be handled by the Service-VM.

When the Tennant traffic enters the OVS/Compute Nodes, based this information, Service Header needs to be attached.

[cid:image009.png at 01D0318C.BC1D1770]



Meathod-3: Hybrid  Meathod.

In both of the above meathods, when the packet needs to traver from one Service-VM1(vNF1) to other Service-VM2 (vNF2), it always needs travers as vNF1->SFF1->SFF2->vFN2.
This will be real overhead and adds lot of latency during packet processing
Instead if SFF1 itself identify which SFF has the next service information, we can avoid the packet traversal across OVS .
For this happen each Service-VM should have the complete service information under that controller.

Service VM will get Service Information by Service-APIs: This information will be used to forward the packet to Nest SFF.
Service Header (ietf) will be attached by SFF and will be processed by Service-VM.


[cid:image010.png at 01D0318C.BC1D1770]

These are my intial thoughts . Please let me know all other thoughts.


Regards,
keshava


From: Yuriy.Babenko at telekom.de [mailto:Yuriy.Babenko at telekom.de]
Sent: Wednesday, January 14, 2015 9:33 PM
To: openstack-dev at lists.openstack.org; mestery at mestery.com
Subject: Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining!

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:keshava.a at hp.com]
Gesendet: Donnerstag, 8. Januar 2015 07:19
An: mestery at mestery.com<mailto:mestery at 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:mestery at 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.erchun at zte.com.cn<mailto:lv.erchun at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 82621 bytes
Desc: oledata.mso
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.emz
Type: application/octet-stream
Size: 19024 bytes
Desc: image008.emz
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.emz
Type: application/octet-stream
Size: 16675 bytes
Desc: image012.emz
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image014.emz
Type: application/octet-stream
Size: 12469 bytes
Desc: image014.emz
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 48691 bytes
Desc: image006.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 22155 bytes
Desc: image007.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 21944 bytes
Desc: image009.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 20331 bytes
Desc: image010.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/0fbd2201/attachment-0007.png>