Open Stack

On 12/17/2015 04:45 PM, Ihar Hrachyshka wrote:
> Rossella Sblendido <rsblendido at suse.com> wrote:
>
>> Hi Ihar,
>>
>>
>> wow, good job!!
>> Sorry for the very slow reply.
>> I really like your proposal...some comments inline.
>>
>> On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote:
>>> Hi,
>>>
>>> Small update on the RFE. It was approved for Mitaka, assuming we come up
>>> with proper details upfront thru neutron-specs process.
>>>
>>> In the meantime, we have found more use cases for flow management among
>>> features in development: QoS DSCP, also the new OF based firewall
>>> driver. Both authors for those new features independently realized that
>>> agent does not currently play nice with flows set by external code due
>>> to its graceful restart behaviour when rules with unknown cookies are
>>> cleaned up. [The agent uses a random session uuid() to mark rules that
>>> belong to its current run.]
>>>
>>> Before I proceed, full disclosure: I know almost nothing about OpenFlow
>>> capabilities, so some pieces below may make no sense. I tried to come up
>>> with high level model first and then try to map it to available OF
>>> features. Please don’t hesitate to comment, I like to learn new
>>> stuff! ;)
>>
>> I am not an expert either so I encourage people to chime in here.
>>
>>> I am thinking lately on the use cases we collected so far. One common
>>> need for all features that were seen to be interested in proper
>>> integration with Open vSwitch agent is to be able to manage feature
>>> specific flows on br-int and br-tun. There are other things that
>>> projects may need, like patch ports, though I am still struggling with
>>> the question of whether it may be postponed or avoided for phase 1.
>>>
>>> There are several specific operation 'kinds' that we should cover for
>>> the RFE:
>>> - managing flows that modify frames in-place;
>>> - managing flows that redirect frames.
>>>
>>> There are some things that should be considered to make features
>>> cooperate with the agent and other extensions:
>>> - feature flows should have proper priorities based on their ‘kind’
>>> (f.e. in-place modification probably go before redirections);
>>> - feature flows should survive flow reset that may be triggered by the
>>> agent;
>>> - feature flows should survive flow reset without data plane disruption
>>> (=they should support graceful restart:
>>> https://review.openstack.org/#/c/182920).
>>>
>>> With that in mind, I see the following high level design for the flow
>>> tables:
>>>
>>> - table 0 serves as a dispatcher for specific features;
>>> - each feature gets one or more tables, one per flow ‘kind’ needed;
>>> - for each feature table, a new flow entry is added to table 0 that
>>> would redirect to feature specific table; the rule will be triggered
>>> only if OF metadata is not updated inside the feature table (see the
>>> next bullet); the rule will have priority that is defined for the ‘kind’
>>> of the operation that is implemented by the table it redirects to;
>>> -  each feature table will have default actions that will 1) mark OF
>>> metadata for the frame as processed by the feature; 2) redirect back to
>>> table 0;
>>> - all feature specific flow rules (except dispatcher rules) belong to
>>> feature tables;
>>>
>>> Now, the workflow for extensions that are interested in setting flows
>>> would be:
>>> - on initialize() call, extension defines feature tables it will need;
>>
>> Do you mean this in a dynamic way or every extension will have tables
>> assigned, basically hard-coded? I prefer the second way so we have
>> more controls of the tables that are currently used.
>
> Do you suggest creating several tables even if an extension is not
> interested in all of them? As for the table name, I guess we may build
> it as agent_cookie + extension name so that it’s clear which tables were
> bootstrapped in current session, and which can be cleaned up after we
> clear flows from previous sessions.

I like this.
>
>>
>>> it passes the name of the feature table and the ‘kind’ of the actions it
>>> will execute; with that, the following is initialized by the agent: 1)
>>
>> It would be nice to pass also a filter to match some packets. We
>> probably don't want to send all the packet to the feature table, the
>> extension can define that.
>>
>
> It probably stands for some optimization, though I am not sure how
> serious. If we go this route, we also need to short-circuit metadata
> marking on filter unmatched, or do we expect other extensions to
> influence filter matching?
>
> I am not sure how it would look like. Do we allow random matching
> filters, or enforce some base types and leave more detailed filters to
> extension tables?

Let's leave it for later then. You are right, that's probably an early 
optimization

>
>>> table 0 dispatcher entry to redirect frames into feature table; the
>>> entry has the priority according to the ‘kind’ of the table; 2) the
>>
>> I think we need to define the priority better. According to what you
>> wrote we assign priority based on "in-place modification probably go
>> before redirections" not sure if it's enough. What happens if we have
>> two features that both requires in place-modifications? How do we
>> prioritize them? Are we going to allow 2 extension at the same time?
>> Let me think more about this...It would be nice to have some real
>> world example…
>
> I assumed that multiple extensions don’t mess with the same frame
> pieces, at least not in a way that would change behaviour based on their
> ordering.
>
> For real world example, let’s say we want to apply DSCP marks on
> specific traffic, but also want to set MPLS header for SFC needs and
> then later push it down the service chain.

I think we really need some input here from the people that are going to 
use this feature. My gut feeling says that we might need more 
granularity, hope to be wrong.
>
>>
>>> actual feature table with two default rules (update metadata and push
>>> back to table 0);
>>> - whenever extension needs to add a new flow rule, it passes the
>>> following into the agent: 1) table name; 2) flow specific parameters
>>> (actions, priority, ...)
>>>
>>> Since the agent will manage setting flows for extensions, it will be
>>> able to use the active agent cookie for all feature flows; next time the
>>> agent is restarted, it should be able to respin extension flows with no
>>> data plane disruption. [Note: we should make sure that on agent restart,
>>> we call to extensions *before* we clean up stale flow rules.]
>>
>> I like this :)
>>> That design will hopefully allow us to abstract interaction with flows
>>> from extensions into management code inside the agent. It should
>>> guarantee extensions cooperate properly assuming they properly define
>>> their priorities thru ‘kinds’ of tables they have.
>>>
>>> It is also assumed that existing flow based features integrated into the
>>> agent (dvr? anti-spoofing?) will eventually move to the new flow table
>>> management model.
>>
>> Good candidates for a POC of this model?
>
> Probably, since they are in tree already. Good suggestion.

:)

I guess it's time to start a spec and ask all interested parties to 
comment there, this thread is becoming pretty long ;)

Rossella

>
> Ihar
>
> __________________________________________________________________________
> 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