[ovs-discuss] [ovn4nfv]

Tue May 17 21:47:33 UTC 2016

Hi Murali,

It seems you have some misunderstanding on the networking-sfc API and did not know that it allows dynamic service insertion and removal into/from a chain as well as a chain's dynamic association with flow classifiers and support for chain graph involving chain branching/forking. To add on John's explanation on OpenStack networking-sfc API, each port-chain can be dynamically associated with zero, one or more flow classifiers. A port-chain created without association with a flow classifier means there is no flow going through that chain path yet. A flow classifier defines classification rules used to classify a traffic stream. The port-chain itself does not impose any restriction on the classifier. Actually the networking-sfc Flow classifier can be easily evolved to be a common flow classifier that can be used by SFC, QoS, TapaaS etc. features. 

Thanks,
Cathy

-----Original Message-----
From: discuss [mailto:discuss-bounces at openvswitch.org] On Behalf Of John McDowall
Sent: Tuesday, May 17, 2016 9:53 AM
To: Muralidharan Rangachari; Murali R
Cc: discuss at openvswitch.org
Subject: Re: [ovs-discuss] [ovn4nfv]

Murali,

Let me try and work through the networking-sfc API to see where the issues
are:

The port-pair construct defines the input/output ports of the VNF. If the VNF only has one port then they are the same.
The port-pair-group construct enables load balancing across a set of VNFs.
Not something we have done but I have hopes that we can leverage the load-balancing in OVN to enable this.
The port-chain allows the construction of a chain of port-pair-groups. It can be one or more.
Within the port chain is also the flow-classifier and I think this is the part that you might be struggling with?

I admit I have some struggles with it too and how to use it. I have used it to define the destination of the chain, not quite how it is defined in NSH but wanted to make something work. The approach I am using is to insert rules that intercept traffic going to (and coming from) a destination and insert a chain before/after the application. I think it could also be made to work in a single direction - if that is what you are thinking about.

As far as containers are concerned I think with the OVN approach to containers the same approach would work - I have it on my todo list.

Does this help?

Regards

John

BTW: My lastest changes are pushed to: https://github.com/doonhammer/ovs

On 5/16/16, 10:47 AM, "Muralidharan Rangachari"
<Muralidharan.Rangachari at huawei.com> wrote:

>
>> When you say "dynamic chains" are you referring to reordering linear 
>>chains  or are you talking about graphs where the path can change 
>>dynamically.
>>In
>> the case of the changes what would trigger the changes?
>
>We have orchestration mechanism to define the flows out of a graph and 
>can be sent down through our network controller (my piece) to define 
>the flows.
>We use many
>ways to get to the flow definition. It is dynamic in the sense, there 
>is no correlation between the NFVs in the chain and no restriction like 
>networking-sfc has on leading classifier.
>
>
>> What type of VNFs are you thinking about it - I (rather arbitrarily)  
>>constrained the VNFs to supporting bump in the wire traffic. The major  
>>reason was to keep the VNF out of requiring L2/L3 information, or 
>>modifying  L2/L3.
>
>My idea was to keep the vnf information at a higher layer (CMS) so we 
>can support any type of VNF. At this time I am not in a position to 
>provide info on the types of VNFs. We don't want to limit to bump on 
>the wire & be able to have chains/flows defined across L3.
>
>
>> Do you have an example or more of a write up of your approach, I 
>>think we  have some commonality as I have followed Russell's 
>>suggestion and created  a generic table for service chaining (not 
>>pushed the code yet) and it does  work on logical flows and ports - 
>>but I think it is different than what you  are suggesting.
>
>Please let me know the details of the new table you have, so we can 
>discuss more.
>
>Unfortunately the project I am on is not open source. The only change I 
>may need in the OVN is have capability to define custom flows using 
>logical elements.
>I may look into L3 flows a bit later, but we are still in elementary 
>stages of getting the L2 pieces to work. Major difference in our 
>approach as far as the documented info I have from all, is that the 
>port pair approach to defining service chains are too low level and 
>less flexible. Getting an abstraction such as Logical Service into OVN 
>is looking a bit out of place. That is just my opinion and not saying 
>we should not do. If we can avoid by having those abstractions in 
>Neutron I think will be cleaner. For my use cases I only need a generic 
>table similar to ACL with more options in match and actions. The 
>details such as port pairs and logical service, we are able to abstract 
>into the CMS/Network Controller.
>Also, my
>use cases are container VNFs, so many management pieces are outside of 
>Openstack.
>
>

_______________________________________________
discuss mailing list
discuss at openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss