Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 06/02/2016 11:03:28
AM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff , "disc...@openvswitch.org"
> , Justin Pettit ,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> Date: 06/02/2016 11:03 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Sure – may need some help and it will probably be next week before Iget
to it.
>
> Regards
>
> John

John-

Let me see what I can do to push the ball along...

Ryan

>
> From: Ryan Moats 
> Date: Wednesday, June 1, 2016 at 1:25 PM
> To: John McDowall 
> Cc: Ben Pfaff , "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit , OpenStack
> Development Mailing List , Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall  wrote on 05/31/2016
> 07:57:02 PM:
>
> > From: John McDowall 
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Ben Pfaff , "disc...@openvswitch.org"
> > , Justin Pettit ,
> > "OpenStack Development Mailing List"  > d...@lists.openstack.org>, Russell Bryant 
> > Date: 05/31/2016 07:57 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > More help is always great :-). As far as who to collaborate, what
> > ever Is easiest for everyone – I am pretty flexible.
> >
> > Regards
> >
> > John
>
> Ok, then I'll ask that we go the submit WIP patches to each of
> networking-sfc and networking-ovn and an RFC patch to d...@openvswitch.org
> and iterate through review.openstack.org and patchworks.
>
> Could you submit the initial patches today or tomorrow? I'd rather
> go that route since you have the lion's share of the work so far
> and credit where credit is due...
>
> Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Sure - may need some help and it will probably be next week before I get to it.

Regards

John

From: Ryan Moats >
Date: Wednesday, June 1, 2016 at 1:25 PM
To: John McDowall 
>
Cc: Ben Pfaff >, 
"disc...@openvswitch.org" 
>, Justin Pettit 
>, OpenStack Development Mailing List 
>, 
Russell Bryant >
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/31/2016 07:57:02 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org"
> >, Justin Pettit 
> >,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> >
> Date: 05/31/2016 07:57 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> More help is always great :-). As far as who to collaborate, what
> ever Is easiest for everyone - I am pretty flexible.
>
> Regards
>
> John

Ok, then I'll ask that we go the submit WIP patches to each of
networking-sfc and networking-ovn and an RFC patch to 
d...@openvswitch.org
and iterate through review.openstack.org and patchworks.

Could you submit the initial patches today or tomorrow? I'd rather
go that route since you have the lion's share of the work so far
and credit where credit is due...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/31/2016 07:57:02
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff , "disc...@openvswitch.org"
> , Justin Pettit ,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> Date: 05/31/2016 07:57 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> More help is always great :-). As far as who to collaborate, what
> ever Is easiest for everyone – I am pretty flexible.
>
> Regards
>
> John

Ok, then I'll ask that we go the submit WIP patches to each of
networking-sfc and networking-ovn and an RFC patch to d...@openvswitch.org
and iterate through review.openstack.org and patchworks.

Could you submit the initial patches today or tomorrow? I'd rather
go that route since you have the lion's share of the work so far
and credit where credit is due...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

More help is always great :-). As far as who to collaborate, what ever Is 
easiest for everyone – I am pretty flexible.

Regards

John

From: Ryan Moats >
Date: Tuesday, May 31, 2016 at 1:59 PM
To: John McDowall 
>
Cc: Ben Pfaff >, 
"disc...@openvswitch.org" 
>, Justin Pettit 
>, OpenStack Development Mailing List 
>, 
Russell Bryant >
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/31/2016 03:21:30 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org"
> >, Justin Pettit 
> >,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> >
> Date: 05/31/2016 03:22 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Let me add the tables to OVN for SFC. That will give us a working
> system to prototype the flow classifier approach on. Hopefully I can
> get something done by end of week.
>
> Regards
>
> John

I've got some internal folks that are willing to help with writing code (as
I will be once I clear my current firefights) so the question of how to
collaborate with code now arises...

Are you comfortable with putting the changes on r.o.o as WiP and patchworks
as RFC and work through the review process or would you rather work via
forks and pull requests in github?

Ryan

> From: Ryan Moats >
> Date: Tuesday, May 31, 2016 at 10:17 AM
> To: John McDowall 
> >
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit 
> >, OpenStack
> Development Mailing List 
> >,
>  Russell Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/26/2016
> 11:08:43 AM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Ben Pfaff >, 
> > "disc...@openvswitch.org"
> > >, Justin Pettit 
> > >,
> > "OpenStack Development Mailing List"  > d...@lists.openstack.org>, Russell Bryant 
> > >
> > Date: 05/26/2016 11:09 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > My (incomplete) throughts about the flow-classifier are:
> >
> > 1)  ACL’s are more about denying access, while the flow classifier
> > is more about steering selected traffic to a path, so we would need
> > to deny-all except allowed flows.
> > 2)  The networking-sfc team has done a nice job with the drivers so
> > ovn has its own flow-classifier driver which allows us to align the
> > flow-classifier with the matches supported in ovs/ovn, which could
> > be an advantage.
>
> The ACL table has a very simple flow-classifier structure and I'd
> like to see if that can be re-used for the purpose of the SFC classifier
> (read that I feel the Logical_Flow_Classifier table is too complex).
> My initial thoughts were to look at extending the action column and
> using the external-ids field to differentiate between legacy ACLs and
> those that are used to intercept traffic and route it to an SFC.
>
> >
> > What were your thoughts on the schema it adds a lot of tables and a
> > lot of commands – cannot think of anyway around it
>
> In this case, I think that the other tables are reasonable and I'm
> uncomfortable trying to stretch the existing tables to cover that
> information...
>
> Ryan
>
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats >
> > Date: Wednesday, May 25, 2016 at 9:12 PM
> > To: John McDowall 
> > 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

 > >
> > > Ryan,
> > >
> > > Ok – I will let the experts weigh in on load balancing.
> > >
> > > In the meantime I have attached a couple of files to show where I am
> > > going. The first is sfc_dict.py and is a representation of the dict
> > > I am passing from SFC to OVN. This will then translate to the
> > > attached ovn-nb schema file.
> > >
> > > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > > schema but I could not think of any other way of doing it.
> > >
> > > Thoughts?
> > >
> > > John
> >
> > The dictionary looks fine for a starting point, and the more I look
> > at the classifier, the more I wonder if we can't do something with
> > the current ACL table to avoid duplication in the NB database
> > definition...
> >
> > Ryan
> >
> > > From: Ryan Moats <rmo...@us.ibm.com>
> > > Date: Wednesday, May 25, 2016 at 7:27 AM
> > > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > > Development Mailing List <openstack-dev@lists.openstack.org>, Ben
Pfaff <
> > > b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant <
> > russ...@ovn.org
> > > >
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > >
> > > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016
> > > 06:33:05 PM:
> > >
> > > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack

> > > > Development Mailing List" <openstack-dev@lists.openstack.org>
> > > > Date: 05/24/2016 06:33 PM
> > > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > > >
> > > > Ryan,
> > > >
> > > > Thanks for getting back to me and pointing me in a more OVS like
> > > > direction. What you say makes sense, let me hack something
together.
> > > > I have been a little distracted getting some use cases together.
The
> > > > other area is how to better map the flow-classifier I have been
> > > > thinking about it a little, but I will leave it till after we get
> > > > the chains done.
> > > >
> > > > Your load-balancing comment was very interesting – I saw some
> > > > patches for load-balancing a few months ago but nothing since. It
> > > > would be great if we could align with load-balancing as that would
> > > > make a really powerful solution.
> > > >
> > > > Regards
> > > >
> > > > John
> > >
> > > John-
> > >
> > > For the load balancing, I believe that you'll want to look at
> > > openvswitch's select group, as that should let you set up multiple
> > > buckets for each egress port in the port pairs that make up a port
> > > group.
> > >
> > > As I understand it, Table 0 identifies the logical port and logical
> > > flow. I'm worried that this means we'll end up with separate bucket
> > > rules for each ingress port of the port pairs that make up a port
> > > group, leading to a cardinality product in the number of rules.
> > > I'm trying to think of a way where Table 0 could identify the packet
> > > as being part of a particular port group, and then I'd only need one
> > > set of bucket rules to figure out the egress side.  However, the
> > > amount of free metadata space is limited and so before we go down
> > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > they buy into this idea or if they can think of an alternative.
> > >
> > > Ryan
> > >
> > > >
> > > > From: Ryan Moats <rmo...@us.ibm.com>
> > > > Date: Monday, May 23, 2016 at 9:06 PM
> > > > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > > > Development Mailing List <openstack-dev@lists.openstack.org>
> > > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > > >
> > > > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> > > > 03:55:14 PM:
> > > >
> > > &g

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/31/2016 03:19:54
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff , "disc...@openvswitch.org"
> , Justin Pettit ,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> Date: 05/31/2016 03:20 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Hopefully – just wanted to make sure it was there.
>
> Regards
>
> John

I think having that as one of the tests to make sure is a good idea...

Ryan

