Open Stack

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:bcafarel at 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.cardoso at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev