Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

On Sat, Aug 13, 2016 at 10:02 PM, Ben Pfaff  wrote:

> On Fri, Jul 29, 2016 at 05:28:26PM +, Mickey Spiegel wrote:
> > Could you expand on why priorities in a single stage aren't enough to
> > satisfy the use case?
> >
> > 
> > If two features are configured independently with a mix of
> > prioritized allow and drop rules, then with a single stage, a
> > new set of ACL rules must be produced that achieves the same
> > behavior.  This is sometimes referred to as an "ACL merge"
> > algorithm, for example:
> > http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_
> paper09186a00800c9470.shtml#wp39514
> >
> > In the worst case, for example when the features act on different
> > packet fields (e.g. one on IP address and another on L4 port),
> > the number of rules required can approach
> > (# of ACL1 rules) * (# of ACL2 rules).
> >
> > While it is possible to code up such an algorithm, it adds
> > significant complexity and complicates whichever layer
> > implements the merge algorithm, either OVN or the CMS above.
> >
> > By using multiple independent pipeline stages, all of this
> > software complexity is avoided, achieving the proper result
> > in a simple and straightforward manner.
> >
> > Recent network hardware ASICs tend to have around 8 or 10 ACL
> > stages, though they tend to evaluate these in parallel given
> > all the emphasis on low latency these days.
>
> I guess that, in software, if there's a need for 2 of something, there's
> usually a need for N of it, so I'd tend to prefer that instead of
> hard-coding 2 stages of ACLs, we make N of them available (for perhaps N
> == 8), especially given that you say hardware tends to work that way.
> It's not really more expensive for OVS, and definitely not if only a few
> of them are used.  We might need to expand the number of logical tables,
> since currently there are only 16 ingress tables and 16 egress tables,
> but doubling them to 32 each wouldn't be a big deal.
>

I did try to code the core part of the changes so that more ACL stages
could be easily added in the future, but the code having to do with
definition of the pipeline stages, associated functions, and nbctl is only
coded for 2 stages at the moment. Let me think about the best way to
generalize this.

As far as need and usage, I guess the key question is whether features
such as service function chaining and QoS marking will use generic ACL
stages, or pipeline stages specifically coded for those features?
In hardware switches, those type of features use many of the multiple
ACL stages.

The way I coded the patch, the fixed rules allowing and dropping
certain flows regardless of user-defined ACL rules are duplicated in
each ACL stage. However, I am not sure if those rules are necessary
or make sense if the actions for that pipeline stage are redirect (for SFC)
or QoS marking, rather than allow and drop. I need to think about it.

I have moved on to other things temporarily, will come back to this patch
if/when I have time to work on ACL tests, or if someone else adds ACL
tests.

Mickey


> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Ben Pfaff]

On Fri, Jul 29, 2016 at 05:28:26PM +, Mickey Spiegel wrote:
> Could you expand on why priorities in a single stage aren't enough to
> satisfy the use case?
> 
> 
> If two features are configured independently with a mix of
> prioritized allow and drop rules, then with a single stage, a
> new set of ACL rules must be produced that achieves the same
> behavior.  This is sometimes referred to as an "ACL merge"
> algorithm, for example:
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
> 
> In the worst case, for example when the features act on different
> packet fields (e.g. one on IP address and another on L4 port),
> the number of rules required can approach
> (# of ACL1 rules) * (# of ACL2 rules).
> 
> While it is possible to code up such an algorithm, it adds
> significant complexity and complicates whichever layer
> implements the merge algorithm, either OVN or the CMS above.
> 
> By using multiple independent pipeline stages, all of this
> software complexity is avoided, achieving the proper result
> in a simple and straightforward manner.
> 
> Recent network hardware ASICs tend to have around 8 or 10 ACL
> stages, though they tend to evaluate these in parallel given
> all the emphasis on low latency these days.

I guess that, in software, if there's a need for 2 of something, there's
usually a need for N of it, so I'd tend to prefer that instead of
hard-coding 2 stages of ACLs, we make N of them available (for perhaps N
== 8), especially given that you say hardware tends to work that way.
It's not really more expensive for OVS, and definitely not if only a few
of them are used.  We might need to expand the number of logical tables,
since currently there are only 16 ingress tables and 16 egress tables,
but doubling them to 32 each wouldn't be a big deal.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Darrell Ball]

On Tue, Aug 2, 2016 at 2:38 PM, Mickey Spiegel <mickeys@gmail.com>
wrote:

> On Tue, Aug 2, 2016 at 1:39 PM, Darrell Ball <dlu...@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 12:05 PM, Russell Bryant <russ...@ovn.org> wrote:
>>
>>>
>>>
>>> On Tue, Aug 2, 2016 at 3:02 PM, Darrell Ball <dlu...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <
>>>>>>> mickeys@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <
>>>>>>> emspi...@us.ibm.com>
>>>>>>> > wrote:
>>>>>>> > >
>>>>>>> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
>>>>>>> > >> To: Mickey Spiegel <mickeys@gmail.com>
>>>>>>> > >> From: Russell Bryant
>>>>>>> > >> Sent by: "dev"
>>>>>>> > >> Date: 07/29/2016 10:02AM
>>>>>>> > >> Cc: ovs dev <dev@openvswitch.org>
>>>>>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>>>>>> > >>
>>>>>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>>>>>>> mickeys@gmail.com
>>>>>>> > >
>>>>>>> > >> wrote:
>>>>>>> > >>
>>>>>>> > >>>
>>>>>>> > >>> This patch adds a second logical switch ingress ACL stage, and
>>>>>>> > >>> correspondingly a second logical switch egress ACL stage.  This
>>>>>>> > >>> allows for more than one ACL-based feature to be applied in the
>>>>>>> > >>> ingress and egress logical switch pipelines.  The features
>>>>>>> > >>> driving the different ACL stages may be configured by different
>>>>>>> > >>> users, for example an application deployer managing security
>>>>>>> > >>> groups and a network or security admin configuring network ACLs
>>>>>>> > >>> or firewall rules.
>>>>>>> > >>>
>>>>>>> > >>> Each ACL stage is self contained.  The "action" for the
>>>>>>> > >>> highest-"priority" matching row in an ACL stage determines a
>>>>>>> > >>> packet's treatment.  A separate "action" will be determined in
>>>>>>> > >>> each ACL stage, according to the ACL rules configured for that
>>>>>>> > >>> ACL stage.  The "priority" values are only relevant within the
>>>>>>> > >>> context of an ACL stage.
>>>>>>> > >>>
>>>>>>> > >>> ACL rules that do not specify an ACL stage are applied to the
>>>>>>> > >>> default "acl" stage.
>>>>>>> > >>>
>>>>>>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> Could you expand on why priorities in a single stage aren't
>>>>>>> enough to
>>>>>>> > >> satisfy the use case?
>>>>>>> > >
>>>>>>> > > If two features are configured independently with a mix of
>>>>>>> > > prioritized allow and drop rules, then with a single stage, a
>>>>>>> > > new set of ACL rules must be produced that achieves the same
>>>>>>> > > behavior.  This is sometimes referred to as an "ACL merge"
>>>>>>> > > algorithm, fo

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

On Tue, Aug 2, 2016 at 1:39 PM, Darrell Ball <dlu...@gmail.com> wrote:

>
>
> On Tue, Aug 2, 2016 at 12:05 PM, Russell Bryant <russ...@ovn.org> wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 3:02 PM, Darrell Ball <dlu...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys@gmail.com>
>>> wrote:
>>>
>>>> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org>
>>>>> wrote:
>>>>>
>>>>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <
>>>>>> mickeys@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <
>>>>>> emspi...@us.ibm.com>
>>>>>> > wrote:
>>>>>> > >
>>>>>> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
>>>>>> > >> To: Mickey Spiegel <mickeys@gmail.com>
>>>>>> > >> From: Russell Bryant
>>>>>> > >> Sent by: "dev"
>>>>>> > >> Date: 07/29/2016 10:02AM
>>>>>> > >> Cc: ovs dev <dev@openvswitch.org>
>>>>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>>>>> > >>
>>>>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>>>>>> mickeys@gmail.com
>>>>>> > >
>>>>>> > >> wrote:
>>>>>> > >>
>>>>>> > >>>
>>>>>> > >>> This patch adds a second logical switch ingress ACL stage, and
>>>>>> > >>> correspondingly a second logical switch egress ACL stage.  This
>>>>>> > >>> allows for more than one ACL-based feature to be applied in the
>>>>>> > >>> ingress and egress logical switch pipelines.  The features
>>>>>> > >>> driving the different ACL stages may be configured by different
>>>>>> > >>> users, for example an application deployer managing security
>>>>>> > >>> groups and a network or security admin configuring network ACLs
>>>>>> > >>> or firewall rules.
>>>>>> > >>>
>>>>>> > >>> Each ACL stage is self contained.  The "action" for the
>>>>>> > >>> highest-"priority" matching row in an ACL stage determines a
>>>>>> > >>> packet's treatment.  A separate "action" will be determined in
>>>>>> > >>> each ACL stage, according to the ACL rules configured for that
>>>>>> > >>> ACL stage.  The "priority" values are only relevant within the
>>>>>> > >>> context of an ACL stage.
>>>>>> > >>>
>>>>>> > >>> ACL rules that do not specify an ACL stage are applied to the
>>>>>> > >>> default "acl" stage.
>>>>>> > >>>
>>>>>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> Could you expand on why priorities in a single stage aren't
>>>>>> enough to
>>>>>> > >> satisfy the use case?
>>>>>> > >
>>>>>> > > If two features are configured independently with a mix of
>>>>>> > > prioritized allow and drop rules, then with a single stage, a
>>>>>> > > new set of ACL rules must be produced that achieves the same
>>>>>> > > behavior.  This is sometimes referred to as an "ACL merge"
>>>>>> > > algorithm, for example:
>>>>>> > >
>>>>>> >
>>>>>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>>>>>> > >
>>>>>> > > In the worst case, for example when the features act on different
>>>>>> > > packet 

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Darrell Ball]

