Raghavan, You are describing questions relate to the 'arbiter' solution to coexistence of applications. Having watched attempts at solving those solutions for years I have come to personally be of

1) Lets consider that we merge flows having conflict actions and programming the action that belong to the flow of higher priority. This becomes complex when admin wanted to re-prioritize. 2)

Thank you Sam I think there is a fundamental difference in our setups. I generated an archetype based on

I have a few questions – excuse me if they are trivial; - When the flows are merged, how can the actions be merged if they are conflicting? - Would there be a way for admins to

That depends... I really *do* want a discussion to look at the 'stack' approach rather than the 'arbiter' approach. My read of

Do we want to merge these 2 discussions or keep them separate? https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution Also - it will be good to have some of these

Denis, all you need for an OVSDB connection is the odl-ovsdb-southbound-impl. In that case you can point a ovsdb node to ODL via ovs-vsctl set manager and ODL will track it. If you wan the restconf

Hi, What I'am trying to figure out is which feature of ovsdb do I *need* to install for establishing a n ovsdb connection. Taking odl-ovsdb-openstack as an example: It requires only

I've got a session here: https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#Coexistence_of_multiple_projects_in_the_same_pipeline_via_a_.27stack.27_approach To look at solving this problem via a

BTW, we should include Tony Tkacik in these dicussions, as he and I had a good discussion on how we could approach this holistically as a community around the two big issues: table0 Pipeline

Yi, I appreciate the thought, but Brady is correct. The nice part of the cohesive architecture is that the GBP OfOverlay renderer can do more actions than just CHAIN, and the SFC project should

Yi, Putting the SFC sfcofl2 in GBP is not a good idea. SFC should work stand-alone without GBP, and moving the sfcofl2 will break that. Also, we're considering a VPN+SFC integration in

Hi, all I put my proposed solution inhttps://wiki.opendaylight.org/view/OF_pipeline, please refer to it for details, maillist blocked my last post.

Hi, all I put my proposed solution inhttps://wiki.opendaylight.org/view/OF_pipeline, please refer to it for details, maillist blocked my last post.

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

Hi, Brady I think we should move sfcofl2 to GBP openflow renderer, I think we should only have one openflow renderer, it should be GBP ofoverlay. Keith said GBP Neutron mapper has implemented part

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”

Yi, 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

Folks- Just wanted to give an update on this work - it now looks like this change is going to slip as I'd like to be as sure as I can be that we will only need to do it once during the Be cycle and I

i agree maruti, not be feasible to combine the 2 functions under the ML2 mechanism driver, as the driver will follow its own growth path, driven by the openstack community. unifying at the provider