[openstack-dev] [midonet] Re: Classifiers for MN's Service Chaining API

Ivan Kelly ivan at midokura.com
Wed Jan 27 09:28:38 UTC 2016

> the API has L2Insertions that each have a position. The current API
> therefore only expects a single list of L2Insertions on a single VM. It
> seems wrong to attach classifiers to the L2Insertion object... on the other
> hand, since the model assumes the Service Function leaves the traffic
> unmodified, it might be consistent with the model. But I'm not sure whether
> the positions should still be unique and I think it would be hard to reason
> about. That suggests we probably need a new object type, let's call it
> InsertionChain for now, that can group a set of Classifiers with a list of
> L2Insertion objects (each with unique position). InsertionChains themselves
> probably need a position field and a single packet might satisfy classifiers
> in multiple InsertionChains, in which case I believe the sensible behavior
> is to traverse multiple lists of L2Insertions (as opposed to just those of
> the InsertionChain with earliest position).
One idea that was floated in the past by Guillermo (in another context
but applicable here), is to add marking to our rules. With this we
could have a classification chain that gets evaluated before the
l2insertion chain. This marking chain would classify the packet as it
traversed the simulation, like
if proto is tcp and port is 22 mark 0xdeadbeef

Then the l2insertion chain could have one set of rules for when mark
0xdeadbeef is present, another for when another mark is present,
another for when there's no mark.

As a bonus, we could then also route based on marks, so active-active
vpn becomes possible.

> how much would the underlying implementation (translation to Redirect Rules)
> have to change? From playing with the code last year, my feeling was that
> the translation was complex and brittle even without classifiers (which adds
> the possibility of satisfying multiple separate chains of insertions). My
> gut feeling is that any re-write/enhancement should include dropping the
> Redirect Rules in favor of modeling L2Insertion directly in MidoNet Agent's
> simulation. As we discussed before, this would allow the simulation to
> pre-compute ALL the steps in the chain and pre-install the corresponding
> flows in all the right peer Agents.
If we're going to modify this code, I would suggest making it so that
we run the full simulation for all steps. I think this would greatly
simplify the translation, since we wouldn't have to worry about trying
to reinsert packages coming back from the service function into the
correct point in simulation. Once we have that, I'm not sure how
necessary or useful it would be to directly model l2insertion in the


More information about the OpenStack-dev mailing list