>
> From: Ryan Moats 
> Date: Tuesday, May 31, 2016 at 10:02 AM
> To: John McDowall 
> Cc: Ben Pfaff , "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit , OpenStack
> Development Mailing List , Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall  wrote on 05/26/2016
> 10:59:48 AM:
>
> > From: John McDowall 
> > To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff 
> > Cc: "disc...@openvswitch.org" , Justin
> > Pettit , OpenStack Development Mailing List
> > , Russell Bryant 
> > Date: 05/26/2016 11:00 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Agree with your description of the problem. The only thing I would
> > add is that in the case of bi-directional chains the return flows
> > need to go through the same VNF(Port-pair).
>
> I'm pretty sure that is caught automagically, isn't it?
>
> Ryan
>
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats 
> > Date: Wednesday, May 25, 2016 at 9:29 PM
> > To: Ben Pfaff 
> > Cc: "disc...@openvswitch.org" , John McDowall
<
> > jmcdow...@paloaltonetworks.com>, Justin Pettit ,
> > OpenStack Development Mailing List  > >, Russell Bryant 
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ben Pfaff  wrote on 05/25/2016 07:44:43 PM:
> >
> > > From: Ben Pfaff 
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: John McDowall ,
> > > "disc...@openvswitch.org" , OpenStack
> > > Development Mailing List , Justin
> > > Pettit , Russell Bryant 
> > > Date: 05/25/2016 07:44 PM
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > >
> > > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > > > As I understand it, Table 0 identifies the logical port and logical
> > > > flow. I'm worried that this means we'll end up with separate bucket
> > > > rules for each ingress port of the port pairs that make up a port
> > > > group, leading to a cardinality product in the number of rules.
> > > > I'm trying to think of a way where Table 0 could identify the
packet
> > > > as being part of a particular port group, and then I'd only need
one
> > > > set of bucket rules to figure out the egress side.  However, the
> > > > amount of free metadata space is limited and so before we go down
> > > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > > they buy into this idea or if they can think of an alternative.
> > >
> > > I've barely been following the discussion, so a recap of the question
> > > here would help a lot.
> > >
> >
> > Sure (and John gets to correct me where I'm wrong) - the SFC proposal
> > is to carry a chain as a ordered set of port groups, where each group
> > consists of multiple port pairs. Each port pair consists of an ingress
> > port and an egress port, so that traffic is load balanced between
> > the ingress ports of a group. Traffic from the egress port of a group
> > is sent to the ingress port of the next group (ingress and egress here
> > are from the point of view of the thing getting the traffic).
> >
> > I was suggesting to John that from the view of the switch, this would
> > be reversed in the openvswitch rules - the proposed CHAINING stage
> > in the ingress pipeline would apply the classifier for traffic entering
> > a chain and identify traffic coming from an egress SFC port in the
> > midst of a chain. The egress pipeline would identify the next ingress
SFC
> > port that gets the traffic or the final destination for traffic exiting
> > the chain.
> >
> > Further, I pointed him at the select group for how traffic could be
> > load balanced between the different ports that are contained in a port
> > group, but that I was worried that I'd need a cartesian product 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Let me add the tables to OVN for SFC. That will give us a working system to 
prototype the flow classifier approach on. Hopefully I can get something done 
by end of week.

Regards

John

From: Ryan Moats >
Date: Tuesday, May 31, 2016 at 10:17 AM
To: John McDowall 
>
Cc: Ben Pfaff >, 
"disc...@openvswitch.org" 
>, Justin Pettit 
>, OpenStack Development Mailing List 
>, 
Russell Bryant >
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/26/2016 11:08:43 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org"
> >, Justin Pettit 
> >,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> >
> Date: 05/26/2016 11:09 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> My (incomplete) throughts about the flow-classifier are:
>
> 1)  ACL’s are more about denying access, while the flow classifier
> is more about steering selected traffic to a path, so we would need
> to deny-all except allowed flows.
> 2)  The networking-sfc team has done a nice job with the drivers so
> ovn has its own flow-classifier driver which allows us to align the
> flow-classifier with the matches supported in ovs/ovn, which could
> be an advantage.

The ACL table has a very simple flow-classifier structure and I'd
like to see if that can be re-used for the purpose of the SFC classifier
(read that I feel the Logical_Flow_Classifier table is too complex).
My initial thoughts were to look at extending the action column and
using the external-ids field to differentiate between legacy ACLs and
those that are used to intercept traffic and route it to an SFC.

>
> What were your thoughts on the schema it adds a lot of tables and a
> lot of commands – cannot think of anyway around it

In this case, I think that the other tables are reasonable and I'm
uncomfortable trying to stretch the existing tables to cover that
information...

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats >
> Date: Wednesday, May 25, 2016 at 9:12 PM
> To: John McDowall 
> >
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit 
> >, OpenStack
> Development Mailing List 
> >,
>  Russell Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/25/2016
> 07:27:46 PM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > >, "OpenStack
> > Development Mailing List" 
> > >,
> >  Ben
> > Pfaff >, Justin Pettit 
> > >, Russell Bryant
> > >
> > Date: 05/25/2016 07:28 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Ok – I will let the experts weigh in on load balancing.
> >
> > In the meantime I have attached a couple of files to show where I am
> > going. The first is sfc_dict.py and is a representation of the dict
> > I am passing from SFC to OVN. This will then translate to the
> > attached ovn-nb schema file.
> >
> > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > schema but I could not think of any other way of doing it.
> >
> > Thoughts?
> >
> > John
>
> The dictionary looks fine for a starting point, and the more I look
> at the classifier, the more I wonder if we can't do something with
> the current ACL table to avoid duplication in the NB database
> 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Hopefully – just wanted to make sure it was there.

Regards

John

From: Ryan Moats >
Date: Tuesday, May 31, 2016 at 10:02 AM
To: John McDowall 
>
Cc: Ben Pfaff >, 
"disc...@openvswitch.org" 
>, Justin Pettit 
>, OpenStack Development Mailing List 
>, 
Russell Bryant >
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/26/2016 10:59:48 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff >
> Cc: "disc...@openvswitch.org" 
> >, Justin
> Pettit >, OpenStack Development 
> Mailing List
> >,
>  Russell Bryant >
> Date: 05/26/2016 11:00 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Agree with your description of the problem. The only thing I would
> add is that in the case of bi-directional chains the return flows
> need to go through the same VNF(Port-pair).

I'm pretty sure that is caught automagically, isn't it?

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats >
> Date: Wednesday, May 25, 2016 at 9:29 PM
> To: Ben Pfaff >
> Cc: "disc...@openvswitch.org" 
> >, John McDowall <
> jmcdow...@paloaltonetworks.com>, 
> Justin Pettit >,
> OpenStack Development Mailing List 
> 
> >, Russell Bryant >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ben Pfaff > wrote on 05/25/2016 07:44:43 PM:
>
> > From: Ben Pfaff >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: John McDowall 
> > >,
> > "disc...@openvswitch.org" 
> > >, OpenStack
> > Development Mailing List 
> > >,
> >  Justin
> > Pettit >, Russell Bryant 
> > >
> > Date: 05/25/2016 07:44 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > > As I understand it, Table 0 identifies the logical port and logical
> > > flow. I'm worried that this means we'll end up with separate bucket
> > > rules for each ingress port of the port pairs that make up a port
> > > group, leading to a cardinality product in the number of rules.
> > > I'm trying to think of a way where Table 0 could identify the packet
> > > as being part of a particular port group, and then I'd only need one
> > > set of bucket rules to figure out the egress side.  However, the
> > > amount of free metadata space is limited and so before we go down
> > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > they buy into this idea or if they can think of an alternative.
> >
> > I've barely been following the discussion, so a recap of the question
> > here would help a lot.
> >
>
> Sure (and John gets to correct me where I'm wrong) - the SFC proposal
> is to carry a chain as a ordered set of port groups, where each group
> consists of multiple port pairs. Each port pair consists of an ingress
> port and an egress port, so that traffic is load balanced between
> the ingress ports of a group. Traffic from the egress port of a group
> is sent to the ingress port of the next group (ingress and egress here
> are from the point of view of the thing getting the traffic).
>
> I was suggesting to John that from the view of the switch, this would
> be reversed in the openvswitch rules - the proposed CHAINING stage
> in the ingress pipeline would apply the classifier for traffic entering
> a chain and identify traffic coming from an egress SFC port in the
> midst of a chain. The egress pipeline would identify the next ingress SFC
> port that gets the traffic 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Henry Fourie]

Ryan,
   I agree that having rules in the ACL table with actions that would steer the 
packets to SFC
Processing would be a good approach.

-Louis

From: Ryan Moats [mailto:rmo...@us.ibm.com]
Sent: Tuesday, May 31, 2016 10:18 AM
To: John McDowall
Cc: Justin Pettit; Russell Bryant; Ben Pfaff; OpenStack Development Mailing 
List; disc...@openvswitch.org
Subject: Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote 
on 05/26/2016 11:08:43 AM:

> From: John McDowall 
> <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, 
> "disc...@openvswitch.org<mailto:disc...@openvswitch.org>"
> <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>, Justin Pettit 
> <jpet...@ovn.org<mailto:jpet...@ovn.org>>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org<mailto:d...@lists.openstack.org>>, Russell Bryant 
> <russ...@ovn.org<mailto:russ...@ovn.org>>
> Date: 05/26/2016 11:09 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> My (incomplete) throughts about the flow-classifier are:
>
> 1)  ACL’s are more about denying access, while the flow classifier
> is more about steering selected traffic to a path, so we would need
> to deny-all except allowed flows.
> 2)  The networking-sfc team has done a nice job with the drivers so
> ovn has its own flow-classifier driver which allows us to align the
> flow-classifier with the matches supported in ovs/ovn, which could
> be an advantage.

The ACL table has a very simple flow-classifier structure and I'd
like to see if that can be re-used for the purpose of the SFC classifier
(read that I feel the Logical_Flow_Classifier table is too complex).
My initial thoughts were to look at extending the action column and
using the external-ids field to differentiate between legacy ACLs and
those that are used to intercept traffic and route it to an SFC.

>
> What were your thoughts on the schema it adds a lot of tables and a
> lot of commands – cannot think of anyway around it

