Keith Burns <alagalah@...>
toggle quoted message
Show quoted text
Pity you can't make it. What is very cool is that between just Ed, Tony and I in separate conversations, all of those options, plus a couple more wrinkles on it to support h/w switches, have been discussed.
I'll make sure that discussions get captured and emailed to the list for follow-up.
My thoughts centre around a namespace type approach, and we need a generally co-ordinated table 0 solution. There are ideas others have I'll let them expand on.
We discussed two possible implementations. But flow conflict detection will be pain point, so far it is just under research, there isn’t a good enough
way to fix this. Option II can avaoid this pain point, but every related project must cooperate and coordinate with each other. Openflowplugin programmer is the layler I suggest, it should be only one entry to program openflow tables and rules, it should provide
high level APIs and uniformly manage all the resources, including table ID, flow ID, flow priority, etc. It can merge multiple flow entries from every projects into a flow entry if possible, welcome your comments and hope you can take them into Opendaylight
Summit for more discussion, I can’t make it.
From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Friday, July 24, 2015 2:07 AM
To: Brady Allen Johnson; Yang, Yi Y; Abhijit Kumbhare
Cc: sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; groupbasedpolicy-dev@...; ovsdb-dev@...; Gaurav Bhagwani; Prakash N N; Hariharan_Sethuraman@...;
Hema Gopalkrishnan; C_Venkataraghavan@...; Thomas Bachman; Keith Burns
Subject: RE: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?
I see other design discussion similar to this topic being proposed. –
Common Network Abstraction
Co-existence of multiple projects in the same pipeline via a “stack” approach
If there is an agreement, we can look to combine them and have a longer discussion.
Great initiative kicking off this discussion :)
This is something we will definitely have to address in the Beryllium release for the GBP+SFC integration. Keith has been telling me for some time now that its a problem.
I look forward to discussing it with the rest of you next week at the design summit in Santa Clara.
On 07/20/2015 09:36 AM, Yang, Yi Y wrote:
Soory I can’t, because it is 0:00 am next day for me
From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Monday, July 20, 2015 3:09 PM
To: Yang, Yi Y
Cc: Prem sankar G; Hema Gopalkrishnan;
openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani;
groupbasedpolicy-dev@...; Prakash N N
Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?
We can start some discussions around this in today (Monday) 9 am Pacific OpenFlow plugin meeting - which you should be able to attend remotely. Of course we have other topics to cover regarding Beryllium & Helium SR 4.
On Sun, Jul 19, 2015 at 11:59 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Ok, thanks, I can’t attend that in person, but we will have some representatives to attend.
I have created a placeholder for this topic during ODL design discussion summit -
We can use this slot for further brainstorming around this topic.
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?
This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin
meeting (at least for part of the meeting) to discuss more?
As you mention probably some kind of a flow conflict detection and resolution module is needed.
On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info
I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer
in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.
I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry
to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:
Fix table conflict
Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes
Fix multiple master/writer synchronization
Provide high level APIs for simplifying use for consumers
Optimization will be visible for all the users (APIs consumers)
Openflowplugin evolution or update will be invisible for all the users (API consumers)
You can list more items here if you can imagine
Welcome your great ideas and look forward to seeing we can bear fruit.
Table 0: Port Security, Ingress
Table 1: Ingress NAT Mapper
Table 2: Source Mapper
Table 3: Destination Mapper
Table 4: Policy Enforcer
Table 5: Egress NAT Mapper
Table 6: External Mapper
Table 0, Transport Ingress
Table 1, Path Mapper
Table 2, Next Hop
Table 10, Transport Egress
Table 0: Classifier
Table 10: Director
Table 20: Distributed ARP Responder
Table 30: DNAT for inbound floating-ip traffic
Table 40: Egress Acces-control
Table 50: Distributed LBaaS
Table 60: Distributed Virtual Routing (DVR)
Table 70: Layer 3 forwarding/lookup service
Table 80: Layer2 rewrite service
Table 90: Ingress Acces-control
Table 100: SNAT for traffic accessing external network
Table 110: Layer2 mac,vlan based forwarding
openflowplugin-dev mailing list
sfc-dev mailing list