[RFE] Extend l2-extensions-api for flow management
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| neutron |
Wishlist
|
Rui Zang |
Bug Description
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.
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/
Changed in neutron: | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
@Margaret
I agree. It's the best way to isolate different project'
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:/
However I do believe being able to dynamically assign tables should be possible so it could also be part of the OvsAgentExtensi
@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) wrote : | #4 |
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:/
I need to send another version today, and let's discuss over there.
Cheers.
tags: | added: ovs |
Changed in neutron: | |
assignee: | nobody → Miguel Angel Ajo (mangelajo) |
status: | Confirmed → In Progress |
Changed in neutron: | |
status: | In Progress → Confirmed |
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:/
[2] https:/
Changed in neutron: | |
status: | Confirmed → Triaged |
tags: |
added: rfe-approved removed: rfe |
Changed in neutron: | |
milestone: | none → newton-1 |
Miguel Angel Ajo (mangelajo) wrote : | #6 |
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) wrote : | #7 |
Yes, I think we should move to a spec. I assume the spec for review is https:/
Related fix proposed to branch: master
Review: https:/
Change abandoned by Miguel Angel Ajo (<email address hidden>) on branch: master
Review: https:/
Reason: https:/
Miguel Angel Ajo (mangelajo) wrote : | #10 |
Ok, it's been moved to a spec now.
Let's iterate over it here: https:/
Fix proposed to branch: master
Review: https:/
Changed in neutron: | |
assignee: | Miguel Angel Ajo (mangelajo) → David Shaughnessy (david-shaughnessy) |
status: | Triaged → In Progress |
Changed in neutron: | |
milestone: | newton-1 → newton-2 |
Changed in neutron: | |
milestone: | newton-2 → newton-3 |
Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https:/
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.
Changed in neutron: | |
milestone: | newton-3 → newton-rc1 |
Changed in neutron: | |
milestone: | newton-rc1 → ocata-1 |
Changed in neutron: | |
milestone: | ocata-1 → ocata-2 |
Changed in neutron: | |
milestone: | ocata-2 → ocata-3 |
Changed in neutron: | |
milestone: | ocata-3 → ocata-rc1 |
Changed in neutron: | |
milestone: | ocata-rc1 → pike-1 |
Ihar Hrachyshka (ihar-hrachyshka) wrote : | #14 |
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.
Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https:/
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.
Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https:/
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.
Changed in neutron: | |
milestone: | pike-1 → pike-2 |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 4ad0c2683dd0bcf
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: I6f9483b920cb09
Related-bug: 1563967
Changed in neutron: | |
assignee: | David Shaughnessy (david-shaughnessy) → Rui Zang (rui-zang) |
Change abandoned by David Shaughnessy (<email address hidden>) on branch: master
Review: https:/
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) 10,arp, in_port= 6 actions= resubmit( ,24)
cookie=1234, table=0, priority=
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.