In this case, I think that the other tables are reasonable and I'm
uncomfortable trying to stretch the existing tables to cover that
information...

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>>
> Date: Wednesday, May 25, 2016 at 9:12 PM
> To: John McDowall 
> <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
> Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, 
> "disc...@openvswitch.org<mailto:disc...@openvswitch.org>" <
> disc...@openvswitch.org<mailto:disc...@openvswitch.org>>, Justin Pettit 
> <jpet...@ovn.org<mailto:jpet...@ovn.org>>, OpenStack
> Development Mailing List 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>,
>  Russell Bryant <
> russ...@ovn.org<mailto:russ...@ovn.org>>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote 
> on 05/25/2016
> 07:27:46 PM:
>
> > From: John McDowall 
> > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org<mailto:disc...@openvswitch.org>" 
> > <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>, "OpenStack
> > Development Mailing List" 
> > <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>,
> >  Ben
> > Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, Justin Pettit 
> > <jpet...@ovn.org<mailto:jpet...@ovn.org>>, Russell Bryant
> > <russ...@ovn.org<mailto:russ...@ovn.org>>
> > Date: 05/25/2016 07:28 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Ok – I will let the experts weigh in on load balancing.
> >
> > In the meantime I have attached a couple of files to show where I am
> > going. The first is sfc_dict.py and is a representation of the dict
> > I am passing from SFC to OVN. This will then translate to the
> > attached ovn-nb schema file.
> >
> > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > schema but I could not think of any other way of doing it.
> >
> > Thoughts?
> >
> 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

Thanks for getting back to me and pointing me in a more OVS like
> > > direction. What you say makes sense, let me hack something together.
> > > I have been a little distracted getting some use cases together. The
> > > other area is how to better map the flow-classifier I have been
> > > thinking about it a little, but I will leave it till after we get
> > > the chains done.
> > >
> > > Your load-balancing comment was very interesting – I saw some
> > > patches for load-balancing a few months ago but nothing since. It
> > > would be great if we could align with load-balancing as that would
> > > make a really powerful solution.
> > >
> > > Regards
> > >
> > > John
> >
> > John-
> >
> > For the load balancing, I believe that you'll want to look at
> > openvswitch's select group, as that should let you set up multiple
> > buckets for each egress port in the port pairs that make up a port
> > group.
> >
> > As I understand it, Table 0 identifies the logical port and logical
> > flow. I'm worried that this means we'll end up with separate bucket
> > rules for each ingress port of the port pairs that make up a port
> > group, leading to a cardinality product in the number of rules.
> > I'm trying to think of a way where Table 0 could identify the packet
> > as being part of a particular port group, and then I'd only need one
> > set of bucket rules to figure out the egress side.  However, the
> > amount of free metadata space is limited and so before we go down
> > this path, I'm going to pull Justin, Ben and Russell in to see if
> > they buy into this idea or if they can think of an alternative.
> >
> > Ryan
> >
> > >
> > > From: Ryan Moats <rmo...@us.ibm.com>
> > > Date: Monday, May 23, 2016 at 9:06 PM
> > > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > > Development Mailing List <openstack-dev@lists.openstack.org>
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > >
> > > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> > > 03:55:14 PM:
> > >
> > > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack

> > > > Development Mailing List" <openstack-dev@lists.openstack.org>
> > > > Date: 05/18/2016 03:55 PM
> > > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > > >
> > > > Ryan,
> > > >
> > > > OK all three repos and now aligned with their masters. I have done
> > > > some simple level system tests and I can steer traffic to a single
> > > > VNF.  Note: some additional changes to networking-sfc to catch-up
> > > > with their changes.
> > > >
> > > > https://github.com/doonhammer/networking-sfc
> > > > https://github.com/doonhammer/networking-ovn
> > > > https://github.com/doonhammer/ovs
> > > >
> > > > The next tasks I see are:
> > > >
> > > > 1. Decouple networking-sfc and networking-ovn. I am thinking that I

> > > > will pass a nested port-chain dictionary holding port-pairs/port-
> > > > pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> > > > 2. Align the interface between networking-ovn and ovs/ovn to match
> > > > the nested dictionary in 1.
> > > > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-
> > chain model.
> > > > 4. Add ability to support chain of port-pairs
> > > > 5. Think about flow-classifiers and how best to map them, today I
> > > > just map the logical-port and ignore everything else.
> > > >
> > > > Any other suggestions/feedback?
> > > >
> > > > Regards
> > > >
> > > > John
> > >
> > > John-
> > >
> > > (Sorry for sending this twice, but I forgot that text/html is not
liked
> > > by the mailing lists ...)
> > >
> > > My apologies for not answering this sooner - I was giving a two day
> > > training on Tues/Wed last week and came back to my son graduating
> > > from HS the next day, so things have been a bit of a whirlwind here.
> > >
> > > Looking at the gith

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/26/2016 10:59:48
AM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff 
> Cc: "disc...@openvswitch.org" , Justin
> Pettit , OpenStack Development Mailing List
> , Russell Bryant 
> Date: 05/26/2016 11:00 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Agree with your description of the problem. The only thing I would
> add is that in the case of bi-directional chains the return flows
> need to go through the same VNF(Port-pair).

I'm pretty sure that is caught automagically, isn't it?

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats 
> Date: Wednesday, May 25, 2016 at 9:29 PM
> To: Ben Pfaff 
> Cc: "disc...@openvswitch.org" , John McDowall <
> jmcdow...@paloaltonetworks.com>, Justin Pettit ,
> OpenStack Development Mailing List  >, Russell Bryant 
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ben Pfaff  wrote on 05/25/2016 07:44:43 PM:
>
> > From: Ben Pfaff 
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: John McDowall ,
> > "disc...@openvswitch.org" , OpenStack
> > Development Mailing List , Justin
> > Pettit , Russell Bryant 
> > Date: 05/25/2016 07:44 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > > As I understand it, Table 0 identifies the logical port and logical
> > > flow. I'm worried that this means we'll end up with separate bucket
> > > rules for each ingress port of the port pairs that make up a port
> > > group, leading to a cardinality product in the number of rules.
> > > I'm trying to think of a way where Table 0 could identify the packet
> > > as being part of a particular port group, and then I'd only need one
> > > set of bucket rules to figure out the egress side.  However, the
> > > amount of free metadata space is limited and so before we go down
> > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > they buy into this idea or if they can think of an alternative.
> >
> > I've barely been following the discussion, so a recap of the question
> > here would help a lot.
> >
>
> Sure (and John gets to correct me where I'm wrong) - the SFC proposal
> is to carry a chain as a ordered set of port groups, where each group
> consists of multiple port pairs. Each port pair consists of an ingress
> port and an egress port, so that traffic is load balanced between
> the ingress ports of a group. Traffic from the egress port of a group
> is sent to the ingress port of the next group (ingress and egress here
> are from the point of view of the thing getting the traffic).
>
> I was suggesting to John that from the view of the switch, this would
> be reversed in the openvswitch rules - the proposed CHAINING stage
> in the ingress pipeline would apply the classifier for traffic entering
> a chain and identify traffic coming from an egress SFC port in the
> midst of a chain. The egress pipeline would identify the next ingress SFC
> port that gets the traffic or the final destination for traffic exiting
> the chain.
>
> Further, I pointed him at the select group for how traffic could be
> load balanced between the different ports that are contained in a port
> group, but that I was worried that I'd need a cartesian product of rules
> in the egress chain stage.  Having thought about this some more, I'm
> realizing that I'm confused and the number of rules should not be that
> bad:
>
> - Table 0 will identify the logical port the traffic comes from
> - The CHAINING stage of the ingress pipeline can map that logical
>   port information to the port group the port is part of.
> - The CHAINING stage of the egress pipeline would use that port
>   group information to select the next logical port via a select group.
>
> I believe this requires a total number of rules in the CHAINING stages
> of the order of the number of ports in the service chain.
>
> The above is predicated on carrying the port group information from
> the ingress pipeline to the egress pipeline in metadata, so I would
> be looking to you for ideas on where this data could be carried, since
> I know that we don't have infinite space for said metadata...
>
> Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

My (incomplete) throughts about the flow-classifier are:

1)  ACL’s are more about denying access, while the flow classifier is more 
about steering selected traffic to a path, so we would need to deny-all except 
allowed flows.
2)  The networking-sfc team has done a nice job with the drivers so ovn has its 
own flow-classifier driver which allows us to align the flow-classifier with 
the matches supported in ovs/ovn, which could be an advantage.

What were your thoughts on the schema it adds a lot of tables and a lot of 
commands – cannot think of anyway around it

Regards

John

From: Ryan Moats >
Date: Wednesday, May 25, 2016 at 9:12 PM
To: John McDowall 
>
Cc: Ben Pfaff >, 
"disc...@openvswitch.org" 
>, Justin Pettit 
>, OpenStack Development Mailing List 
>, 
Russell Bryant >
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/25/2016 07:27:46 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >,
>  Ben
> Pfaff >, Justin Pettit 
> >, Russell Bryant
> >
> Date: 05/25/2016 07:28 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Ok – I will let the experts weigh in on load balancing.
>
> In the meantime I have attached a couple of files to show where I am
> going. The first is sfc_dict.py and is a representation of the dict
> I am passing from SFC to OVN. This will then translate to the
> attached ovn-nb schema file.
>
> One of my concerns is that SFC almost doubles the size of the ovn-nb
> schema but I could not think of any other way of doing it.
>
> Thoughts?
>
> John

The dictionary looks fine for a starting point, and the more I look
at the classifier, the more I wonder if we can't do something with
the current ACL table to avoid duplication in the NB database
definition...

Ryan

