Open Stack

John McDowall <jmcdowall at paloaltonetworks.com> wrote on 06/17/2016 04:07:38
PM:

> From: John McDowall <jmcdowall at paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: discuss <discuss at openvswitch.org>, Na Zhu <nazhu at cn.ibm.com>,
> "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Srilatha Tangirala/San
> Francisco/IBM at 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 <rmoats at us.ibm.com>
> Date: Friday, June 17, 2016 at 7:26 AM
> To: John McDowall <jmcdowall at paloaltonetworks.com>
> Cc: discuss <discuss at openvswitch.org>, Na Zhu <nazhu at cn.ibm.com>,
> "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>, Srilatha Tangirala
<srilatta at 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 <jmcdowall at paloaltonetworks.com> wrote on 06/15/2016
> 05:58:35 PM:
>
> > From: John McDowall <jmcdowall at paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: Na Zhu <nazhu at cn.ibm.com>, Srilatha Tangirala/San Francisco/
> > IBM at IBMUS, "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>, discuss
> > <discuss at 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 <rmoats at us.ibm.com>
> > Date: Tuesday, June 14, 2016 at 9:42 PM
> > To: John McDowall <jmcdowall at paloaltonetworks.com>
> > Cc: Na Zhu <nazhu at cn.ibm.com>, Srilatha Tangirala <srilatta at us.ibm.com
> > >, "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev at lists.openstack.org>, discuss <discuss at openvswitch.org>
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> >
> > "discuss" <discuss-bounces at openvswitch.org> wrote on 06/14/2016
10:31:40 PM:
> >
> > > From: John McDowall <jmcdowall at paloaltonetworks.com>
> > > To: Na Zhu <nazhu at cn.ibm.com>
> > > Cc: Srilatha Tangirala/San Francisco/IBM at IBMUS, "OpenStack
> > > Development Mailing List \(not for usage questions\)" <openstack-
> > > dev at lists.openstack.org>, discuss <discuss at 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-bounces at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160617/268dc003/attachment.html>