Murali, Thanks for taking the time to look at our approach - always interested in a better way to solve the problem. To help me understand a couple of questions:
1. 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? 2. 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. 3. 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. Regards John From: Murali R <muralir...@gmail.com<mailto:muralir...@gmail.com>> Date: Sunday, May 15, 2016 at 11:10 PM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> Cc: Russell Bryant <russ...@ovn.org<mailto:russ...@ovn.org>>, "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" <discuss@openvswitch.org<mailto:discuss@openvswitch.org>>, "mural...@huawei.com<mailto:mural...@huawei.com>" <mural...@huawei.com<mailto:mural...@huawei.com>> Subject: Re: [ovs-discuss] [ovn4nfv] ovn-architecture.7.xml<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_ovs_blob_master_ovn_ovn-2Darchitecture.7.xml&d=CwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=dS-GKLYt1-LbCnueIwF_XntJgxqne2NLCBugNqHwJc4&s=Wocmp1PYZKaJ11wVFGRkJE1SbYvU32YteoA4teg0F5A&e=> ovn-nb.xml<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_ovs_blob_master_ovn_ovn-2Dnb.xml&d=CwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=dS-GKLYt1-LbCnueIwF_XntJgxqne2NLCBugNqHwJc4&s=G1ne4iUdIGm-8Ook2AiWl44w6H0Ftxdev_MNyvfOLHQ&e=> I have talked to the networking-sfc team and I think we have an approach to use the networking-sfc interface in Openstack. I think it is better than the API I created in Openstack and leverages their driver model. I am going to try and get something working to illustrate the model. Simple case should be relatively easy - if we want to add multiple VNF's it will get a little harder. John, Thank you for taking time to document your ideas. I am looking into a slightly different use case where the chains are not static as defined by the networking-sfc. We are geared more into the mobile networks. For my use case, I could just use the ACL table expanded to have more "match" entries and similar action entries as in the ACL handling. I had a few discussions earlier with Russell but I was busy with other stuff past couple of months. This weekend I was catching up with these email threads and also looking into ovn code for changes needed at my end. My idea is that the services could be modeled as "device" equivalent in nova/neutron and does not need to have a logical service in ovn. The service chain could be abstracted as custom flow definition. The sfc and your approach looks kind of geared to a specific static chain/service insertion definition, It is OK at openstack end to have what you need but we could keep ovn more generic. I wanted to throw in this idea & see if you could model all your "logical services" in networking-ovn (neutron side) and not add additional entity in ovn? The neutron db can have the sfc/sfi info, interpreted/translated to custom flows at networking-ovn. Also would it be possible to have a more generic ACL table (with more generic name), so we can define custom flows using logical ports and logical flows? This is a general question, not necessarily related to sfi or sfc. This way the ovn is purely defining the data paths and manages ports. External ids can provide mappings to device id as we do in nova/neutron. We could talk over the phone if you wish tomorrow. I have added my work email also here. -Murali
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