> From: Ryan Moats >
> Date: Wednesday, May 25, 2016 at 7:27 AM
> To: John McDowall 
> >
> Cc: "disc...@openvswitch.org" 
> >, OpenStack
> Development Mailing List 
> >,
>  Ben Pfaff <
> b...@ovn.org>, Justin Pettit 
> >, Russell Bryant 
> 
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/24/2016
> 06:33:05 PM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > >, "OpenStack
> > Development Mailing List" 
> > >
> > Date: 05/24/2016 06:33 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks for getting back to me and pointing me in a more OVS like
> > direction. What you say makes sense, let me hack something together.
> > I have been a little distracted getting some use cases together. The
> > other area is how to better map the flow-classifier I have been
> > thinking about it a little, but I will leave it till after we get
> > the chains done.
> >
> > Your load-balancing comment was very interesting – I saw some
> > patches for load-balancing a few months ago but nothing since. It
> > would be great if we could align with load-balancing as that would
> > make a really powerful solution.
> >
> > Regards
> >
> > John
>
> John-
>
> For the load balancing, I believe that you'll want to look at
> openvswitch's select group, as that should let you set up multiple
> buckets for each egress port in the port pairs that make up a port
> group.
>
> As I understand it, Table 0 identifies the logical port and logical
> flow. I'm 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

Ben Pfaff  wrote on 05/25/2016 07:44:43 PM:

> From: Ben Pfaff 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: John McDowall ,
> "disc...@openvswitch.org" , OpenStack
> Development Mailing List , Justin
> Pettit , Russell Bryant 
> Date: 05/25/2016 07:44 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > As I understand it, Table 0 identifies the logical port and logical
> > flow. I'm worried that this means we'll end up with separate bucket
> > rules for each ingress port of the port pairs that make up a port
> > group, leading to a cardinality product in the number of rules.
> > I'm trying to think of a way where Table 0 could identify the packet
> > as being part of a particular port group, and then I'd only need one
> > set of bucket rules to figure out the egress side.  However, the
> > amount of free metadata space is limited and so before we go down
> > this path, I'm going to pull Justin, Ben and Russell in to see if
> > they buy into this idea or if they can think of an alternative.
>
> I've barely been following the discussion, so a recap of the question
> here would help a lot.
>

Sure (and John gets to correct me where I'm wrong) - the SFC proposal
is to carry a chain as a ordered set of port groups, where each group
consists of multiple port pairs. Each port pair consists of an ingress
port and an egress port, so that traffic is load balanced between
the ingress ports of a group. Traffic from the egress port of a group
is sent to the ingress port of the next group (ingress and egress here
are from the point of view of the thing getting the traffic).

I was suggesting to John that from the view of the switch, this would
be reversed in the openvswitch rules - the proposed CHAINING stage
in the ingress pipeline would apply the classifier for traffic entering
a chain and identify traffic coming from an egress SFC port in the
midst of a chain. The egress pipeline would identify the next ingress SFC
port that gets the traffic or the final destination for traffic exiting
the chain.

Further, I pointed him at the select group for how traffic could be
load balanced between the different ports that are contained in a port
group, but that I was worried that I'd need a cartesian product of rules
in the egress chain stage.  Having thought about this some more, I'm
realizing that I'm confused and the number of rules should not be that
bad:

- Table 0 will identify the logical port the traffic comes from
- The CHAINING stage of the ingress pipeline can map that logical
  port information to the port group the port is part of.
- The CHAINING stage of the egress pipeline would use that port
  group information to select the next logical port via a select group.

I believe this requires a total number of rules in the CHAINING stages
of the order of the number of ports in the service chain.

The above is predicated on carrying the port group information from
the ingress pipeline to the egress pipeline in metadata, so I would
be looking to you for ideas on where this data could be carried, since
I know that we don't have infinite space for said metadata...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/25/2016 07:27:46
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>, Ben
> Pfaff <b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
> <russ...@ovn.org>
> Date: 05/25/2016 07:28 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Ok – I will let the experts weigh in on load balancing.
>
> In the meantime I have attached a couple of files to show where I am
> going. The first is sfc_dict.py and is a representation of the dict
> I am passing from SFC to OVN. This will then translate to the
> attached ovn-nb schema file.
>
> One of my concerns is that SFC almost doubles the size of the ovn-nb
> schema but I could not think of any other way of doing it.
>
> Thoughts?
>
> John

The dictionary looks fine for a starting point, and the more I look
at the classifier, the more I wonder if we can't do something with
the current ACL table to avoid duplication in the NB database
definition...

Ryan

> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Wednesday, May 25, 2016 at 7:27 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Ben Pfaff <
> b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
<russ...@ovn.org
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016
> 06:33:05 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/24/2016 06:33 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks for getting back to me and pointing me in a more OVS like
> > direction. What you say makes sense, let me hack something together.
> > I have been a little distracted getting some use cases together. The
> > other area is how to better map the flow-classifier I have been
> > thinking about it a little, but I will leave it till after we get
> > the chains done.
> >
> > Your load-balancing comment was very interesting – I saw some
> > patches for load-balancing a few months ago but nothing since. It
> > would be great if we could align with load-balancing as that would
> > make a really powerful solution.
> >
> > Regards
> >
> > John
>
> John-
>
> For the load balancing, I believe that you'll want to look at
> openvswitch's select group, as that should let you set up multiple
> buckets for each egress port in the port pairs that make up a port
> group.
>
> As I understand it, Table 0 identifies the logical port and logical
> flow. I'm worried that this means we'll end up with separate bucket
> rules for each ingress port of the port pairs that make up a port
> group, leading to a cardinality product in the number of rules.
> I'm trying to think of a way where Table 0 could identify the packet
> as being part of a particular port group, and then I'd only need one
> set of bucket rules to figure out the egress side.  However, the
> amount of free metadata space is limited and so before we go down
> this path, I'm going to pull Justin, Ben and Russell in to see if
> they buy into this idea or if they can think of an alternative.
>
> Ryan
>
> >
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Monday, May 23, 2016 at 9:06 PM
> > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > Development Mailing List <openstack-dev@lists.openstack.org>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> > 03:55:14 PM:
> >
> > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > > Development Mailing List" <openstack-dev@lists.openstack.org>
> > > Date: 05/18/2016 03:55 PM
&g

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ben Pfaff]

On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> As I understand it, Table 0 identifies the logical port and logical
> flow. I'm worried that this means we'll end up with separate bucket
> rules for each ingress port of the port pairs that make up a port
> group, leading to a cardinality product in the number of rules.
> I'm trying to think of a way where Table 0 could identify the packet
> as being part of a particular port group, and then I'd only need one
> set of bucket rules to figure out the egress side.  However, the
> amount of free metadata space is limited and so before we go down
> this path, I'm going to pull Justin, Ben and Russell in to see if
> they buy into this idea or if they can think of an alternative.

I've barely been following the discussion, so a recap of the question
here would help a lot.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Ok – I will let the experts weigh in on load balancing.

In the meantime I have attached a couple of files to show where I am going. The 
first is sfc_dict.py and is a representation of the dict I am passing from SFC 
to OVN. This will then translate to the attached ovn-nb schema file.

One of my concerns is that SFC almost doubles the size of the ovn-nb schema but 
I could not think of any other way of doing it.

Thoughts?

John

From: Ryan Moats >
Date: Wednesday, May 25, 2016 at 7:27 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>, 
Ben Pfaff >, Justin Pettit 
>, Russell Bryant 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/24/2016 06:33:05 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/24/2016 06:33 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks for getting back to me and pointing me in a more OVS like
> direction. What you say makes sense, let me hack something together.
> I have been a little distracted getting some use cases together. The
> other area is how to better map the flow-classifier I have been
> thinking about it a little, but I will leave it till after we get
> the chains done.
>
> Your load-balancing comment was very interesting – I saw some
> patches for load-balancing a few months ago but nothing since. It
> would be great if we could align with load-balancing as that would
> make a really powerful solution.
>
> Regards
>
> John

John-

For the load balancing, I believe that you'll want to look at
openvswitch's select group, as that should let you set up multiple
buckets for each egress port in the port pairs that make up a port
group.

As I understand it, Table 0 identifies the logical port and logical
flow. I'm worried that this means we'll end up with separate bucket
rules for each ingress port of the port pairs that make up a port
group, leading to a cardinality product in the number of rules.
I'm trying to think of a way where Table 0 could identify the packet
as being part of a particular port group, and then I'd only need one
set of bucket rules to figure out the egress side.  However, the
amount of free metadata space is limited and so before we go down
this path, I'm going to pull Justin, Ben and Russell in to see if
they buy into this idea or if they can think of an alternative.

Ryan

>
> From: Ryan Moats >
> Date: Monday, May 23, 2016 at 9:06 PM
> To: John McDowall 
> >
> Cc: "disc...@openvswitch.org" 
> >, OpenStack
> Development Mailing List 
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/18/2016
> 03:55:14 PM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > >, "OpenStack
> > Development Mailing List" 
> > >
> > Date: 05/18/2016 03:55 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > OK all three repos and now aligned with their masters. I have done
> > some simple level system tests and I can steer traffic to a single
> > VNF.  Note: some additional changes to networking-sfc to catch-up
> > with their changes.
> >
> > https://github.com/doonhammer/networking-sfc
> > 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016 06:33:05
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/24/2016 06:33 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks for getting back to me and pointing me in a more OVS like
> direction. What you say makes sense, let me hack something together.
> I have been a little distracted getting some use cases together. The
> other area is how to better map the flow-classifier I have been
> thinking about it a little, but I will leave it till after we get
> the chains done.
>
> Your load-balancing comment was very interesting – I saw some
> patches for load-balancing a few months ago but nothing since. It
> would be great if we could align with load-balancing as that would
> make a really powerful solution.
>
> Regards
>
> John

John-

For the load balancing, I believe that you'll want to look at
openvswitch's select group, as that should let you set up multiple
buckets for each egress port in the port pairs that make up a port
group.

