Rossella Sblendido <rsblend...@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.
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?
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.
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.
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
