John,
 Work is currently in progress on a OVN LB that specifies a 
VIP to distribute load to a set of IP addresses:

ovn-nbctl  create load_balancer 
vips:30.0.0.1="172.16.1.2,172.16.1.3,172.16.1.4"`

http://openvswitch.org/pipermail/dev/2016-February/066959.html

What is needed to an OVN LB that would distribute load over
a set of Logical Ports. This would be implemented using the 
OVS group in a similar manner to that described in that patch.
 
 - Louis

-----Original Message-----
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of John McDowall
Sent: Sunday, July 17, 2016 9:23 PM
To: Ryan Moats
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] SFC: How about stages in both pipelines?

Ryan,

We see this use case a lot - essentially a FW between logical network segments, 
and one could be the internet. It is not so much a chain but a link in a chain 
:-0. The complexity is using load-balancers to scale the firewall to support 
the scale of the application load. Which ends up looking a like this (excuse my 
ascii art).

                                                                              | 
- App
                                |--FW -- |                     | - App
Internet -> LB1--  |--FW ---  |- LB2----  | - App
                               |--FW -- |                      | - App
                                                                              | 
- App


Now if OSVS/OVN can do the load balancing the picture  becomes simpler and more 
interesting.

Thoughts?

j
From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>>
Date: Sunday, July 17, 2016 at 7:02 PM
To: John McDowall 
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>" 
<dev@openvswitch.org<mailto:dev@openvswitch.org>>
Subject: Re: SFC: How about stages in both pipelines?


John McDowall 
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote 
on 07/17/2016 08:18:48 PM:

> From: John McDowall 
> <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>" 
> <dev@openvswitch.org<mailto:dev@openvswitch.org>>
> Date: 07/17/2016 08:18 PM
> Subject: Re: SFC: How about stages in both pipelines?
>
> Ryan,
>
> I assume you are thinking about L3 VNF support?
>
> If so yes I need to think this through - any ideas would be 
> appreciated
>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>>
> Date: Sunday, July 17, 2016 at 6:15 PM
> To: John McDowall 
> <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>
> >
> Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>" 
> <dev@openvswitch.org<mailto:dev@openvswitch.org>>
> Subject: SFC: How about stages in both pipelines?
>
> John-
>
> To date, I think we've talked about adding an SFC stage to the ingress 
> pipeline for logical switch datapaths and how to enable that via 
> OpenStack/Neutron. Since OVN doesn't have to assume OpenStack as the 
> CMS, I think we should also be adding that stage to the ingress 
> pipeline of the logical router datapath.
>
>
> Ryan

I don't think I'm talking about L3 VNF support (at least not that way I've 
heard the term used previously).

Rather, I'm thinking of how I might support VNFs that work at network edges or 
boundaries (for example, an IDS/IPS for traffic from the Internet).  Since such 
VNFs would be looking at inter-network traffic only, I don't think it makes 
since to shoehorn them into the logical datapath associated with a logical 
switch as that would require making the ACLs more complex to ensure they don't 
have to handle intra-network traffic.  Since inter-network traffic will pass 
through at least one logical datapath associated with a logical router, I'm 
thinking adding an SFC stage to the logical router's ingress pipeline would 
support this scenario fairly cleanly at the OVN level.

I admit that I've no ideas yet on how to set up networking-sfc to support such 
a scenario, but that doesn't mean we can't add the code to OVN to support it.

Ryan
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to