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-boun...@openvswitch.org] On Behalf Of John McDowall Sent: Tuesday, May 17, 2016 9:53 AM To: Muralidharan Rangachari; Murali R Cc: discuss@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.rangach...@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@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss