On 12/17/2015 04:45 PM, Ihar Hrachyshka wrote:
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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