On Tue, Aug 2, 2016 at 12:05 PM, Russell Bryant <russ...@ovn.org> wrote:

>
>
> On Tue, Aug 2, 2016 at 3:02 PM, Darrell Ball <dlu...@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys@gmail.com>
>> wrote:
>>
>>> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:
>>>>
>>>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <
>>>>> emspi...@us.ibm.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > -----"dev" <dev-boun...@openvswitch.org> wrote: -
>>>>> > >> To: Mickey Spiegel <mickeys@gmail.com>
>>>>> > >> From: Russell Bryant
>>>>> > >> Sent by: "dev"
>>>>> > >> Date: 07/29/2016 10:02AM
>>>>> > >> Cc: ovs dev <dev@openvswitch.org>
>>>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>>>> > >>
>>>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>>>>> mickeys@gmail.com
>>>>> > >
>>>>> > >> wrote:
>>>>> > >>
>>>>> > >>>
>>>>> > >>> This patch adds a second logical switch ingress ACL stage, and
>>>>> > >>> correspondingly a second logical switch egress ACL stage.  This
>>>>> > >>> allows for more than one ACL-based feature to be applied in the
>>>>> > >>> ingress and egress logical switch pipelines.  The features
>>>>> > >>> driving the different ACL stages may be configured by different
>>>>> > >>> users, for example an application deployer managing security
>>>>> > >>> groups and a network or security admin configuring network ACLs
>>>>> > >>> or firewall rules.
>>>>> > >>>
>>>>> > >>> Each ACL stage is self contained.  The "action" for the
>>>>> > >>> highest-"priority" matching row in an ACL stage determines a
>>>>> > >>> packet's treatment.  A separate "action" will be determined in
>>>>> > >>> each ACL stage, according to the ACL rules configured for that
>>>>> > >>> ACL stage.  The "priority" values are only relevant within the
>>>>> > >>> context of an ACL stage.
>>>>> > >>>
>>>>> > >>> ACL rules that do not specify an ACL stage are applied to the
>>>>> > >>> default "acl" stage.
>>>>> > >>>
>>>>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>>>> > >>
>>>>> > >>
>>>>> > >> Could you expand on why priorities in a single stage aren't
>>>>> enough to
>>>>> > >> satisfy the use case?
>>>>> > >
>>>>> > > If two features are configured independently with a mix of
>>>>> > > prioritized allow and drop rules, then with a single stage, a
>>>>> > > new set of ACL rules must be produced that achieves the same
>>>>> > > behavior.  This is sometimes referred to as an "ACL merge"
>>>>> > > algorithm, for example:
>>>>> > >
>>>>> >
>>>>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>>>>> > >
>>>>> > > In the worst case, for example when the features act on different
>>>>> > > packet fields (e.g. one on IP address and another on L4 port),
>>>>> > > the number of rules required can approach
>>>>> > > (# of ACL1 rules) * (# of ACL2 rules).
>>>>> > >
>>>>> > > While it is possible to code up such an algorithm, it adds
>>>>> > > significant complexity and complicates whichever layer
>>&g

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Tue, Aug 2, 2016 at 3:35 PM, Guru Shetty  wrote:

>
>
> On 2 August 2016 at 12:27, Russell Bryant  wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 3:17 PM, Guru Shetty  wrote:
>>
>>>
>>>
>>> On 2 August 2016 at 12:01, Russell Bryant  wrote:
>>>

 On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty  wrote:

> The 2 ct_commit for deletion of firewall rules will likely be tricky.
> This
> will need unit tests.
>

 I don't think I understand the concern.  Can you expand a bit on what
 you mean by "2 ct_commit for deletion of firewall rules"?

>>>
>>> My memory on how ct_commit(ct_label=1) works is a little hazy. There are
>>> 2 stages now. So whenever a firewall rule is deleted for an established
>>> connection, the default ct_commit(ct_label=1) will get hit and the
>>> connection is dropped. The same thing happens in the second stage for any
>>> removed firewall rule. In the second stage when a firewall rule is deleted
>>> ct_label is also set which will reflect in the first stage. Does not this
>>> cause confusion with the logic?
>>>
>>
>> Setting ct_label back to 0 only happens in the stateful table.  That
>> ct_commit will only occur if none of the ACL stages think the packet should
>> be dropped.  I think it's OK.
>>
>
> I see. I think we should still consider unit tests now. Userspace datapath
> has ct_commit now (it still can't do NAT). That should ideally work. If
> that does not work, we should consider adding tests to system-ovn.at
>

Yes, I agree that this area is sorely lacking in test coverage.

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Guru Shetty]

On 2 August 2016 at 12:27, Russell Bryant  wrote:

>
>
> On Tue, Aug 2, 2016 at 3:17 PM, Guru Shetty  wrote:
>
>>
>>
>> On 2 August 2016 at 12:01, Russell Bryant  wrote:
>>
>>>
>>> On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty  wrote:
>>>
 The 2 ct_commit for deletion of firewall rules will likely be tricky.
 This
 will need unit tests.

>>>
>>> I don't think I understand the concern.  Can you expand a bit on what
>>> you mean by "2 ct_commit for deletion of firewall rules"?
>>>
>>
>> My memory on how ct_commit(ct_label=1) works is a little hazy. There are
>> 2 stages now. So whenever a firewall rule is deleted for an established
>> connection, the default ct_commit(ct_label=1) will get hit and the
>> connection is dropped. The same thing happens in the second stage for any
>> removed firewall rule. In the second stage when a firewall rule is deleted
>> ct_label is also set which will reflect in the first stage. Does not this
>> cause confusion with the logic?
>>
>
> Setting ct_label back to 0 only happens in the stateful table.  That
> ct_commit will only occur if none of the ACL stages think the packet should
> be dropped.  I think it's OK.
>

I see. I think we should still consider unit tests now. Userspace datapath
has ct_commit now (it still can't do NAT). That should ideally work. If
that does not work, we should consider adding tests to system-ovn.at




>
> --
> Russell Bryant
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Tue, Aug 2, 2016 at 3:17 PM, Guru Shetty  wrote:

>
>
> On 2 August 2016 at 12:01, Russell Bryant  wrote:
>
>>
>> On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty  wrote:
>>
>>> The 2 ct_commit for deletion of firewall rules will likely be tricky.
>>> This
>>> will need unit tests.
>>>
>>
>> I don't think I understand the concern.  Can you expand a bit on what you
>> mean by "2 ct_commit for deletion of firewall rules"?
>>
>
> My memory on how ct_commit(ct_label=1) works is a little hazy. There are 2
> stages now. So whenever a firewall rule is deleted for an established
> connection, the default ct_commit(ct_label=1) will get hit and the
> connection is dropped. The same thing happens in the second stage for any
> removed firewall rule. In the second stage when a firewall rule is deleted
> ct_label is also set which will reflect in the first stage. Does not this
> cause confusion with the logic?
>

Setting ct_label back to 0 only happens in the stateful table.  That
ct_commit will only occur if none of the ACL stages think the packet should
be dropped.  I think it's OK.

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Guru Shetty]

On 2 August 2016 at 12:01, Russell Bryant  wrote:

>
> On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty  wrote:
>
>> The 2 ct_commit for deletion of firewall rules will likely be tricky. This
>> will need unit tests.
>>
>
> I don't think I understand the concern.  Can you expand a bit on what you
> mean by "2 ct_commit for deletion of firewall rules"?
>

My memory on how ct_commit(ct_label=1) works is a little hazy. There are 2
stages now. So whenever a firewall rule is deleted for an established
connection, the default ct_commit(ct_label=1) will get hit and the
connection is dropped. The same thing happens in the second stage for any
removed firewall rule. In the second stage when a firewall rule is deleted
ct_label is also set which will reflect in the first stage. Does not this
cause confusion with the logic?


>
>
> --
> Russell Bryant
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Tue, Aug 2, 2016 at 3:02 PM, Darrell Ball <dlu...@gmail.com> wrote:

>
>
> On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys@gmail.com>
> wrote:
>
>> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:
>>>
>>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
>>>> wrote:
>>>>
>>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com
>>>> >
>>>> > wrote:
>>>> > >
>>>> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
>>>> > >> To: Mickey Spiegel <mickeys@gmail.com>
>>>> > >> From: Russell Bryant
>>>> > >> Sent by: "dev"
>>>> > >> Date: 07/29/2016 10:02AM
>>>> > >> Cc: ovs dev <dev@openvswitch.org>
>>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>>> > >>
>>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>>>> mickeys@gmail.com
>>>> > >
>>>> > >> wrote:
>>>> > >>
>>>> > >>>
>>>> > >>> This patch adds a second logical switch ingress ACL stage, and
>>>> > >>> correspondingly a second logical switch egress ACL stage.  This
>>>> > >>> allows for more than one ACL-based feature to be applied in the
>>>> > >>> ingress and egress logical switch pipelines.  The features
>>>> > >>> driving the different ACL stages may be configured by different
>>>> > >>> users, for example an application deployer managing security
>>>> > >>> groups and a network or security admin configuring network ACLs
>>>> > >>> or firewall rules.
>>>> > >>>
>>>> > >>> Each ACL stage is self contained.  The "action" for the
>>>> > >>> highest-"priority" matching row in an ACL stage determines a
>>>> > >>> packet's treatment.  A separate "action" will be determined in
>>>> > >>> each ACL stage, according to the ACL rules configured for that
>>>> > >>> ACL stage.  The "priority" values are only relevant within the
>>>> > >>> context of an ACL stage.
>>>> > >>>
>>>> > >>> ACL rules that do not specify an ACL stage are applied to the
>>>> > >>> default "acl" stage.
>>>> > >>>
>>>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>>> > >>
>>>> > >>
>>>> > >> Could you expand on why priorities in a single stage aren't enough
>>>> to
>>>> > >> satisfy the use case?
>>>> > >
>>>> > > If two features are configured independently with a mix of
>>>> > > prioritized allow and drop rules, then with a single stage, a
>>>> > > new set of ACL rules must be produced that achieves the same
>>>> > > behavior.  This is sometimes referred to as an "ACL merge"
>>>> > > algorithm, for example:
>>>> > >
>>>> >
>>>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>>>> > >
>>>> > > In the worst case, for example when the features act on different
>>>> > > packet fields (e.g. one on IP address and another on L4 port),
>>>> > > the number of rules required can approach
>>>> > > (# of ACL1 rules) * (# of ACL2 rules).
>>>> > >
>>>> > > While it is possible to code up such an algorithm, it adds
>>>> > > significant complexity and complicates whichever layer
>>>> > > implements the merge algorithm, either OVN or the CMS above.
>>>> > >
>>>> > > By using multiple independent pipeline stages, all of this
>>>> > > software complexity is avoided, achieving the proper result
>>>> > > in a simple and straightforward manner.
>>>> > >
>>>> > > Recent n

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Tue, Aug 2, 2016 at 1:29 PM, Guru Shetty  wrote:

> The 2 ct_commit for deletion of firewall rules will likely be tricky. This
> will need unit tests.
>

I don't think I understand the concern.  Can you expand a bit on what you
mean by "2 ct_commit for deletion of firewall rules"?

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Darrell Ball]

On Tue, Aug 2, 2016 at 10:23 AM, Mickey Spiegel <mickeys@gmail.com>
wrote:

> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:
>>
>>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
>>> wrote:
>>>
>>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com>
>>> > wrote:
>>> > >
>>> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
>>> > >> To: Mickey Spiegel <mickeys....@gmail.com>
>>> > >> From: Russell Bryant
>>> > >> Sent by: "dev"
>>> > >> Date: 07/29/2016 10:02AM
>>> > >> Cc: ovs dev <dev@openvswitch.org>
>>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>> > >>
>>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>>> mickeys@gmail.com
>>> > >
>>> > >> wrote:
>>> > >>
>>> > >>>
>>> > >>> This patch adds a second logical switch ingress ACL stage, and
>>> > >>> correspondingly a second logical switch egress ACL stage.  This
>>> > >>> allows for more than one ACL-based feature to be applied in the
>>> > >>> ingress and egress logical switch pipelines.  The features
>>> > >>> driving the different ACL stages may be configured by different
>>> > >>> users, for example an application deployer managing security
>>> > >>> groups and a network or security admin configuring network ACLs
>>> > >>> or firewall rules.
>>> > >>>
>>> > >>> Each ACL stage is self contained.  The "action" for the
>>> > >>> highest-"priority" matching row in an ACL stage determines a
>>> > >>> packet's treatment.  A separate "action" will be determined in
>>> > >>> each ACL stage, according to the ACL rules configured for that
>>> > >>> ACL stage.  The "priority" values are only relevant within the
>>> > >>> context of an ACL stage.
>>> > >>>
>>> > >>> ACL rules that do not specify an ACL stage are applied to the
>>> > >>> default "acl" stage.
>>> > >>>
>>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>> > >>
>>> > >>
>>> > >> Could you expand on why priorities in a single stage aren't enough
>>> to
>>> > >> satisfy the use case?
>>> > >
>>> > > If two features are configured independently with a mix of
>>> > > prioritized allow and drop rules, then with a single stage, a
>>> > > new set of ACL rules must be produced that achieves the same
>>> > > behavior.  This is sometimes referred to as an "ACL merge"
>>> > > algorithm, for example:
>>> > >
>>> >
>>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>>> > >
>>> > > In the worst case, for example when the features act on different
>>> > > packet fields (e.g. one on IP address and another on L4 port),
>>> > > the number of rules required can approach
>>> > > (# of ACL1 rules) * (# of ACL2 rules).
>>> > >
>>> > > While it is possible to code up such an algorithm, it adds
>>> > > significant complexity and complicates whichever layer
>>> > > implements the merge algorithm, either OVN or the CMS above.
>>> > >
>>> > > By using multiple independent pipeline stages, all of this
>>> > > software complexity is avoided, achieving the proper result
>>> > > in a simple and straightforward manner.
>>> > >
>>> > > Recent network hardware ASICs tend to have around 8 or 10 ACL
>>> > > stages, though they tend to evaluate these in parallel given
>>> > > all the emphasis on low latency these days.
>>> >
>>> > Throwing in an example to illustrate the difference between one
>>> > ACL stage and two ACL stages:
>>> >
>>> > If two separate ACL stages:
>&

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:

>
>
> On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:
>
>> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
>> wrote:
>>
>> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com>
>> > wrote:
>> > >
>> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
>> > >> To: Mickey Spiegel <mickeys@gmail.com>
>> > >> From: Russell Bryant
>> > >> Sent by: "dev"
>> > >> Date: 07/29/2016 10:02AM
>> > >> Cc: ovs dev <dev@openvswitch.org>
>> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>> > >>
>> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
>> mickeys@gmail.com
>> > >
>> > >> wrote:
>> > >>
>> > >>>
>> > >>> This patch adds a second logical switch ingress ACL stage, and
>> > >>> correspondingly a second logical switch egress ACL stage.  This
>> > >>> allows for more than one ACL-based feature to be applied in the
>> > >>> ingress and egress logical switch pipelines.  The features
>> > >>> driving the different ACL stages may be configured by different
>> > >>> users, for example an application deployer managing security
>> > >>> groups and a network or security admin configuring network ACLs
>> > >>> or firewall rules.
>> > >>>
>> > >>> Each ACL stage is self contained.  The "action" for the
>> > >>> highest-"priority" matching row in an ACL stage determines a
>> > >>> packet's treatment.  A separate "action" will be determined in
>> > >>> each ACL stage, according to the ACL rules configured for that
>> > >>> ACL stage.  The "priority" values are only relevant within the
>> > >>> context of an ACL stage.
>> > >>>
>> > >>> ACL rules that do not specify an ACL stage are applied to the
>> > >>> default "acl" stage.
>> > >>>
>> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>> > >>
>> > >>
>> > >> Could you expand on why priorities in a single stage aren't enough to
>> > >> satisfy the use case?
>> > >
>> > > If two features are configured independently with a mix of
>> > > prioritized allow and drop rules, then with a single stage, a
>> > > new set of ACL rules must be produced that achieves the same
>> > > behavior.  This is sometimes referred to as an "ACL merge"
>> > > algorithm, for example:
>> > >
>> >
>> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>> > >
>> > > In the worst case, for example when the features act on different
>> > > packet fields (e.g. one on IP address and another on L4 port),
>> > > the number of rules required can approach
>> > > (# of ACL1 rules) * (# of ACL2 rules).
>> > >
>> > > While it is possible to code up such an algorithm, it adds
>> > > significant complexity and complicates whichever layer
>> > > implements the merge algorithm, either OVN or the CMS above.
>> > >
>> > > By using multiple independent pipeline stages, all of this
>> > > software complexity is avoided, achieving the proper result
>> > > in a simple and straightforward manner.
>> > >
>> > > Recent network hardware ASICs tend to have around 8 or 10 ACL
>> > > stages, though they tend to evaluate these in parallel given
>> > > all the emphasis on low latency these days.
>> >
>> > Throwing in an example to illustrate the difference between one
>> > ACL stage and two ACL stages:
>> >
>> > If two separate ACL stages:
>> > Feature 1
>> > acl  from-lport  100 (tcp == 80) allow-related
>> > acl  from-lport  100 (tcp == 8080) allow-related
>> > acl  from-lport  100 (udp) allow-related
>> > acl  from-lport  100 (ip4.src == 10.1.1.0/24 && tcp) allow-related
>> >
>> > Feature 2
>> > acl2 from-lport  300 (ip4.dst == 172.16.10.0/24) allow-related
>> > acl2 from-l

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Guru Shetty]

On 2 August 2016 at 10:23, Mickey Spiegel <mickeys@gmail.com> wrote:

> On Tue, Aug 2, 2016 at 9:26 AM, Darrell Ball <dlu...@gmail.com> wrote:
>
> >
> >
> > On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:
> >
> >> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
> >> wrote:
> >>
> >> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com
> >
> >> > wrote:
> >> > >
> >> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
> >> > >> To: Mickey Spiegel <mickeys....@gmail.com>
> >> > >> From: Russell Bryant
> >> > >> Sent by: "dev"
> >> > >> Date: 07/29/2016 10:02AM
> >> > >> Cc: ovs dev <dev@openvswitch.org>
> >> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
> >> > >>
> >> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
> >> mickeys@gmail.com
> >> > >
> >> > >> wrote:
> >> > >>
> >> > >>>
> >> > >>> This patch adds a second logical switch ingress ACL stage, and
> >> > >>> correspondingly a second logical switch egress ACL stage.  This
> >> > >>> allows for more than one ACL-based feature to be applied in the
> >> > >>> ingress and egress logical switch pipelines.  The features
> >> > >>> driving the different ACL stages may be configured by different
> >> > >>> users, for example an application deployer managing security
> >> > >>> groups and a network or security admin configuring network ACLs
> >> > >>> or firewall rules.
> >> > >>>
> >> > >>> Each ACL stage is self contained.  The "action" for the
> >> > >>> highest-"priority" matching row in an ACL stage determines a
> >> > >>> packet's treatment.  A separate "action" will be determined in
> >> > >>> each ACL stage, according to the ACL rules configured for that
> >> > >>> ACL stage.  The "priority" values are only relevant within the
> >> > >>> context of an ACL stage.
> >> > >>>
> >> > >>> ACL rules that do not specify an ACL stage are applied to the
> >> > >>> default "acl" stage.
> >> > >>>
> >> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
> >> > >>
> >> > >>
> >> > >> Could you expand on why priorities in a single stage aren't enough
> to
> >> > >> satisfy the use case?
> >> > >
> >> > > If two features are configured independently with a mix of
> >> > > prioritized allow and drop rules, then with a single stage, a
> >> > > new set of ACL rules must be produced that achieves the same
> >> > > behavior.  This is sometimes referred to as an "ACL merge"
> >> > > algorithm, for example:
> >> > >
> >> >
> >>
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
> >> > >
> >> > > In the worst case, for example when the features act on different
> >> > > packet fields (e.g. one on IP address and another on L4 port),
> >> > > the number of rules required can approach
> >> > > (# of ACL1 rules) * (# of ACL2 rules).
> >> > >
> >> > > While it is possible to code up such an algorithm, it adds
> >> > > significant complexity and complicates whichever layer
> >> > > implements the merge algorithm, either OVN or the CMS above.
> >> > >
> >> > > By using multiple independent pipeline stages, all of this
> >> > > software complexity is avoided, achieving the proper result
> >> > > in a simple and straightforward manner.
> >> > >
> >> > > Recent network hardware ASICs tend to have around 8 or 10 ACL
> >> > > stages, though they tend to evaluate these in parallel given
> >> > > all the emphasis on low latency these days.
> >> >
> >> > Throwing in an example to illustrate the difference between one
> >> > ACL stage and two ACL st

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Darrell Ball]

On Tue, Aug 2, 2016 at 4:52 AM, Russell Bryant <russ...@ovn.org> wrote:

> On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
> wrote:
>
> > On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com>
> > wrote:
> > >
> > > -"dev" <dev-boun...@openvswitch.org> wrote: -
> > >> To: Mickey Spiegel <mickeys@gmail.com>
> > >> From: Russell Bryant
> > >> Sent by: "dev"
> > >> Date: 07/29/2016 10:02AM
> > >> Cc: ovs dev <dev@openvswitch.org>
> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
> > >>
> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <
> mickeys@gmail.com
> > >
> > >> wrote:
> > >>
> > >>>
> > >>> This patch adds a second logical switch ingress ACL stage, and
> > >>> correspondingly a second logical switch egress ACL stage.  This
> > >>> allows for more than one ACL-based feature to be applied in the
> > >>> ingress and egress logical switch pipelines.  The features
> > >>> driving the different ACL stages may be configured by different
> > >>> users, for example an application deployer managing security
> > >>> groups and a network or security admin configuring network ACLs
> > >>> or firewall rules.
> > >>>
> > >>> Each ACL stage is self contained.  The "action" for the
> > >>> highest-"priority" matching row in an ACL stage determines a
> > >>> packet's treatment.  A separate "action" will be determined in
> > >>> each ACL stage, according to the ACL rules configured for that
> > >>> ACL stage.  The "priority" values are only relevant within the
> > >>> context of an ACL stage.
> > >>>
> > >>> ACL rules that do not specify an ACL stage are applied to the
> > >>> default "acl" stage.
> > >>>
> > >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
> > >>
> > >>
> > >> Could you expand on why priorities in a single stage aren't enough to
> > >> satisfy the use case?
> > >
> > > If two features are configured independently with a mix of
> > > prioritized allow and drop rules, then with a single stage, a
> > > new set of ACL rules must be produced that achieves the same
> > > behavior.  This is sometimes referred to as an "ACL merge"
> > > algorithm, for example:
> > >
> >
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
> > >
> > > In the worst case, for example when the features act on different
> > > packet fields (e.g. one on IP address and another on L4 port),
> > > the number of rules required can approach
> > > (# of ACL1 rules) * (# of ACL2 rules).
> > >
> > > While it is possible to code up such an algorithm, it adds
> > > significant complexity and complicates whichever layer
> > > implements the merge algorithm, either OVN or the CMS above.
> > >
> > > By using multiple independent pipeline stages, all of this
> > > software complexity is avoided, achieving the proper result
> > > in a simple and straightforward manner.
> > >
> > > Recent network hardware ASICs tend to have around 8 or 10 ACL
> > > stages, though they tend to evaluate these in parallel given
> > > all the emphasis on low latency these days.
> >
> > Throwing in an example to illustrate the difference between one
> > ACL stage and two ACL stages:
> >
> > If two separate ACL stages:
> > Feature 1
> > acl  from-lport  100 (tcp == 80) allow-related
> > acl  from-lport  100 (tcp == 8080) allow-related
> > acl  from-lport  100 (udp) allow-related
> > acl  from-lport  100 (ip4.src == 10.1.1.0/24 && tcp) allow-related
> >
> > Feature 2
> > acl2 from-lport  300 (ip4.dst == 172.16.10.0/24) allow-related
> > acl2 from-lport  300 (ip4.dst == 192.168.20.0/24) allow-related
> > acl2 from-lport  200 (ip4.dst == 172.16.0.0/20) drop
> > acl2 from-lport  200 (ip4.dst == 192.168.0.0/16) drop
> > acl2 from-lport  100 (ip4.dst == 172.16.0.0/16) allow-related
> >
> > Combined in one stage, to get the equivalent behavior, this would
> require:
> > from-lport  300 (ip4.dst == 172.16.10.0/24 && tcp == 80) allow-rel

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys@gmail.com>
wrote:

> On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com>
> wrote:
> >
> > -"dev" <dev-boun...@openvswitch.org> wrote: -
> >> To: Mickey Spiegel <mickeys@gmail.com>
> >> From: Russell Bryant
> >> Sent by: "dev"
> >> Date: 07/29/2016 10:02AM
> >> Cc: ovs dev <dev@openvswitch.org>
> >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
> >>
> >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <mickeys@gmail.com
> >
> >> wrote:
> >>
> >>>
> >>> This patch adds a second logical switch ingress ACL stage, and
> >>> correspondingly a second logical switch egress ACL stage.  This
> >>> allows for more than one ACL-based feature to be applied in the
> >>> ingress and egress logical switch pipelines.  The features
> >>> driving the different ACL stages may be configured by different
> >>> users, for example an application deployer managing security
> >>> groups and a network or security admin configuring network ACLs
> >>> or firewall rules.
> >>>
> >>> Each ACL stage is self contained.  The "action" for the
> >>> highest-"priority" matching row in an ACL stage determines a
> >>> packet's treatment.  A separate "action" will be determined in
> >>> each ACL stage, according to the ACL rules configured for that
> >>> ACL stage.  The "priority" values are only relevant within the
> >>> context of an ACL stage.
> >>>
> >>> ACL rules that do not specify an ACL stage are applied to the
> >>> default "acl" stage.
> >>>
> >>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
> >>
> >>
> >> Could you expand on why priorities in a single stage aren't enough to
> >> satisfy the use case?
> >
> > If two features are configured independently with a mix of
> > prioritized allow and drop rules, then with a single stage, a
> > new set of ACL rules must be produced that achieves the same
> > behavior.  This is sometimes referred to as an "ACL merge"
> > algorithm, for example:
> >
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
> >
> > In the worst case, for example when the features act on different
> > packet fields (e.g. one on IP address and another on L4 port),
> > the number of rules required can approach
> > (# of ACL1 rules) * (# of ACL2 rules).
> >
> > While it is possible to code up such an algorithm, it adds
> > significant complexity and complicates whichever layer
> > implements the merge algorithm, either OVN or the CMS above.
> >
> > By using multiple independent pipeline stages, all of this
> > software complexity is avoided, achieving the proper result
> > in a simple and straightforward manner.
> >
> > Recent network hardware ASICs tend to have around 8 or 10 ACL
> > stages, though they tend to evaluate these in parallel given
> > all the emphasis on low latency these days.
>
> Throwing in an example to illustrate the difference between one
> ACL stage and two ACL stages:
>
> If two separate ACL stages:
> Feature 1
> acl  from-lport  100 (tcp == 80) allow-related
> acl  from-lport  100 (tcp == 8080) allow-related
> acl  from-lport  100 (udp) allow-related
> acl  from-lport  100 (ip4.src == 10.1.1.0/24 && tcp) allow-related
>
> Feature 2
> acl2 from-lport  300 (ip4.dst == 172.16.10.0/24) allow-related
> acl2 from-lport  300 (ip4.dst == 192.168.20.0/24) allow-related
> acl2 from-lport  200 (ip4.dst == 172.16.0.0/20) drop
> acl2 from-lport  200 (ip4.dst == 192.168.0.0/16) drop
> acl2 from-lport  100 (ip4.dst == 172.16.0.0/16) allow-related
>
> Combined in one stage, to get the equivalent behavior, this would require:
> from-lport  300 (ip4.dst == 172.16.10.0/24 && tcp == 80) allow-related
> from-lport  300 (ip4.dst == 172.16.10.0/24 && tcp == 8080) allow-related
> from-lport  300 (ip4.dst == 172.16.10.0/24 && udp) allow-related
> from-lport  300 (ip4.dst == 172.16.10.0/24 && ip4.src == 10.1.1.0/24 &&
> tcp) allow-related
> from-lport  300 (ip4.dst == 192.168.20.0/24 && tcp == 80) allow-related
> from-lport  300 (ip4.dst == 192.168.20.0/24 && tcp == 8080) allow-related
> from-lport  300 (ip4.dst == 192.168.20.0/24 && udp) allow-relate

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com>
wrote:
>
> -"dev" <dev-boun...@openvswitch.org> wrote: -
>> To: Mickey Spiegel <mickeys@gmail.com>
>> From: Russell Bryant
>> Sent by: "dev"
>> Date: 07/29/2016 10:02AM
>> Cc: ovs dev <dev@openvswitch.org>
>> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage
>>
>> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <mickeys@gmail.com>
>> wrote:
>>
>>>
>>> This patch adds a second logical switch ingress ACL stage, and
>>> correspondingly a second logical switch egress ACL stage.  This
>>> allows for more than one ACL-based feature to be applied in the
>>> ingress and egress logical switch pipelines.  The features
>>> driving the different ACL stages may be configured by different
>>> users, for example an application deployer managing security
>>> groups and a network or security admin configuring network ACLs
>>> or firewall rules.
>>>
>>> Each ACL stage is self contained.  The "action" for the
>>> highest-"priority" matching row in an ACL stage determines a
>>> packet's treatment.  A separate "action" will be determined in
>>> each ACL stage, according to the ACL rules configured for that
>>> ACL stage.  The "priority" values are only relevant within the
>>> context of an ACL stage.
>>>
>>> ACL rules that do not specify an ACL stage are applied to the
>>> default "acl" stage.
>>>
>>> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>
>>
>>
>> Could you expand on why priorities in a single stage aren't enough to
>> satisfy the use case?
>
> If two features are configured independently with a mix of
> prioritized allow and drop rules, then with a single stage, a
> new set of ACL rules must be produced that achieves the same
> behavior.  This is sometimes referred to as an "ACL merge"
> algorithm, for example:
>
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514
>
> In the worst case, for example when the features act on different
> packet fields (e.g. one on IP address and another on L4 port),
> the number of rules required can approach
> (# of ACL1 rules) * (# of ACL2 rules).
>
> While it is possible to code up such an algorithm, it adds
> significant complexity and complicates whichever layer
> implements the merge algorithm, either OVN or the CMS above.
>
> By using multiple independent pipeline stages, all of this
> software complexity is avoided, achieving the proper result
> in a simple and straightforward manner.
>
> Recent network hardware ASICs tend to have around 8 or 10 ACL
> stages, though they tend to evaluate these in parallel given
> all the emphasis on low latency these days.

Throwing in an example to illustrate the difference between one
ACL stage and two ACL stages:

If two separate ACL stages:
Feature 1
acl  from-lport  100 (tcp == 80) allow-related
acl  from-lport  100 (tcp == 8080) allow-related
acl  from-lport  100 (udp) allow-related
acl  from-lport  100 (ip4.src == 10.1.1.0/24 && tcp) allow-related

Feature 2
acl2 from-lport  300 (ip4.dst == 172.16.10.0/24) allow-related
acl2 from-lport  300 (ip4.dst == 192.168.20.0/24) allow-related
acl2 from-lport  200 (ip4.dst == 172.16.0.0/20) drop
acl2 from-lport  200 (ip4.dst == 192.168.0.0/16) drop
acl2 from-lport  100 (ip4.dst == 172.16.0.0/16) allow-related

Combined in one stage, to get the equivalent behavior, this would require:
from-lport  300 (ip4.dst == 172.16.10.0/24 && tcp == 80) allow-related
from-lport  300 (ip4.dst == 172.16.10.0/24 && tcp == 8080) allow-related
from-lport  300 (ip4.dst == 172.16.10.0/24 && udp) allow-related
from-lport  300 (ip4.dst == 172.16.10.0/24 && ip4.src == 10.1.1.0/24 &&
tcp) allow-related
from-lport  300 (ip4.dst == 192.168.20.0/24 && tcp == 80) allow-related
from-lport  300 (ip4.dst == 192.168.20.0/24 && tcp == 8080) allow-related
from-lport  300 (ip4.dst == 192.168.20.0/24 && udp) allow-related
from-lport  300 (ip4.dst == 192.168.20.0/24 && ip4.src == 10.1.1.0/24 &&
tcp) allow-related
from-lport  200 (ip4.dst == 172.16.0.0/20) drop
from-lport  200 (ip4.dst == 192.168.0.0/16) drop
from-lport  100 (ip4.dst == 172.16.0.0/16 && tcp == 80) allow-related
from-lport  100 (ip4.dst == 172.16.0.0/16 && tcp == 8080) allow-related
from-lport  100 (ip4.dst == 172.16.0.0/16 && udp) allow-related
from-lport  100 (ip4.dst == 172.16.0.0/16 && ip4.src == 10.1.1.0/24 && tcp)
allow-r

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

-"dev" <dev-boun...@openvswitch.org> wrote: -
To: Mickey Spiegel <mickeys@gmail.com>
From: Russell Bryant 
Sent by: "dev" 
Date: 07/29/2016 10:02AM
Cc: ovs dev <dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <mickeys@gmail.com>
wrote:

>
> This patch adds a second logical switch ingress ACL stage, and
> correspondingly a second logical switch egress ACL stage.  This
> allows for more than one ACL-based feature to be applied in the
> ingress and egress logical switch pipelines.  The features
> driving the different ACL stages may be configured by different
> users, for example an application deployer managing security
> groups and a network or security admin configuring network ACLs
> or firewall rules.
>
> Each ACL stage is self contained.  The "action" for the
> highest-"priority" matching row in an ACL stage determines a
> packet's treatment.  A separate "action" will be determined in
> each ACL stage, according to the ACL rules configured for that
> ACL stage.  The "priority" values are only relevant within the
> context of an ACL stage.
>
> ACL rules that do not specify an ACL stage are applied to the
> default "acl" stage.
>
> Signed-off-by: Mickey Spiegel <mickeys@gmail.com>


Could you expand on why priorities in a single stage aren't enough to
satisfy the use case?


If two features are configured independently with a mix of
prioritized allow and drop rules, then with a single stage, a
new set of ACL rules must be produced that achieves the same
behavior.  This is sometimes referred to as an "ACL merge"
algorithm, for example:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514

In the worst case, for example when the features act on different
packet fields (e.g. one on IP address and another on L4 port),
the number of rules required can approach
(# of ACL1 rules) * (# of ACL2 rules).

While it is possible to code up such an algorithm, it adds
significant complexity and complicates whichever layer
implements the merge algorithm, either OVN or the CMS above.

By using multiple independent pipeline stages, all of this
software complexity is avoided, achieving the proper result
in a simple and straightforward manner.

Recent network hardware ASICs tend to have around 8 or 10 ACL
stages, though they tend to evaluate these in parallel given
all the emphasis on low latency these days.

Mickey


-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


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

Re: [ovs-dev] [PATCH] ovn: Add second ACL stage

[Russell Bryant]

On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel 
wrote:

>
> This patch adds a second logical switch ingress ACL stage, and
> correspondingly a second logical switch egress ACL stage.  This
> allows for more than one ACL-based feature to be applied in the
> ingress and egress logical switch pipelines.  The features
> driving the different ACL stages may be configured by different
> users, for example an application deployer managing security
> groups and a network or security admin configuring network ACLs
> or firewall rules.
>
> Each ACL stage is self contained.  The "action" for the
> highest-"priority" matching row in an ACL stage determines a
> packet's treatment.  A separate "action" will be determined in
> each ACL stage, according to the ACL rules configured for that
> ACL stage.  The "priority" values are only relevant within the
> context of an ACL stage.
>
> ACL rules that do not specify an ACL stage are applied to the
> default "acl" stage.
>
> Signed-off-by: Mickey Spiegel 


Could you expand on why priorities in a single stage aren't enough to
satisfy the use case?

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ovn: Add second ACL stage

[Mickey Spiegel]

From: Mickey Spiegel 

This patch adds a second logical switch ingress ACL stage, and
correspondingly a second logical switch egress ACL stage.  This
allows for more than one ACL-based feature to be applied in the
ingress and egress logical switch pipelines.  The features
driving the different ACL stages may be configured by different
users, for example an application deployer managing security
groups and a network or security admin configuring network ACLs
or firewall rules.

Each ACL stage is self contained.  The "action" for the
highest-"priority" matching row in an ACL stage determines a
packet's treatment.  A separate "action" will be determined in
each ACL stage, according to the ACL rules configured for that
ACL stage.  The "priority" values are only relevant within the
context of an ACL stage.

ACL rules that do not specify an ACL stage are applied to the
default "acl" stage.

Signed-off-by: Mickey Spiegel 
---
 ovn/northd/ovn-northd.c   | 319 +++---
 ovn/ovn-nb.ovsschema  |   7 +-
 ovn/ovn-nb.xml|  25 
 ovn/utilities/ovn-nbctl.c |  35 +++--
 tests/ovn-nbctl.at|  30 +++--
 5 files changed, 264 insertions(+), 152 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 3047b76..2e1d314 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -97,12 +97,13 @@ enum ovn_stage {
 PIPELINE_STAGE(SWITCH, IN,  PRE_LB, 4, "ls_in_pre_lb") \
 PIPELINE_STAGE(SWITCH, IN,  PRE_STATEFUL,   5, "ls_in_pre_stateful")\
 PIPELINE_STAGE(SWITCH, IN,  ACL,6, "ls_in_acl")  \
-PIPELINE_STAGE(SWITCH, IN,  LB, 7, "ls_in_lb")   \
-PIPELINE_STAGE(SWITCH, IN,  STATEFUL,   8, "ls_in_stateful") \
-PIPELINE_STAGE(SWITCH, IN,  ARP_ND_RSP, 9, "ls_in_arp_rsp")  \
-PIPELINE_STAGE(SWITCH, IN,  DHCP_OPTIONS,   10, "ls_in_dhcp_options") \
-PIPELINE_STAGE(SWITCH, IN,  DHCP_RESPONSE,  11, "ls_in_dhcp_response") \
-PIPELINE_STAGE(SWITCH, IN,  L2_LKUP,12, "ls_in_l2_lkup")  \
+PIPELINE_STAGE(SWITCH, IN,  ACL2,   7, "ls_in_acl2")  \
+PIPELINE_STAGE(SWITCH, IN,  LB, 8, "ls_in_lb")   \
+PIPELINE_STAGE(SWITCH, IN,  STATEFUL,   9, "ls_in_stateful") \
+PIPELINE_STAGE(SWITCH, IN,  ARP_ND_RSP, 10, "ls_in_arp_rsp")  \
+PIPELINE_STAGE(SWITCH, IN,  DHCP_OPTIONS,   11, "ls_in_dhcp_options") \
+PIPELINE_STAGE(SWITCH, IN,  DHCP_RESPONSE,  12, "ls_in_dhcp_response") \
+PIPELINE_STAGE(SWITCH, IN,  L2_LKUP,13, "ls_in_l2_lkup")  \
   \
 /* Logical switch egress stages. */   \
 PIPELINE_STAGE(SWITCH, OUT, PRE_LB,   0, "ls_out_pre_lb") \
@@ -110,9 +111,10 @@ enum ovn_stage {
 PIPELINE_STAGE(SWITCH, OUT, PRE_STATEFUL, 2, "ls_out_pre_stateful")  \
 PIPELINE_STAGE(SWITCH, OUT, LB,   3, "ls_out_lb")\
 PIPELINE_STAGE(SWITCH, OUT, ACL,  4, "ls_out_acl")\
-PIPELINE_STAGE(SWITCH, OUT, STATEFUL, 5, "ls_out_stateful")   \
-PIPELINE_STAGE(SWITCH, OUT, PORT_SEC_IP,  6, "ls_out_port_sec_ip")\
-PIPELINE_STAGE(SWITCH, OUT, PORT_SEC_L2,  7, "ls_out_port_sec_l2")\
+PIPELINE_STAGE(SWITCH, OUT, ACL2, 5, "ls_out_acl2")\
+PIPELINE_STAGE(SWITCH, OUT, STATEFUL, 6, "ls_out_stateful")   \
+PIPELINE_STAGE(SWITCH, OUT, PORT_SEC_IP,  7, "ls_out_port_sec_ip")\
+PIPELINE_STAGE(SWITCH, OUT, PORT_SEC_L2,  8, "ls_out_port_sec_l2")\
   \
 /* Logical router ingress stages. */  \
 PIPELINE_STAGE(ROUTER, IN,  ADMISSION,   0, "lr_in_admission")\
@@ -193,6 +195,48 @@ ovn_stage_to_datapath_type(enum ovn_stage stage)
 default: OVS_NOT_REACHED();
 }
 }
+
+static enum ovn_stage
+ovn_stage_from_acl_stage(const char *acl_stage, enum ovn_pipeline pipeline) {
+if ((pipeline == P_IN) && !acl_stage) {
+return S_SWITCH_IN_ACL;
+} else if ((pipeline == P_OUT) && !acl_stage) {
+return S_SWITCH_OUT_ACL;
+} else if ((pipeline == P_IN) && !strcmp(acl_stage, "acl")) {
+return S_SWITCH_IN_ACL;
+} else if ((pipeline == P_OUT) && !strcmp(acl_stage, "acl")) {
+return S_SWITCH_OUT_ACL;
+} else if ((pipeline == P_IN) && !strcmp(acl_stage, "acl2")) {
+return S_SWITCH_IN_ACL2;
+} else if ((pipeline == P_OUT) && !strcmp(acl_stage, "acl2")) {
+return S_SWITCH_OUT_ACL2;
+} else if (pipeline == P_IN) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
+VLOG_WARN_RL(, "Bad configuration: invalid ACL stage %s",
+ acl_stage);
+return S_SWITCH_IN_ACL;
+} else {
+static struct