> 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
