Takashi Yamamoto <yamam...@midokura.com> wrote:
hi,
On Fri, Dec 4, 2015 at 12:46 AM, Ihar Hrachyshka <ihrac...@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
__________________________________________________________________________
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
