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