As I understand it, Table 0 identifies the logical port and logical
flow. I'm worried that this means we'll end up with separate bucket
rules for each ingress port of the port pairs that make up a port
group, leading to a cardinality product in the number of rules.
I'm trying to think of a way where Table 0 could identify the packet
as being part of a particular port group, and then I'd only need one
set of bucket rules to figure out the egress side.  However, the
amount of free metadata space is limited and so before we go down
this path, I'm going to pull Justin, Ben and Russell in to see if
they buy into this idea or if they can think of an alternative.

Ryan

>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Monday, May 23, 2016 at 9:06 PM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> 03:55:14 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/18/2016 03:55 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > OK all three repos and now aligned with their masters. I have done
> > some simple level system tests and I can steer traffic to a single
> > VNF.  Note: some additional changes to networking-sfc to catch-up
> > with their changes.
> >
> > https://github.com/doonhammer/networking-sfc
> > https://github.com/doonhammer/networking-ovn
> > https://github.com/doonhammer/ovs
> >
> > The next tasks I see are:
> >
> > 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> > will pass a nested port-chain dictionary holding port-pairs/port-
> > pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> > 2. Align the interface between networking-ovn and ovs/ovn to match
> > the nested dictionary in 1.
> > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain
model.
> > 4. Add ability to support chain of port-pairs
> > 5. Think about flow-classifiers and how best to map them, today I
> > just map the logical-port and ignore everything else.
> >
> > Any other suggestions/feedback?
> >
> > Regards
> >
> > John
>
> John-
>
> (Sorry for sending this twice, but I forgot that text/html is not liked
> by the mailing lists ...)
>
> My apologies for not answering this sooner - I was giving a two day
> training on Tues/Wed last week and came back to my son graduating
> from HS the next day, so things have been a bit of a whirlwind here.
>
> Looking at the github repos, I like the idea of passing a dictionary
> from networking-sfc to networking-ovn. The flow classifiers should
> be relatively straightforward to map to ovs match rules (famous last
> words)...
>
> I've probably missed an orbit here, but in the ovn-northd implementation,
> I was expecting to find service chains in the egress and router pipelines
> in addition to the ingress pipeline (see below for why I

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Thanks for getting back to me and pointing me in a more OVS like direction. 
What you say makes sense, let me hack something together. I have been a little 
distracted getting some use cases together. The other area is how to better map 
the flow-classifier I have been thinking about it a little, but I will leave it 
till after we get the chains done.

Your load-balancing comment was very interesting - I saw some patches for 
load-balancing a few months ago but nothing since. It would be great if we 
could align with load-balancing as that would make a really powerful solution.

Regards

John

From: Ryan Moats >
Date: Monday, May 23, 2016 at 9:06 PM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/18/2016 03:55:14 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/18/2016 03:55 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> OK all three repos and now aligned with their masters. I have done
> some simple level system tests and I can steer traffic to a single
> VNF.  Note: some additional changes to networking-sfc to catch-up
> with their changes.
>
> https://github.com/doonhammer/networking-sfc
> https://github.com/doonhammer/networking-ovn
> https://github.com/doonhammer/ovs
>
> The next tasks I see are:
>
> 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> will pass a nested port-chain dictionary holding port-pairs/port-
> pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> 2. Align the interface between networking-ovn and ovs/ovn to match
> the nested dictionary in 1.
> 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.
> 4. Add ability to support chain of port-pairs
> 5. Think about flow-classifiers and how best to map them, today I
> just map the logical-port and ignore everything else.
>
> Any other suggestions/feedback?
>
> Regards
>
> John

John-

(Sorry for sending this twice, but I forgot that text/html is not liked
by the mailing lists ...)

My apologies for not answering this sooner - I was giving a two day
training on Tues/Wed last week and came back to my son graduating
from HS the next day, so things have been a bit of a whirlwind here.

Looking at the github repos, I like the idea of passing a dictionary
from networking-sfc to networking-ovn. The flow classifiers should
be relatively straightforward to map to ovs match rules (famous last
words)...

I've probably missed an orbit here, but in the ovn-northd implementation,
I was expecting to find service chains in the egress and router pipelines
in addition to the ingress pipeline (see below for why I think a service
chain stage in the egress pipeline makes sense ...)

Also, in the ovn-northd implementation, I'm a little disturbed to see the
ingress side of the service chain sending packets to output ports - I
think that a more scalable (and more "ovs-like" approach) would be to
match the egress side of a port pair in the chaining stage of the
ingress pipeline, with an action that  set the input port register.
Then the egress pipeline would have a chaining stage where the output
port register would be set based on the ingress port of the next port
pair in the chain and the packet being punted to the proper output port
in the last table.  That should automagically build your function chain
and provide the basis for 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/18/2016 03:55:14
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/18/2016 03:55 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> OK all three repos and now aligned with their masters. I have done
> some simple level system tests and I can steer traffic to a single
> VNF.  Note: some additional changes to networking-sfc to catch-up
> with their changes.
>
> https://github.com/doonhammer/networking-sfc
> https://github.com/doonhammer/networking-ovn
> https://github.com/doonhammer/ovs
>
> The next tasks I see are:
>
> 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> will pass a nested port-chain dictionary holding port-pairs/port-
> pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> 2. Align the interface between networking-ovn and ovs/ovn to match
> the nested dictionary in 1.
> 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain
model.
> 4. Add ability to support chain of port-pairs
> 5. Think about flow-classifiers and how best to map them, today I
> just map the logical-port and ignore everything else.
>
> Any other suggestions/feedback?
>
> Regards
>
> John

John-

(Sorry for sending this twice, but I forgot that text/html is not liked
by the mailing lists ...)

My apologies for not answering this sooner - I was giving a two day
training on Tues/Wed last week and came back to my son graduating
from HS the next day, so things have been a bit of a whirlwind here.

Looking at the github repos, I like the idea of passing a dictionary
from networking-sfc to networking-ovn. The flow classifiers should
be relatively straightforward to map to ovs match rules (famous last
words)...

I've probably missed an orbit here, but in the ovn-northd implementation,
I was expecting to find service chains in the egress and router pipelines
in addition to the ingress pipeline (see below for why I think a service
chain stage in the egress pipeline makes sense ...)

Also, in the ovn-northd implementation, I'm a little disturbed to see the
ingress side of the service chain sending packets to output ports - I
think that a more scalable (and more "ovs-like" approach) would be to
match the egress side of a port pair in the chaining stage of the
ingress pipeline, with an action that  set the input port register.
Then the egress pipeline would have a chaining stage where the output
port register would be set based on the ingress port of the next port
pair in the chain and the packet being punted to the proper output port
in the last table.  That should automagically build your function chain
and provide the basis for bucketizing multiple ingress ports for the
next port group to support hash based load balancing.

Does that make sense?

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John-
 
My apologies for not answering this sooner - I was giving a two day training on Tues/Wed last week and came back to my son graduating from HS the next day, so thiings have been a bit of a whirlwind here.
 
Looking at the github repos, I like the idea of passing a dictionary from networking-sfc to networking-ovn.  The flow classifiers should be relatively straightforward to map to ovs match rules (famous last words)...
 
I've probably missed an orbit here, but in the ovn-northd implementation, I was expecting to find service chains in the egress and router pipelines in addition to the ingress pipeline (see below for why I think a service chain stage in the egress pipeline makes sense ...)
 
Also, in the ovn-northd implementation, I'm a little disturbed to see the ingress side of the service chain sending packets to output ports - I think that a more
scalable (and more "ovs" approach) would be to match the egress side of a port pair in the chaining stage of the ingress pipeline, with an action that  set the input port register.  Then the egress pipeline would have a chaining stage where the output port register would be set based on the ingress port of the next port pair in the chain and the packet being punted to the proper output port in the last table.  That should automagically build your function chain and provider the bases for bucketizing multiple ingress ports for the next port group to support hash based load balancing.
 
Does that make sense?
 
Ryan
 
- Original message -From: John McDowall <jmcdow...@paloaltonetworks.com>To: Ryan Moats/Omaha/IBM@IBMUSCc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack Development Mailing List" <openstack-dev@lists.openstack.org>Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVNDate: Wed, May 18, 2016 3:55 PM 
Ryan,
 
OK all three repos and now aligned with their masters. I have done some simple level system tests and I can steer traffic to a single VNF.  Note: some additional changes to networking-sfc to catch-up with their changes.
 
https://github.com/doonhammer/networking-sfc 
https://github.com/doonhammer/networking-ovn
https://github.com/doonhammer/ovs 
 
The next tasks I see are:
 
 
Decouple networking-sfc and networking-ovn. I am thinking that I will pass a nested port-chain dictionary holding port-pairs/port-pair-groups/flow-classifiers from networking-sfc to networking-ovn.Align the interface between networking-ovn and ovs/ovn to match the nested dictionary in 1.Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.Add ability to support chain of port-pairsThink about flow-classifiers and how best to map them, today I just map the logical-port and ignore everything else.
 
Any other suggestions/feedback?
 
Regards
 
John
  
From: Ryan Moats <rmo...@us.ibm.com>Date: Wednesday, May 11, 2016 at 1:39 PMTo: John McDowall <jmcdow...@paloaltonetworks.com>Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN 
  
John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 12:37:40 PM:> From: John McDowall <jmcdow...@paloaltonetworks.com>> To: Ryan Moats/Omaha/IBM@IBMUS> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack> Development Mailing List" <openstack-dev@lists.openstack.org>> Date: 05/11/2016 12:37 PM> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN>> Ryan,>> I have done networking-sfc the files that I see as changed/added are:>> devstack/settings   Modified Runtime setting to pick up OVN Driver> networking_sfc/db/migration/alembic_migrations/versions/mitaka/> expand/5a475fc853e6_ovs_data_model.py Hack to work around> flow_classifier issue – need to resolve with SFC team.> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN Driver> networking_sfc/services/sfc/drivers/ovn/driver.py     Added ovn driver file> setup.cfg Inserted OVN driver entry>> I am currently working to clean up ovs/ovn.>> Regards>> JohnI can confirm that the networking-sfc rebase goes in clean againstmaster for me :) - Looking forward to ovs ...Ryan 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

OK all three repos and now aligned with their masters. I have done some simple 
level system tests and I can steer traffic to a single VNF.  Note: some 
additional changes to networking-sfc to catch-up with their changes.

https://github.com/doonhammer/networking-sfc
https://github.com/doonhammer/networking-ovn
https://github.com/doonhammer/ovs

The next tasks I see are:



  1.  Decouple networking-sfc and networking-ovn. I am thinking that I will 
pass a nested port-chain dictionary holding 
port-pairs/port-pair-groups/flow-classifiers from networking-sfc to 
networking-ovn.
  2.  Align the interface between networking-ovn and ovs/ovn to match the 
nested dictionary in 1.
  3.  Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.
  4.  Add ability to support chain of port-pairs
  5.  Think about flow-classifiers and how best to map them, today I just map 
the logical-port and ignore everything else.

Any other suggestions/feedback?

Regards

John

From: Ryan Moats >
Date: Wednesday, May 11, 2016 at 1:39 PM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/11/2016 12:37:40 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/11/2016 12:37 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> I have done networking-sfc the files that I see as changed/added are:
>
> devstack/settings   Modified Runtime setting to pick up OVN Driver
> networking_sfc/db/migration/alembic_migrations/versions/mitaka/
> expand/5a475fc853e6_ovs_data_model.py Hack to work around
> flow_classifier issue - need to resolve with SFC team.
> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN Driver
> networking_sfc/services/sfc/drivers/ovn/driver.py Added ovn driver file
> setup.cfg Inserted OVN driver entry
>
> I am currently working to clean up ovs/ovn.
>
> Regards
>
> John

I can confirm that the networking-sfc rebase goes in clean against
master for me :) - Looking forward to ovs ...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/11/2016 12:37:40
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/11/2016 12:37 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> I have done networking-sfc the files that I see as changed/added are:
>
> devstack/settings   Modified Runtime setting to pick up OVN Driver
> networking_sfc/db/migration/alembic_migrations/versions/mitaka/
> expand/5a475fc853e6_ovs_data_model.py Hack to work around
> flow_classifier issue – need to resolve with SFC team.
> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN
Driver
> networking_sfc/services/sfc/drivers/ovn/driver.py Added ovn driver
file
> setup.cfg Inserted OVN driver entry
>
> I am currently working to clean up ovs/ovn.
>
> Regards
>
> John

I can confirm that the networking-sfc rebase goes in clean against
master for me :) - Looking forward to ovs ...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/11/2016 12:37:40
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/11/2016 12:37 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> I have done networking-sfc the files that I see as changed/added are:
>
> devstack/settings   Modified Runtime setting to pick up OVN Driver
> networking_sfc/db/migration/alembic_migrations/versions/mitaka/
> expand/5a475fc853e6_ovs_data_model.py Hack to work around
> flow_classifier issue – need to resolve with SFC team.
> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN
Driver
> networking_sfc/services/sfc/drivers/ovn/driver.py Added ovn driver
file
> setup.cfg Inserted OVN driver entry
>

Ack... I'll run throug those changes either later today or tomorrow
morning...

Thanks,
Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/11/2016 12:06:55
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/11/2016 12:07 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Looks good apart from:
>
> networking_ovn/common/extensions.py
>
> There should be no changes to that file, I removed them as they are
> from an older prototype.
>
> Regards
>
> John

Ah, ok, I must of missed that when rolling through the patch series -
I've updated my copy.

Are you tackling networking-sfc or ovs next?

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Looks good apart from:

networking_ovn/common/extensions.py

There should be no changes to that file, I removed them as they are from an 
older prototype.

Regards

John

From: Ryan Moats >
Date: Wednesday, May 11, 2016 at 9:59 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/11/2016 11:30:07 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/11/2016 11:30 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Apologies for missing the _init_.py files – removed them and
> remerged. When I do a compare from my repo to main I see three files
> changed (which I think is correct):
>
> networking_ovn/ovsdb/commands.py
> networking_ovn/ovsdb/impl_idl_ovn.py
> networking_ovn/ovsdb/ovn_api.py
>
> I could be doing something wrong as not an expert at merging repos.
> If I am doing something wrong let me know and I will fix it.
>
> Regards
>
> John

So the change I made to common/extensions.py was to avoid a merge
conflict, and I double checked and yes, the changes I had to
plugin.py are spurious, so here is an updated/corrected patch for
you to check against:

>From eb93dc3984145f1b82be15d204c2f0790c1429bd Mon Sep 17 00:00:00 2001
From: RYAN D. MOATS >
Date: Wed, 11 May 2016 09:10:18 -0500
Subject: [PATCH] test

Signed-off-by: RYAN D. MOATS >
---
networking_ovn/common/extensions.py  |1 +
networking_ovn/ovsdb/commands.py |   78 ++
networking_ovn/ovsdb/impl_idl_ovn.py |   18 
networking_ovn/ovsdb/ovn_api.py  |   49 +
4 files changed, 146 insertions(+), 0 deletions(-)

diff --git a/networking_ovn/common/extensions.py 
b/networking_ovn/common/extensions.py
index c171e11..55fc147 100644
--- a/networking_ovn/common/extensions.py
+++ b/networking_ovn/common/extensions.py
@@ -37,4 +37,5 @@ SUPPORTED_API_EXTENSIONS = [
'subnet_allocation',
'port-security',
'allowed-address-pairs',
+'sfi',
]
diff --git a/networking_ovn/ovsdb/commands.py b/networking_ovn/ovsdb/commands.py
index 7ea7a6f..68a747f 100644
--- a/networking_ovn/ovsdb/commands.py
+++ b/networking_ovn/ovsdb/commands.py
@@ -164,6 +164,84 @@ class DelLogicalPortCommand(BaseCommand):
setattr(lswitch, 'ports', ports)
self.api._tables['Logical_Port'].rows[lport.uuid].delete()

