<html><body><p><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 06/17/2016 04:07:38 PM:<br><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Ryan Moats/Omaha/IBM@IBMUS</tt><br><tt>> Cc: discuss <discuss@openvswitch.org>, Na Zhu <nazhu@cn.ibm.com>, <br>> "OpenStack Development Mailing List (not for usage questions)" <br>> <openstack-dev@lists.openstack.org>, Srilatha Tangirala/San <br>> Francisco/IBM@IBMUS</tt><br><tt>> Date: 06/17/2016 04:07 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>> See inline</tt><br><tt>> <br>> Regards</tt><br><tt>> <br>> John</tt><br><tt>> <br>> From: Ryan Moats <rmoats@us.ibm.com><br>> Date: Friday, June 17, 2016 at 7:26 AM<br>> To: John McDowall <jmcdowall@paloaltonetworks.com><br>> Cc: discuss <discuss@openvswitch.org>, Na Zhu <nazhu@cn.ibm.com>, <br>> "OpenStack Development Mailing List (not for usage questions)" <<br>> openstack-dev@lists.openstack.org>, Srilatha Tangirala <srilatta@us.ibm.com><br>> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> [networking-sfc] SFC andOVN</tt><br><tt>> <br>> Apologies for being delayed on replying and in-line back as well<br>> <br>> Ryan<br>> <br>> John McDowall <jmcdowall@paloaltonetworks.com> wrote on 06/15/2016 <br>> 05:58:35 PM:<br>> <br>> > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > To: Ryan Moats/Omaha/IBM@IBMUS<br>> > 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><br>> > Date: 06/15/2016 05:58 PM<br>> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> > [networking-sfc] SFC andOVN<br>> > <br>> > Ryan,<br>> > <br>> > In-line<br>> > <br>> > Regards<br>> > <br>> > John<br>> > <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<br>> > <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.<br>> <br>> RM> Back in the day when we discussed this internally here, SFCs could<br>> RM> be inserted as BiW (which we do a good job with currently) and at<br>> RM> network boundaries (which I'm not sure how I could do with the<br>> RM> current model) - my router question is more one of leaving the<br>> RM> door open for the boundary case (sorry for the pun) in the future.</tt><br><tt>> <br>> JED> Lets leave the door open and see what we can do once we have <br>> the basic model working?</tt><br><tt>> <br>> > 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...<br>> > 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.<br>> <br>> RM> yes and I see the action field of the ACL table being extended<br>> RM> to include "enter port chain <blah>" to cover that metadata.<br>> RM> Why couldn't bidirectional Flow Classifiers at SFC just be<br>> RM> implemented as a pair of uni-directional ACLs in the NB DB?<br>> RM> I'll back off on this point if I can see an example of an flow<br>> RM> classifier that can't be made to fit in the ACL table, but to<br>> RM> date, I've not been able to construct such a beast.<br>> <br>> JED> I would actually go a little further, the requirement on the <br>> flow-classifier is that </tt><br><tt>> JED> matches are supported by the switch/router. So the matches <br>> supported by the switch define the scope</tt><br><tt>> JED> of the flow-classifier. If I set the action of the ACL (defined<br>> by the flow-classifier) to send traffic the first port-pair</tt><br><tt>> Input port – would that work?</tt><br><br><tt>RM> I thought that we'd set the action of the ACL to be the port</tt><br><tt>RM> chain itself and then let the chain definition take over as</tt><br><tt>RM> far as steering goes.</tt><br><br><tt>Ryan</tt><BR>
</body></html>