Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

2017-01-12 Thread Cathy Zhang 
This clash check was added on purpose to avoid the ambiguity of the following 
scenario (This is just one of many similar scenarios):

VM2, VM3 hosted on Int-Bridge1 of Server1
VM4 hosted on Int-Bridge2 of Server2
VM5 hosted on Int-Bridge3 of Server3

Chain1: VM1, VM2, VM4
Chain2: VM1, VM3, VM5

Suppose FC1 for Chain1 and FC2 for Chain2 are the same except logical source 
port(Igor's testing scenario). 
If we allow this, then when the Int-Bridge1 on Server1 receives the packet from 
VM2 or VM3, it can not distinguish 
which chain the packet is associated with and thus don't know whether to 
forward the packet to VM4 or VM5  
since the packet's n-tuple classification is the same (logical source port is 
not carried in the packet). 

If the SF2 on VM2 and the SF3 on VM3 are chain-ID aware (eg. Supports NSH), 
then the ambiguity can be resolved and we can remove this check. 
Another alternative is to support a chain-ID-correlation mechanism between the 
SF and the vSwitch. 

Thanks,
Cathy

 

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 7:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow 
classifiers

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com> wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following 
> limitation when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same 
> classification of traffic but from different logical source ports – my 
> expectation was that there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 
> 2 different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the 
> flow-classifier being checked are in [2], where neither logical source 
> port or logical destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a 
> bug? For the SFC Graphs work, it’s important that this limitation be 
> lifted – I’m happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192
> a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f
> 408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I ended up 
hitting the same problem while anylyzing the tempest race condition failures 
[1].

Each test creates a new port to use for its port pair, and a new flow 
classifier. The flow classifier has the same parameters, except for the source 
logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test conflicting with 
the new one.

My thoughts here: this should indeed be allowed, and I think this restriction 
comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of 
flowclassifier_basic_conflict(), as it adds logical port conflict check and is 
the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs went 
fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

--
Bernard Cafarelli

__
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
__
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] [networking-sfc] Limitation on port chains + flow classifiers

2017-01-12 Thread Duarte Cardoso, Igor 
Thanks Bernard, Louis, IRC meeting,

Given the encapsulation requirement when having SFC Graphs, there is then no 
need to call flowclassifier_basic_conflict() for the said graphs. I will see 
how to avoid calling flowclassifier_basic_conflict() specifically when creating 
graphs of port chains. Will likely need to touch multiple parts of the code 
since port chain resources must already exist before a graph can connect them. 

Best regards,
Igor.

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 3:44 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow 
classifiers

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com> wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following 
> limitation when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same 
> classification of traffic but from different logical source ports – my 
> expectation was that there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 
> 2 different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the 
> flow-classifier being checked are in [2], where neither logical source 
> port or logical destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a 
> bug? For the SFC Graphs work, it’s important that this limitation be 
> lifted – I’m happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192
> a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f
> 408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I ended up 
hitting the same problem while anylyzing the tempest race condition failures 
[1].

Each test creates a new port to use for its port pair, and a new flow 
classifier. The flow classifier has the same parameters, except for the source 
logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test conflicting with 
the new one.

My thoughts here: this should indeed be allowed, and I think this restriction 
comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of 
flowclassifier_basic_conflict(), as it adds logical port conflict check and is 
the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs went 
fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

--
Bernard Cafarelli

__
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
__
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] [networking-sfc] Limitation on port chains + flow classifiers

2017-01-12 Thread Bernard Cafarelli 
On 10 January 2017 at 14:13, Duarte Cardoso, Igor
 wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following limitation
> when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same classification of
> traffic but from different logical source ports – my expectation was that
> there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 2
> different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the flow-classifier
> being checked are in [2], where neither logical source port or logical
> destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a bug? For
> the SFC Graphs work, it’s important that this limitation be lifted – I’m
> happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I
ended up hitting the same problem while anylyzing the tempest race
condition failures [1].

Each test creates a new port to use for its port pair, and a new flow
classifier. The flow classifier has the same parameters, except for
the source logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test
conflicting with the new one.

My thoughts here: this should indeed be allowed, and I think this
restriction comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of
flowclassifier_basic_conflict(), as it adds logical port conflict
check and is the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs
went fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

-- 
Bernard Cafarelli

__
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

[openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

2017-01-10 Thread Duarte Cardoso, Igor 
Hi networking-sfc,

While working on the SFC Graphs patch, I observed the following limitation when 
creating port-chains: http://paste.openstack.org/show/594387/.

My objective was to have 2 port-chains acting on the same classification of 
traffic but from different logical source ports - my expectation was that there 
wouldn't be any clash here.

However, the flow-classifiers clash when they are associated to those 2 
different port-chains.

The exception is raised in [1] and the attributes of the flow-classifier being 
checked are in [2], where neither logical source port or logical destination 
port are specified.

Is there a specific reasoning behind this or can it be considered a bug? For 
the SFC Graphs work, it's important that this limitation be lifted - I'm happy 
to submit a patch to correct it.
Let me know your thoughts.

[1] 
https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

Best regards,
Igor.

__
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