+class AddLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, lswitch, may_exist, **columns):
+super(AddLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.lswitch = lswitch
+self.may_exist = may_exist
+self.columns = columns
+
+def run_idl(self, txn):
+try:
+lswitch = idlutils.row_by_value(self.api.idl, 'Logical_Switch',
+'name', self.lswitch)
+services= getattr(lswitch, 'services', [])
+except idlutils.RowNotFound:
+msg = _("Logical Switch %s does not exist") % self.lswitch
+raise RuntimeError(msg)
+if self.may_exist:
+service = idlutils.row_by_value(self.api.idl,
+ 'Logical_Service', 'name',
+ self.lservice, None)
+if service:
+return
+
+lswitch.verify('services')
+
+service = txn.insert(self.api._tables['Logical_Service'])
+service.name = self.lservice
+for col, val in self.columns.items():
+setattr(service, col, val)
+# add the newly created service to existing lswitch
+services.append(service.uuid)
+setattr(lswitch, 'services', services)
+
+class SetLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, if_exists, **columns):
+super(SetLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.columns = columns
+self.if_exists = if_exists
+
+def run_idl(self, txn):
+try:
+service = idlutils.row_by_value(self.api.idl, 'Logical_Service',
+

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/11/2016 11:30:07
AM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/11/2016 11:30 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Apologies for missing the _init_.py files – removed them and
> remerged. When I do a compare from my repo to main I see three files
> changed (which I think is correct):
>
> networking_ovn/ovsdb/commands.py
> networking_ovn/ovsdb/impl_idl_ovn.py
> networking_ovn/ovsdb/ovn_api.py
>
> I could be doing something wrong as not an expert at merging repos.
> If I am doing something wrong let me know and I will fix it.
>
> Regards
>
> John

So the change I made to common/extensions.py was to avoid a merge
conflict, and I double checked and yes, the changes I had to
plugin.py are spurious, so here is an updated/corrected patch for
you to check against:

From eb93dc3984145f1b82be15d204c2f0790c1429bd Mon Sep 17 00:00:00 2001
From: RYAN D. MOATS 
Date: Wed, 11 May 2016 09:10:18 -0500
Subject: [PATCH] test

Signed-off-by: RYAN D. MOATS 
---
 networking_ovn/common/extensions.py  |1 +
 networking_ovn/ovsdb/commands.py |   78 ++
 networking_ovn/ovsdb/impl_idl_ovn.py |   18 
 networking_ovn/ovsdb/ovn_api.py  |   49 +
 4 files changed, 146 insertions(+), 0 deletions(-)

diff --git a/networking_ovn/common/extensions.py 
b/networking_ovn/common/extensions.py
index c171e11..55fc147 100644
--- a/networking_ovn/common/extensions.py
+++ b/networking_ovn/common/extensions.py
@@ -37,4 +37,5 @@ SUPPORTED_API_EXTENSIONS = [
 'subnet_allocation',
 'port-security',
 'allowed-address-pairs',
+'sfi',
 ]
diff --git a/networking_ovn/ovsdb/commands.py b/networking_ovn/ovsdb/commands.py
index 7ea7a6f..68a747f 100644
--- a/networking_ovn/ovsdb/commands.py
+++ b/networking_ovn/ovsdb/commands.py
@@ -164,6 +164,84 @@ class DelLogicalPortCommand(BaseCommand):
 setattr(lswitch, 'ports', ports)
 self.api._tables['Logical_Port'].rows[lport.uuid].delete()

+class AddLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, lswitch, may_exist, **columns):
+super(AddLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.lswitch = lswitch
+self.may_exist = may_exist
+self.columns = columns
+
+def run_idl(self, txn):
+try:
+lswitch = idlutils.row_by_value(self.api.idl, 'Logical_Switch',
+'name', self.lswitch)
+services= getattr(lswitch, 'services', [])
+except idlutils.RowNotFound:
+msg = _("Logical Switch %s does not exist") % self.lswitch
+raise RuntimeError(msg)
+if self.may_exist:
+service = idlutils.row_by_value(self.api.idl,
+ 'Logical_Service', 'name',
+ self.lservice, None)
+if service:
+return
+
+lswitch.verify('services')
+
+service = txn.insert(self.api._tables['Logical_Service'])
+service.name = self.lservice
+for col, val in self.columns.items():
+setattr(service, col, val)
+# add the newly created service to existing lswitch
+services.append(service.uuid)
+setattr(lswitch, 'services', services)
+
+class SetLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, if_exists, **columns):
+super(SetLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.columns = columns
+self.if_exists = if_exists
+
+def run_idl(self, txn):
+try:
+service = idlutils.row_by_value(self.api.idl, 'Logical_Service',
+'name', self.lservice)
+except idlutils.RowNotFound:
+if self.if_exists:
+return
+msg = _("Logical Service %s does not exist") % self.lservice
+raise RuntimeError(msg)
+
+for col, val in self.columns.items():
+setattr(service, col, val)
+
+class DelLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, lswitch, if_exists):
+super(DelLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.lswitch = lswitch
+self.if_exists = if_exists
+
+def run_idl(self, txn):
+try:
+lservice = idlutils.row_by_value(self.api.idl, 'Logical_Service',
+ 'name', self.lservice)
+lswitch = idlutils.row_by_value(self.api.idl, 'Logical_Switch',
+

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Apologies for missing the _init_.py files – removed them and remerged. When I 
do a compare from my repo to main I see three files changed (which I think is 
correct):

networking_ovn/ovsdb/commands.py
networking_ovn/ovsdb/impl_idl_ovn.py
networking_ovn/ovsdb/ovn_api.py

I could be doing something wrong as not an expert at merging repos. If I am 
doing something wrong let me know and I will fix it.

Regards

John

From: Ryan Moats >
Date: Wednesday, May 11, 2016 at 7:12 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/10/2016 11:11:57 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/10/2016 11:12 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Let me do that – I assume adding them to plugin.py is the right approach.
>
> I have cleaned up 
> https://github.com/doonhammer/networking-ovn
>  and
> did a merge so it should be a lot easier to see the changes. I am
> going to cleanup ovs/ovn next. Once I have everything cleaned up and
> make sure it is still working I will move the code over to the port-
> pair/port-chain model.
>
> Let me know if that works for you.
>
> Regards
>
> John
>
> From: Ryan Moats >
> Date: Tuesday, May 10, 2016 at 7:38 AM
> To: John McDowall 
> >
> Cc: "disc...@openvswitch.org" 
> >, OpenStack
> Development Mailing List 
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/09/2016
> 10:46:41 AM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > >, "OpenStack
> > Development Mailing List" 
> > >
> > Date: 05/09/2016 10:46 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks – let me try and get the code cleaned up and rebased. One
> > area that I could use your insight on is the interface to
> > networking-ovn and how it should look.
> >
> > Regards
> >
> > John
>
> Looking at this, the initial code that I think should move over are
> _create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
> create_vnf and delete_vnf.
>
> What I haven't figured out at this point is:
> 1) Is the above enough?
> 2) Do we need to refactor some of OVNPlugin's calls to provide hooks
> for the SFC
>driver to use for when the OVNPlugin inheritance goes away.
>
> Ryan

I like the idea, but unfortunately, I'm still not able to apply the series
cleanly to openstack:master:
- the list of supported extensions has moved from plugin.py to
  commons/extensions.py
- the patches that create extensions/__init__.py and
  networking_ovn/db/migration/__init__.py complain of garbage
- the patch that adds Logging on fixed ips doesn't align with the new
  code structure for handling same
- the patch that removes experimental code also has a whole lot of
  changes that were part of the master devstack/plugin.sh and so
  confuses patch.  Worse, almost 90% of the changes to plugin.py fail
  because of the same commingling.

After walking through all the patches, I'm still seeing what looks like
some cruft: I'm not sure what networking_ovn/db/migration
and networking_ovn/extensions are doing anymore, as they only have
__init__.py files in them.

Even with that, I *think* the following patch below all the changes against
tip of the tree master...

Ryan

---

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/10/2016 11:11:57
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/10/2016 11:12 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Let me do that – I assume adding them to plugin.py is the right approach.
>
> I have cleaned up https://github.com/doonhammer/networking-ovn and
> did a merge so it should be a lot easier to see the changes. I am
> going to cleanup ovs/ovn next. Once I have everything cleaned up and
> make sure it is still working I will move the code over to the port-
> pair/port-chain model.
>
> Let me know if that works for you.
>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Tuesday, May 10, 2016 at 7:38 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/09/2016
> 10:46:41 AM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/09/2016 10:46 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks – let me try and get the code cleaned up and rebased. One
> > area that I could use your insight on is the interface to
> > networking-ovn and how it should look.
> >
> > Regards
> >
> > John
>
> Looking at this, the initial code that I think should move over are
> _create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
> create_vnf and delete_vnf.
>
> What I haven't figured out at this point is:
> 1) Is the above enough?
> 2) Do we need to refactor some of OVNPlugin's calls to provide hooks
> for the SFC
>driver to use for when the OVNPlugin inheritance goes away.
>
> Ryan

I like the idea, but unfortunately, I'm still not able to apply the series
cleanly to openstack:master:
- the list of supported extensions has moved from plugin.py to
  commons/extensions.py
- the patches that create extensions/__init__.py and
  networking_ovn/db/migration/__init__.py complain of garbage
- the patch that adds Logging on fixed ips doesn't align with the new
  code structure for handling same
- the patch that removes experimental code also has a whole lot of
  changes that were part of the master devstack/plugin.sh and so
  confuses patch.  Worse, almost 90% of the changes to plugin.py fail
  because of the same commingling.

After walking through all the patches, I'm still seeing what looks like
some cruft: I'm not sure what networking_ovn/db/migration
and networking_ovn/extensions are doing anymore, as they only have
__init__.py files in them.

Even with that, I *think* the following patch below all the changes against
tip of the tree master...

Ryan

---
 networking_ovn/common/extensions.py |1 +
 networking_ovn/ovsdb/commands.py|   78 +++
 networking_ovn/ovsdb/impl_idl_ovn.py|   18 +++
 networking_ovn/ovsdb/ovn_api.py |   49 +++
 networking_ovn/plugin.py|   71 
 5 files changed, 217 insertions(+), 0 deletions(-)
 create mode 100644 networking_ovn/db/migration/__init__.py
 create mode 100644 networking_ovn/extensions/__init__.py

diff --git a/networking_ovn/common/extensions.py 
b/networking_ovn/common/extensions.py
index c171e11..55fc147 100644
--- a/networking_ovn/common/extensions.py
+++ b/networking_ovn/common/extensions.py
@@ -37,4 +37,5 @@ SUPPORTED_API_EXTENSIONS = [
 'subnet_allocation',
 'port-security',
 'allowed-address-pairs',
+'sfi',
 ]
diff --git a/networking_ovn/db/migration/__init__.py 
b/networking_ovn/db/migration/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/networking_ovn/extensions/__init__.py 
b/networking_ovn/extensions/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/networking_ovn/ovsdb/commands.py b/networking_ovn/ovsdb/commands.py
index 7ea7a6f..68a747f 100644
--- a/networking_ovn/ovsdb/commands.py
+++ b/networking_ovn/ovsdb/commands.py
@@ -164,6 +164,84 @@ class DelLogicalPortCommand(BaseCommand):
 setattr(lswitch, 'ports', ports)
 self.api

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Let me do that - I assume adding them to plugin.py is the right approach.

I have cleaned up https://github.com/doonhammer/networking-ovn and did a merge 
so it should be a lot easier to see the changes. I am going to cleanup ovs/ovn 
next. Once I have everything cleaned up and make sure it is still working I 
will move the code over to the port-pair/port-chain model.

Let me know if that works for you.

Regards

John

From: Ryan Moats >
Date: Tuesday, May 10, 2016 at 7:38 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/09/2016 10:46:41 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/09/2016 10:46 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks - let me try and get the code cleaned up and rebased. One
> area that I could use your insight on is the interface to
> networking-ovn and how it should look.
>
> Regards
>
> John

Looking at this, the initial code that I think should move over are
_create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
create_vnf and delete_vnf.

What I haven't figured out at this point is:
1) Is the above enough?
2) Do we need to refactor some of OVNPlugin's calls to provide hooks for the SFC
   driver to use for when the OVNPlugin inheritance goes away.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/09/2016 10:46:41
AM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" , "OpenStack
> Development Mailing List" 
> Date: 05/09/2016 10:46 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks – let me try and get the code cleaned up and rebased. One
> area that I could use your insight on is the interface to
> networking-ovn and how it should look.
>
> Regards
>
> John

Looking at this, the initial code that I think should move over are
_create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
create_vnf and delete_vnf.

What I haven't figured out at this point is:
1) Is the above enough?
2) Do we need to refactor some of OVNPlugin's calls to provide hooks for
the SFC
   driver to use for when the OVNPlugin inheritance goes away.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Thanks - let me try and get the code cleaned up and rebased. One area that I 
could use your insight on is the interface to networking-ovn and how it should 
look.

Regards

John

