<html><body><p><tt>Apologies for being delayed on replying and in-line back as well</tt><br><br><tt>Ryan</tt><br><br><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 06/15/2016 05:58:35 PM:<br></tt><tt><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Ryan Moats/Omaha/IBM@IBMUS</tt><br><tt>> Cc: Na Zhu <nazhu@cn.ibm.com>, Srilatha Tangirala/San Francisco/<br>> IBM@IBMUS, "OpenStack Development Mailing List (not for usage <br>> questions)" <openstack-dev@lists.openstack.org>, discuss <br>> <discuss@openvswitch.org></tt><br><tt>> Date: 06/15/2016 05:58 PM</tt><br><tt>> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> [networking-sfc] SFC andOVN</tt><br><tt>> <br>> Ryan,</tt><br><tt>> <br>> In-line</tt><br><tt>> <br>> Regards</tt><br><tt>> <br>> John</tt><br><tt>> <br>> From: Ryan Moats <rmoats@us.ibm.com><br>> Date: Tuesday, June 14, 2016 at 9:42 PM<br>> To: John McDowall <jmcdowall@paloaltonetworks.com><br>> Cc: Na Zhu <nazhu@cn.ibm.com>, Srilatha Tangirala <srilatta@us.ibm.com<br>> >, "OpenStack Development Mailing List (not for usage questions)" <<br>> openstack-dev@lists.openstack.org>, discuss <discuss@openvswitch.org><br>> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> [networking-sfc] SFC andOVN</tt><br><tt>> <br>> "discuss" <discuss-bounces@openvswitch.org> wrote on 06/14/2016 10:31:40 PM:<br>> <br>> > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > To: Na Zhu <nazhu@cn.ibm.com><br>> > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack <br>> > Development Mailing List \(not for usage questions\)" <openstack-<br>> > dev@lists.openstack.org>, discuss <discuss@openvswitch.org><br>> > Date: 06/14/2016 10:48 PM<br>> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> > [networking-sfc] SFC andOVN<br>> > Sent by: "discuss" <discuss-bounces@openvswitch.org><br>> > <br>> > Juno,<br>> > <br>> > It is a container for port-pair-groups and flow-classifier. I <br>> > imagine there could be more the than one port-chain per switch. Also<br>> > we may want to extend the model beyond a single lswitch <br>> <br>> I agree that there could be more than one port-chain per switch, determined<br>> by the flow classifier. <br>> <br>> What I'm confused by is:<br>> <br>> 1. Why are items only recorded in logical switches? I would think<br>> that I could also attach an SFC to a logical router - although I admit<br>> that the current neutron model for ports doesn't really allow that<br>> easily. Couple that with the change of name from Logical_Port to<br>> Logical_Switch_Port, and I'm left wondering if we aren't better off<br>> with the following "weak" links instead: <br>> -the Port_Chain includes the logical switch as an external_id<br>> -each Port_Pair_Group includes the Port_Chain as an external_id<br>> -each Port_Pair includes the PPG as an external_id<br>> -each Logical_Switch_Port includes the PP as an external_id<br>> <br>> I *think* that *might* allow me (in the future) to attach a port chain<br>> to a logical router by setting the logical router as an external_id and<br>> using Logical_Router_Ports to make up the PPs...<br>> <br>> JED> If there are “port-chain” tables for switches and routers I <br>> think I agree. Not sure how this is impacted by the type of VNF (see<br>> the last email to Juno). I struggle a bit with imagining the flows.</tt><br><br><tt>RM> Back in the day when we discussed this internally here, SFCs could</tt><br><tt>RM> be inserted as BiW (which we do a good job with currently) and at</tt><br><tt>RM> network boundaries (which I'm not sure how I could do with the</tt><br><tt>RM> current model) - my router question is more one of leaving the</tt><br><tt>RM> door open for the boundary case (sorry for the pun) in the future.</tt><br><br><tt>> 2. I still don't see what Logical_Flow_Classifier is buying me that<br>> ACL doesn't - I can codify all of the classifiers given in the match<br>> criteria of an ACL entry and codify the first PPG of the SFC as<br>> the action of the ACL entry...</tt><br><tt>> JED> Flow classifiers do map to an ACL entry – just need additional <br>> metadata, I.e. Action of the ACL and wether the rules should be uni <br>> or bi-directional. Though that information could be in the port-chain.</tt><br><br><tt>RM> yes and I see the action field of the ACL table being extended</tt><br><tt>RM> to include "enter port chain <blah>" to cover that metadata.</tt><br><tt>RM> Why couldn't bidirectional Flow Classifiers at SFC just be</tt><br><tt>RM> implemented as a pair of uni-directional ACLs in the NB DB?</tt><br><tt>RM> I'll back off on this point if I can see an example of an flow</tt><br><tt>RM> classifier that can't be made to fit in the ACL table, but to</tt><br><tt>RM> date, I've not been able to construct such a beast.</tt><br><br><BR>
</body></html>