Open Stack

Takashi Yamamoto <yamamoto at midokura.com> wrote:

> hi,
>
> On Fri, Dec 4, 2015 at 12:46 AM, Ihar Hrachyshka <ihrachys at redhat.com>  
> 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 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.
>
> i suspect port management is mandatory for many of usecases.

Could be. If we realize it, we will build on top of general agent API  
framework. The rest of proposal talks about flow management though, and if  
we feel some use cases can be covered with just patch ports, no flows  
involved, we can split efforts and push some stub agent API that can be  
evolved in parallel for two things.

>
>> 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; 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) table 0
>> dispatcher entry to redirect frames into feature table; the entry has the
>> priority according to the ‘kind’ of the table; 2) the 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, ...)
>
> "actions" here means openflow actions?
>
> passing openflow actions as parameters is not simple as it might sound
> because they are complex objects.  esp. when we have two backends.
> (ovs-ofctl and native of_interface)

Lately I started to think that allowing all types of rules in extension  
tables is not such a bad idea, as long as the agent is the entity managing  
cookies, not extensions (for disruption-less agent restarts).

>
>> 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.]
>>
>> 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.
>>
>> I understand that the model does not reflect how do feature processing for
>> existing OF based features in the agent. It may require some smart
>> workarounds to allow non-disruptive migration to new flow table setup.
>>
>> It would be great to see the design bashed hard before I start to put it
>> into spec format. Especially if it’s not sane. :)
>
> i tend to think it's better to start from a crude experimental api (eg.  
> give
> the bridge objects to extension drivers) to avoid blocking subprojects  
> too long.

I think the main problem with it is it’s not clear how to make ovs agent  
graceful restart feature play nice with extension flows. If the agent does  
not manage the tables and flows for extensions, their flow infra will be  
dropped on each agent restart.

We may probably think of passing agent uuid into extensions to allow it to  
be used as a cookie for their flows, and make sure extensions are triggered  
before we reset obsolete flows in the agent. It may work.

I would only want to see it as a temporary solution. One thing that I would  
like to tackle with the proposal is keeping our main flow tables clean from  
extension specific flows, if anything, for easier debugging.

Ihar