[RFE] Extend l2-extensions-api for flow management

[David Shaughnessy]

The l2-extensions-api that merged in Mitaka allows extensions of the OvSNeutronAgent to use the OvS flow table.
This introduces a new challenge of interoperability between extensions creating flows.
As the OvS flow table matches traffic to flows based on packet characteristics in the order of priority assigned to the flow,
it will inevitably result in two extensions using flows that will block the extension that uses the lower priority flows.
Therefore a flow manager or flow pipeline is necessary that will prevent extensions from blocking other flows from matching traffic.

[Margaret Frances (margaret-frances)]

We may want to consider assigning separate table(s) and separate meta-data fields to each feature. This would result in something like (removing cruft for clarity) what is seen in the top-most table0 flow, and the table10 flow :

  cookie=abcd, table=0, priority=65535,reg2=0x0,in_port=6 actions=resubmit(,10)
  cookie=1234, table=0, priority=10,arp,in_port=6 actions=resubmit(,24)
  cookie=1234, table=0, priority=0 actions=NORMAL

  cookie=abcd, table=10, priority=0 actions=load:0x37->NXM_NX_REG2[0..5],mod_nw_tos:104,resubmit(,0)

  cookie=1234, table=24, priority=2,arp,in_port=6,arp_spa=10.251.2.136 actions=NORMAL

All features can then use the highest priority in table0 without contention.

[Armando Migliaccio (armando-migliaccio)]

Solving a flow multi writer problem (a la Network Intent Composition) is probably beyond what we can be realistically achieved in Neutron, but we should try and figure out a way to minimize/document/alert contention and leave resolution out of scope.

[David Shaughnessy (david-shaughnessy)]

@Margaret

I agree. It's the best way to isolate different project's/extension's flows from each other. What I'm thinking at the moment is if the projects or extensions should be aware this is happening. If they do not need to be aware then most of the work will be centered in Neutron. Using the cookie that each project/extension automatically passes when creating a flow ( https://review.openstack.org/#/c/267591/ ) to redirect flows from table 0 to other available tables with a resubmit from table 0 to that assigned table (It would also need to resubmit back to table 0 whenever it would use NORMAL or another action that sends traffic).

An approach which would require more active participation from projects and extensions would be to create a pipeline that projects would add their flows to and the pipeline would sort them to avoid clashing.

A more simple approach would be to take the example of the OvS firewall and assign tables:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/common/constants.py#L53

However I do believe being able to dynamically assign tables should be possible so it could also be part of the OvsAgentExtensionApi class, which could dynamically allocate unused tables to projects which need to use it to gain access to the flow table anyway.

@Armando

I believe if it can be done as for the moment there are 5 projects or extensions that required the use flow table with different use-cases for each. I've had some interactions with members from each community and I think we can find a resolution even if it results in the last approach I listed above.

[Miguel Angel Ajo (mangelajo)]

I agree, we can find a solution.

I'm proposing something sightly different to the jump to table, and resubmit to table 0 strategy (which of course, works), for several reasons:

1) You get clear insertion points on the egress and ingress path of a packet.
2) You can draw your flow tables with inspection tools as a graph.
3) I suspect it's more performant on the first hit (until ovs builds a megaflow entry in kernel) because for each transition you just have a jump instead of two.

https://review.openstack.org/314106

I need to send another version today, and let's discuss over there.

Cheers.

[Armando Migliaccio (armando-migliaccio)]

The need is clear, and this sounds like the continuation of [1], and due to the complexity of the problem at end, this calls for a full blown spec where we can flesh out the details and the extent of the work to pursue in the Newton timeframe. It seems that Ajo is working on [2], let's make sure we agree that the devref format is the best way forward.

[1] https://blueprints.launchpad.net/neutron/+spec/l2-api-extensions
[2] https://review.openstack.org/#/c/314106/

[Miguel Angel Ajo (mangelajo)]

It's not a user facing feature, but it's a developer API element that should be good enough (or extensible enough) to solve our current and future problem in this area. I'm perfectly fine with moving this into a spec, if we all agree.

[cathy Hong Zhang (cathy-h-zhang)]

Yes, I think we should move to a spec. I assume the spec for review is https://review.openstack.org/#/c/314106/?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/320439

[OpenStack Infra (hudson-openstack)]

Change abandoned by Miguel Angel Ajo (<email address hidden>) on branch: master
Review: https://review.openstack.org/314106
Reason: https://review.openstack.org/320439

[Miguel Angel Ajo (mangelajo)]

Ok, it's been moved to a spec now.

Let's iterate over it here: https://review.openstack.org/320439

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/323963

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/323963
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Ihar Hrachyshka (ihar-hrachyshka)]

I hear this initiative may loose its approver. We may need to revisit if we still have both authors as well as reviewers lined up to support the initiative.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https://review.openstack.org/320439
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https://review.openstack.org/323963
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/320439
Committed: https://git.openstack.org/cgit/openstack/neutron-specs/commit/?id=4ad0c2683dd0bcfab7588e041b0eb8542a3c5174
Submitter: Jenkins
Branch: master

commit 4ad0c2683dd0bcfab7588e041b0eb8542a3c5174
Author: Miguel Angel Ajo <email address hidden>
Date: Tue May 24 15:12:04 2016 +0200

    L2 extension ovs flow management

    This spec defines the work to be done around the ovs flow management
    to allow healthy interoperability of l2 extensions that need to manipulate
    OpenFlow tables.

    Change-Id: I6f9483b920cb095515aefad35a25e59fcc53be63
    Related-bug: 1563967

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Shaughnessy (<email address hidden>) on branch: master
Review: https://review.opendev.org/323963

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.