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