From: Ryan Moats >
Date: Sunday, May 8, 2016 at 8:32 PM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/08/2016 07:34:52 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >
> Date: 05/08/2016 07:35 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Correcting ovs address
>
> Ryan,
>
> Thanks for taking a look at these  - really appreciate it. I will
> work on the rebasing this week and get everything current. At the
> same time I can get rid of some excess code as I went through a few
> iterations to get to this point. There are still a lot of
> unaddressed edge conditions and details that need to be thought
> through and addressed - but once we reach consensus on the approach
> we can start to address them.
>
> Thinking though the various repos in reverse order.
>
> OVS
> ===
>
> I would like to change the code to follow the model that Russell
> Bryant did in his patches see:  
> https://github.com/russellb/ovs/
> commits/chaining
>
> They have several advantages:
> 1. Creates a new table for chaining which should help isolate the
> code and make chaining more "atomic"
> 2. He follows the port-pair/port-chain model of SFC so integration
> should be cleaner
> 3. Following the port-pair/port-chain model makes extending the
> solution to handle a chain of VNFs fairly easy.
> If everyone is good with this I can work this into the patches and rebase.

You are anticipating where I was looking to go, so I'm on board with
this idea.

> Networking-OVN
> ===
>
> There is some old code here in plugin.py that I think comes out.
> When I added OVN as a SFC Driver there was a lot of code that I
> added to  networking-ovn that became obsolete. The IDL code would be
> modified to follow the port-pair/port-chain. model.  The biggest
> question I have from your comments is the interface between the
> networking-sfc and networking-ovn. I think I agree with you that
> networking-ovn should expose an interface that is called by
> networking-sfc and that would remove the need to subclass OVNPlugin
> in the networking-sfc OVN driver. Is that what you were intending?

Yes, I was looking at how that subclass could be avoided.

> Networking-SFC
> ==
>
> If we follow Russell's model in OVN/OVS then there very close
> alignment with the SFC model and the code will become simpler. Also
> removing the OVNPlugin dependency will also clean things up.

Yes, I was hoping that would be a side effect as well...

I like all of your proposed ideas and am looking forward to seeing
the next iteration. Please feel free to reach out if you need
another pair of hands to help with coding...

Ryan Moats
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall  wrote on 05/08/2016 07:34:52
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> Date: 05/08/2016 07:35 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Correcting ovs address
>
> Ryan,
>
> Thanks for taking a look at these  - really appreciate it. I will
> work on the rebasing this week and get everything current. At the
> same time I can get rid of some excess code as I went through a few
> iterations to get to this point. There are still a lot of
> unaddressed edge conditions and details that need to be thought
> through and addressed – but once we reach consensus on the approach
> we can start to address them.
>
> Thinking though the various repos in reverse order.
>
> OVS
> ===
>
> I would like to change the code to follow the model that Russell
> Bryant did in his patches see:  https://github.com/russellb/ovs/
> commits/chaining
>
> They have several advantages:
> 1. Creates a new table for chaining which should help isolate the
> code and make chaining more “atomic”
> 2. He follows the port-pair/port-chain model of SFC so integration
> should be cleaner
> 3. Following the port-pair/port-chain model makes extending the
> solution to handle a chain of VNFs fairly easy.
> If everyone is good with this I can work this into the patches and
rebase.

You are anticipating where I was looking to go, so I'm on board with
this idea.

> Networking-OVN
> ===
>
> There is some old code here in plugin.py that I think comes out.
> When I added OVN as a SFC Driver there was a lot of code that I
> added to  networking-ovn that became obsolete. The IDL code would be
> modified to follow the port-pair/port-chain. model.  The biggest
> question I have from your comments is the interface between the
> networking-sfc and networking-ovn. I think I agree with you that
> networking-ovn should expose an interface that is called by
> networking-sfc and that would remove the need to subclass OVNPlugin
> in the networking-sfc OVN driver. Is that what you were intending?

Yes, I was looking at how that subclass could be avoided.

> Networking-SFC
> ==
>
> If we follow Russell’s model in OVN/OVS then there very close
> alignment with the SFC model and the code will become simpler. Also
> removing the OVNPlugin dependency will also clean things up.

Yes, I was hoping that would be a side effect as well...

I like all of your proposed ideas and am looking forward to seeing
the next iteration. Please feel free to reach out if you need
another pair of hands to help with coding...

Ryan Moats
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Thanks for taking a look at these  - really appreciate it. I will work on the 
rebasing this week and get everything current. At the same time I can get rid 
of some excess code as I went through a few iterations to get to this point. 
There are still a lot of unaddressed edge conditions and details that need to 
be thought through and addressed – but once we reach consensus on the approach 
we can start to address them.

Thinking though the various repos in reverse order.

OVS
===

I would like to change the code to follow the model that Russell Bryant did in 
his patches see:  https://github.com/russellb/ovs/commits/chaining

They have several advantages:

  1.  Creates a new table for chaining which should help isolate the code and 
make chaining more “atomic”
  2.  He follows the port-pair/port-chain model of SFC so integration should be 
cleaner
  3.  Following the port-pair/port-chain model makes extending the solution to 
handle a chain of VNFs fairly easy.

If everyone is good with this I can work this into the patches and rebase.

Networking-OVN
===

There is some old code here in plugin.py that I think comes out. When I added 
OVN as a SFC Driver there was a lot of code that I added to  networking-ovn 
that became obsolete. The IDL code would be modified to follow the 
port-pair/port-chain. model.  The biggest question I have from your comments is 
the interface between the networking-sfc and networking-ovn. I think I agree 
with you that networking-ovn should expose an interface that is called by 
networking-sfc and that would remove the need to subclass OVNPlugin in the 
networking-sfc OVN driver. Is that what you were intending?

Networking-SFC
==

If we follow Russell’s model in OVN/OVS then there very close alignment with 
the SFC model and the code will become simpler. Also removing the OVNPlugin 
dependency will also clean things up.


Regards

John



From: Ryan Moats >
Date: Sunday, May 8, 2016 at 11:23 AM
To: John McDowall 
>
Cc: "disc...@openvswtich.org" 
>, 
"openstack-dev@lists.openstack.org" 
>
Subject: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


First, apologies for the cross-posting, but when this topic came up last week,
I wasn't able to keep track of all the folks that asked to be included in the 
email,
so I'm doing a mass post to try and catch everybody that might be interested.

Second, John, thank you for stepping forward and mentioning that you've been
working on code for SFC and OVN!!  I took a look at your repos on github.com
(because I'm a firm believe in NOT re-inventing the wheel) and my initial
comments follow...

Networking-SFC 
(https://github.com/doonhammer/networking-sfc)
=

This repo is the cleanest, as I was able to merge the current networking-sfc
master on top of it with no conflicts.  Looking around, I'm not entirely
comfortable with the idea of networking-sfc making direct calls to the OVN IDL
in parallel to networking-ovn.  I believe a cleaner solution would be to
add the code to configure OVN for SFC to networking-ovn itself, and expose an
API that the driver code in networking-sfc would call.

Networking-OVN 
(https://github.com/doonhammer/networking-ovn)
=

This repo makes me a bit nervous, as it claims to be 36 commits ahead
(and 129 commits behind) openstack-master.  That's a substantial drift, and
the first thing I wanted to do was see what merge conflicts might exist when
I try to merge the current master into it.  There are two merge conflicts
detected in networking_ovn/plugin.py, and given (as I understand it) the
direction of splitting the networking-ovn monolithic plugin back into ML2
and L3 service portions, I encourage you to rebase this commit (if you don't
have time, let me know and I'll see about fixing the merge issue).

OVS 

[openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

First, apologies for the cross-posting, but when this topic came up last
week,
I wasn't able to keep track of all the folks that asked to be included in
the email,
so I'm doing a mass post to try and catch everybody that might be
interested.

Second, John, thank you for stepping forward and mentioning that you've
been
working on code for SFC and OVN!!  I took a look at your repos on
github.com
(because I'm a firm believe in NOT re-inventing the wheel) and my initial
comments follow...

Networking-SFC (https://github.com/doonhammer/networking-sfc)
=

This repo is the cleanest, as I was able to merge the current
networking-sfc
master on top of it with no conflicts.  Looking around, I'm not entirely
comfortable with the idea of networking-sfc making direct calls to the OVN
IDL
in parallel to networking-ovn.  I believe a cleaner solution would be to
add the code to configure OVN for SFC to networking-ovn itself, and expose
an
API that the driver code in networking-sfc would call.

Networking-OVN (https://github.com/doonhammer/networking-ovn)
=

This repo makes me a bit nervous, as it claims to be 36 commits ahead
(and 129 commits behind) openstack-master.  That's a substantial drift, and
the first thing I wanted to do was see what merge conflicts might exist
when
I try to merge the current master into it.  There are two merge conflicts
detected in networking_ovn/plugin.py, and given (as I understand it) the
direction of splitting the networking-ovn monolithic plugin back into ML2
and L3 service portions, I encourage you to rebase this commit (if you
don't
have time, let me know and I'll see about fixing the merge issue).

OVS (https://github.com/doonhammer/ovs)
===

This repo also has some drift (in that it is 21 comits ahead and 406
commits
behind openvswitch master).  The merge conflicts I've found here are in
ovn/ovn-nb.ovsschema and ovn/northd/ovn-northd.c.  The ovsschema conflict
looks like it can be resolved by bumping the micro version of the current
master
and recalculating/inserting the schema checksum.  On the other hand, the
conflicts in ovn-northd.c are a bit more numerous (I count 22 of them as I
write
this).  I'm not sure what the easiest way is to get this rebased onto the
current tip of tree master...

The reason I'm interested in the rebasing exercises is I want to get to a
set
of patches that can be publically committed, at which point I (wearing my
operator hat) can evaluate them to see if they meet our needs for SFC.  If
you
need help with the rebasing, I'm happy to work with you...

Ryan Moats (regXboi on IRC, jayhawk87 on github)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev