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

[Ivan Kelly]

> 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
simulation.

-Ivan

__
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

Re: [openstack-dev] [midonet] ping cannot work from VM to external gateway IP.

[Ivan Kelly]

>>> I cannot ping from VM to external gateway IP (which is set up at the
>>> physical router side).
This is a known issue. We have it in the backlog to fix but noone has
gotten to it yet.

-Ivan

__
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

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

[Ivan Kelly]

+1 for #2

On Tue, Dec 1, 2015 at 10:57 AM, Sandro Mathys  wrote:
> Hi,
>
> Our IRC channels have been neglected for a long time, and as a result
> we lost ownership of #midonet-dev, which is now owner by
> freenode-staff. In theory, it should be very easy to get ownership
> back, particularly since we still own #midonet. But in reality, it
> seems like none of the freenode staff feel responsible for these
> requests, so we still aren't owners after requesting it for 3 weeks
> already.
>
> Therefore, Toni Segura suggested we just ditch it and move to
> #openstack-midonet instead.
>
> However, several people have also said we don't need two channels,
> i.e. we should merge #midonet and #midonet-dev.
>
> So, here's three proposals:
>
> Proposal #1:
> * keep #midonet
> * replace #midonet-dev with #openstack-midonet
>
> Proposal #2:
> * keep #midonet
> * merge #midonet-dev into #midonet
>
> Proposal #3:
> * replace both #midonet and #midonet-dev with #openstack-midonet
>
> I don't have any strong feelings for any of the proposals, but suggest
> we go with proposal #2. Traffic in both #midonet and #midonet-dev is
> rather low, so one channel should do - there's way busier OpenStack
> channels out there. Furthermore, #midonet is shorter than
> #openstack-midonet and already established. I also think people will
> rather look in #midonet than #openstack-midonet if they're looking for
> us.
>
> Thoughts?
>
> Cheers,
> Sandro
>
> __
> 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