Date   

Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Edward Warnicke <hagbard@...>
 

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 the opinion
that:

a)  There are no good solutions to those problems - the entire approach of 'merging' flows outside of a monolithic application is unlikely to work
b)  I strongly suspect application authors will be unwilling to accept voluntarily an 'arbiter' that could alter or drop their requested flows in ways that might adversely effect their application.

Which is to say... I think that trying to work at the 'assembly language' level (flows) to solve coexistence is to granular to make meaningful usable progress.

What I am proposing is that we instead 'uplevel' coexistence to the 'stack' layer.  We are all familiar with legacy networks stack (L4, L3, L2 etc).  Clearly that particular choice of stack
is not what we would choose for SDN.  But imagine something *roughly* like this:

1)  Each layer in the new 'stack' (Policy, SFC, Overlay) gets its own set of tables for its pipeline.
2)  We have a set of *simple* *clearly defined* rules for handoff
     (might be as simple as the 'Policy' layer being able to get the first table in the SFC layer and using a GOTO table to punt
       to that next pipeline).

No arbiter is merging (dropping or rewriting) flows.  An implementation for a pipeline gets the flows they ask for.  But it allows for composition of independent application pipelines.

*This* approach (especially with some of the neat ideas Keith has to make it even simpler and easier, which I will leave to him to describe) is something that I believe personally we
*can* make work, and that I believe *can* get voluntary adoption.

Ed


On Fri, Jul 24, 2015 at 9:16 AM, <C_Venkataraghavan@...> wrote:

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 configure the application priority during conflicts?

-          Wouldn’t it be better to maintain both flows without merging, but tagging the flows with some context info? For e.g., tagging all App1 related flows in all tables using a common cookie?

 

Raghavan

 

From: Edward Warnicke [mailto:hagbard@...]
Sent: Friday, July 24, 2015 9:17 PM
To: Abhijit Kumbhare
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N; Sethuraman, Hariharan; Venkataraghavan, C; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

My read of https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution was that it was looking at the 'arbiter' approach.

(as a matter of personal opinion, I think the 'arbiter' approach is a dead end)

 

Ed

 

On Fri, Jul 24, 2015 at 8:17 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Do we want to merge these 2 discussions or keep them separate?

 

 

Also - it will be good to have some of these sessions earlier in the morning so that remote folks from India, etc. will be able to participate. e.g. there is a session on OpenFlow clustering which I believe Muthu plans to attend - and this OF Pipeline session that some others like Hema, etc. want to attend. So should these 2 sessions on 2 different mornings?

 

On Fri, Jul 24, 2015 at 6:40 AM, Edward Warnicke <hagbard@...> wrote:

I've got a session here:

 

 

To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 

would be a good venue for the discussion?

 

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into

the discussion.

 

Ed

 

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:

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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

 

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

 

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

 

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>

Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 support multiple classifiers feeding into SFCOFL2.

 

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

 

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.

 

 

 

 

 

From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady

On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 



_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 

 


_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 

 



Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Hariharan_Sethuraman@...
 

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)      In next scenario, the match-fields of flow 1 may be a subset of flow 2’s match-fields. Not sure if this falls under conflict definition of this project.

 

Thanks,

Hari

 

From: Venkataraghavan, C
Sent: Friday, July 24, 2015 9:46 PM
To: Edward Warnicke; Abhijit Kumbhare
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N; Sethuraman, Hariharan; Prem sankar G
Subject: RE: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 configure the application priority during conflicts?

-          Wouldn’t it be better to maintain both flows without merging, but tagging the flows with some context info? For e.g., tagging all App1 related flows in all tables using a common cookie?

 

Raghavan

 

From: Edward Warnicke [mailto:hagbard@...]
Sent: Friday, July 24, 2015 9:17 PM
To: Abhijit Kumbhare
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N; Sethuraman, Hariharan; Venkataraghavan, C; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

My read of https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution was that it was looking at the 'arbiter' approach.

(as a matter of personal opinion, I think the 'arbiter' approach is a dead end)

 

Ed

 

On Fri, Jul 24, 2015 at 8:17 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Do we want to merge these 2 discussions or keep them separate?

 

 

Also - it will be good to have some of these sessions earlier in the morning so that remote folks from India, etc. will be able to participate. e.g. there is a session on OpenFlow clustering which I believe Muthu plans to attend - and this OF Pipeline session that some others like Hema, etc. want to attend. So should these 2 sessions on 2 different mornings?

 

On Fri, Jul 24, 2015 at 6:40 AM, Edward Warnicke <hagbard@...> wrote:

I've got a session here:

 

 

To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 

would be a good venue for the discussion?

 

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into

the discussion.

 

Ed

 

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:

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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

 

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

 

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

 

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>

Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 support multiple classifiers feeding into SFCOFL2.

 

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

 

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.

 

 

 

 

 

From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady

On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 

 

_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 

 


_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 

 


Re: feature required for ovsdb connection

Baudinot Denis Gerold (badi) <badi@...>
 

Thank you Sam

I think there is a fundamental difference in our setups. I generated an archetype based on this:

https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype

And then I subsequently added dependencies and features as I required them.

Also I actually never get info from the "config-pusher" in my karaf.log. Instead I get an exception some time after I started karaf.


Exception in thread "config-pusher" java.lang.SecurityException: Insufficient roles/credentials for operation
at org.apache.karaf.management.KarafMBeanServerGuard.handleInvoke(KarafMBeanServerGuard.java:289)
at org.apache.karaf.management.KarafMBeanServerGuard.invoke(KarafMBeanServerGuard.java:85)
at org.apache.karaf.management.boot.KarafMBeanServerBuilder$MBeanInvocationHandler.invoke(KarafMBeanServerBuilder.java:63)
at com.sun.proxy.$Proxy0.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.MXBeanProxy$InvokeHandler.invoke(MXBeanProxy.java:150)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:167)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:252)
at com.sun.proxy.$Proxy15.beginConfig(Unknown Source)
at org.opendaylight.controller.config.util.ConfigRegistryJMXClient.beginConfig(ConfigRegistryJMXClient.java:96)
at org.opendaylight.controller.netconf.confignetconfconnector.transactions.TransactionProvider.getTestTransaction(TransactionProvider.java:120)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.test(EditConfig.java:109)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.executeTests(EditConfig.java:96)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.getResponseInternal(EditConfig.java:75)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.handleWithNoSubsequentOperations(EditConfig.java:308)
at org.opendaylight.controller.netconf.util.mapping.AbstractLastNetconfOperation.handle(AbstractLastNetconfOperation.java:33)
at org.opendaylight.controller.netconf.util.mapping.AbstractNetconfOperation.handle(AbstractNetconfOperation.java:100)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.sendRequestGetResponseCheckIsOK(ConfigPusherImpl.java:342)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.pushConfig(ConfigPusherImpl.java:293)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.pushConfigWithConflictingVersionRetries(ConfigPusherImpl.java:135)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.internalPushConfigs(ConfigPusherImpl.java:103)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.process(ConfigPusherImpl.java:76)
at org.opendaylight.controller.netconf.persist.impl.osgi.ConfigPersisterActivator$InnerCustomizer$1.run(ConfigPersisterActivator.java:181)
at java.lang.Thread.run(Thread.java:745)

I didn't find an explanation for this yet

Regards
Denis
________________________________________
Von: Sam Hague [shague@...]
Gesendet: Freitag, 24. Juli 2015 17:09
An: Baudinot Denis Gerold (badi)
Cc: ovsdb-dev@...
Betreff: Re: [ovsdb-dev] feature required for ovsdb connection

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 component then you use the odl-ovsdb-southbound-impl-ui (which includes odl-ovsdb-southbound-impl) and you can also issue restconf calls to create the connections and query the model.

There have been issues where certain models start at different times and it causes issues for dependent models. You might be hitting that case. In my first test of the lithium release to just install the odl-ovsdb-southbound-impl feature there was an exception listed on the console converning models and the listening port was not opened. A second test it worked fine. So it's possible you might be hitting that.

The karaf logs should have the following if everything worked correctly:

2015-07-24 11:01:03,677 | INFO | config-pusher | SouthboundProvider | 184 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.Lithium | SouthboundProvider Session Initiated
2015-07-24 11:01:03,683 | INFO | config-pusher | OvsdbDataChangeListener | 184 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.Lithium | Registering OvsdbNodeDataChangeListener
2015-07-24 11:01:03,816 | INFO | entLoopGroup-5-1 | LoggingHandler | 119 - io.netty.common - 4.0.26.Final | [id: 0x8e720879] REGISTERED
2015-07-24 11:01:03,816 | INFO | entLoopGroup-5-1 | LoggingHandler | 119 - io.netty.common - 4.0.26.Final | [id: 0x8e720879] BIND(0.0.0.0/0.0.0.0:6640)

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: ovsdb-dev@...
Sent: Friday, July 24, 2015 10:24:41 AM
Subject: [ovsdb-dev] feature required for ovsdb connection

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
odl-ovsdb-southbound-impl-ui as a feature from ovsdb (except netvirt bundles
which I assume are not responsible for this).

After installing the odl-ovsdb-southbound-impl-ui feature I checked if
something is listening to :6640 because OVS was not able to connect (via
set-manager) there. And apparently nothing is indeed listeing to that port.

What am I missing here?

Regards & Thanks
Denis

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Venkataraghavan Chetput
 

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 configure the application priority during conflicts?

-          Wouldn’t it be better to maintain both flows without merging, but tagging the flows with some context info? For e.g., tagging all App1 related flows in all tables using a common cookie?

 

Raghavan

 

From: Edward Warnicke [mailto:hagbard@...]
Sent: Friday, July 24, 2015 9:17 PM
To: Abhijit Kumbhare
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N; Sethuraman, Hariharan; Venkataraghavan, C; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

My read of https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution was that it was looking at the 'arbiter' approach.

(as a matter of personal opinion, I think the 'arbiter' approach is a dead end)

 

Ed

 

On Fri, Jul 24, 2015 at 8:17 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Do we want to merge these 2 discussions or keep them separate?

 

 

Also - it will be good to have some of these sessions earlier in the morning so that remote folks from India, etc. will be able to participate. e.g. there is a session on OpenFlow clustering which I believe Muthu plans to attend - and this OF Pipeline session that some others like Hema, etc. want to attend. So should these 2 sessions on 2 different mornings?

 

On Fri, Jul 24, 2015 at 6:40 AM, Edward Warnicke <hagbard@...> wrote:

I've got a session here:

 

 

To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 

would be a good venue for the discussion?

 

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into

the discussion.

 

Ed

 

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:

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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

 

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

 

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

 

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>

Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 support multiple classifiers feeding into SFCOFL2.

 

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

 

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.

 

 

 

 

 

From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady

On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 



_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 

 


_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 

 


Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Edward Warnicke <hagbard@...>
 

That depends... I really *do* want a discussion to look at the 'stack' approach rather than the 'arbiter' approach.
My read of https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution was that it was looking at the 'arbiter' approach.
(as a matter of personal opinion, I think the 'arbiter' approach is a dead end)

Ed

On Fri, Jul 24, 2015 at 8:17 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Do we want to merge these 2 discussions or keep them separate?


Also - it will be good to have some of these sessions earlier in the morning so that remote folks from India, etc. will be able to participate. e.g. there is a session on OpenFlow clustering which I believe Muthu plans to attend - and this OF Pipeline session that some others like Hema, etc. want to attend. So should these 2 sessions on 2 different mornings?

On Fri, Jul 24, 2015 at 6:40 AM, Edward Warnicke <hagbard@...> wrote:
I've got a session here:


To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 
would be a good venue for the discussion?

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into
the discussion.

Ed

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:
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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 support multiple classifiers feeding into SFCOFL2.

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.





From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev





Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Abhijit Kumbhare
 

Do we want to merge these 2 discussions or keep them separate?


Also - it will be good to have some of these sessions earlier in the morning so that remote folks from India, etc. will be able to participate. e.g. there is a session on OpenFlow clustering which I believe Muthu plans to attend - and this OF Pipeline session that some others like Hema, etc. want to attend. So should these 2 sessions on 2 different mornings?

On Fri, Jul 24, 2015 at 6:40 AM, Edward Warnicke <hagbard@...> wrote:
I've got a session here:


To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 
would be a good venue for the discussion?

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into
the discussion.

Ed

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:
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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 support multiple classifiers feeding into SFCOFL2.

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.





From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev




Re: feature required for ovsdb connection

Sam Hague
 

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 component then you use the odl-ovsdb-southbound-impl-ui (which includes odl-ovsdb-southbound-impl) and you can also issue restconf calls to create the connections and query the model.

There have been issues where certain models start at different times and it causes issues for dependent models. You might be hitting that case. In my first test of the lithium release to just install the odl-ovsdb-southbound-impl feature there was an exception listed on the console converning models and the listening port was not opened. A second test it worked fine. So it's possible you might be hitting that.

The karaf logs should have the following if everything worked correctly:

2015-07-24 11:01:03,677 | INFO | config-pusher | SouthboundProvider | 184 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.Lithium | SouthboundProvider Session Initiated
2015-07-24 11:01:03,683 | INFO | config-pusher | OvsdbDataChangeListener | 184 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.Lithium | Registering OvsdbNodeDataChangeListener
2015-07-24 11:01:03,816 | INFO | entLoopGroup-5-1 | LoggingHandler | 119 - io.netty.common - 4.0.26.Final | [id: 0x8e720879] REGISTERED
2015-07-24 11:01:03,816 | INFO | entLoopGroup-5-1 | LoggingHandler | 119 - io.netty.common - 4.0.26.Final | [id: 0x8e720879] BIND(0.0.0.0/0.0.0.0:6640)

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: ovsdb-dev@...
Sent: Friday, July 24, 2015 10:24:41 AM
Subject: [ovsdb-dev] feature required for ovsdb connection

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
odl-ovsdb-southbound-impl-ui as a feature from ovsdb (except netvirt bundles
which I assume are not responsible for this).

After installing the odl-ovsdb-southbound-impl-ui feature I checked if
something is listening to :6640 because OVS was not able to connect (via
set-manager) there. And apparently nothing is indeed listeing to that port.

What am I missing here?

Regards & Thanks
Denis

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


feature required for ovsdb connection

Baudinot Denis Gerold (badi) <badi@...>
 

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 odl-ovsdb-southbound-impl-ui as a feature from ovsdb (except netvirt bundles which I assume are not responsible for this).

After installing the odl-ovsdb-southbound-impl-ui feature I checked if something is listening to :6640 because OVS was not able to connect (via set-manager) there. And apparently nothing is indeed listeing to that port.

What am I missing here?

Regards & Thanks
Denis


Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Edward Warnicke <hagbard@...>
 

I've got a session here:


To look at solving this problem via a 'stack' oriented (rather than arbiter oriented solution) that I believe is quite in line with your ideas Keith, perhaps that 
would be a good venue for the discussion?

It also seems to me that in addition to the two issues you listed above (table0 and co-existence) you also have 'handoff between stack layers' to work into
the discussion.

Ed

On Fri, Jul 24, 2015 at 6:33 AM, alagalah <alagalah@...> wrote:
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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 support multiple classifiers feeding into SFCOFL2.

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.





From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev



Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

alagalah <alagalah@...>
 

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 co-existance (which I want to solve via namespacing with metadata and recirculation ID)

We should definitely propose this as an unconference session for the ODL Summit. I’m happy that this is a “baby steps” approach, as I’d like to test and validate my idea across both the GBP OfOverlay and SFCOFL2 pipelines, but Tony has a more broad longer term view which addresses a number of different issues (such as how to translate a generalised ideal OF pipeline onto a constrained hardware platform etc).

Note: This doesn’t have to be just one session. There could be a discussion at a broader [OFP <-> consumers of …] level discussion, and a more tactical GBP/SFC/netvirt general pipeline discussion too.

From: alagalah <alagalah@...>
Date: Friday, July 24, 2015 at 6:20 AM
To: Brady Allen Johnson <brady.allen.johnson@...>, "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 support multiple classifiers feeding into SFCOFL2.

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.





From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

alagalah <alagalah@...>
 

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 support multiple classifiers feeding into SFCOFL2.

One thing I’d like to propose for the SFC Be Release Plan that I can commit to, is working on a OF OVS based classifier for SFC. This would be a simple matter for our team who currently works on both GBP and SFC to do, as it would leverage a lot of the existing GBP OfOverlay pipeline, but in a much simple fashion (as it wouldn’t have to understand policy etc).

Specifically to your point, co-existance is something we have started working on. Table Offsets won’t solve everything, mainly due to pipeline exit/re-entry (recirc won’t solve this by itself either). I’m working on a namespacing idea, but haven’t had time to code it up, but will be proposing this idea as something I can commit to for both RPs. Clearly welcome anyone want to jump in and help, and I know there are many people with differing ideas on how this should be done. (See Ed’s “overlay” sessions at ODL Summit for instance). 

Brady, sorry if I am behind on emails, but when were you planning on having SFC Be RP discussions? 

For GBP I am having an unconference at the ODL Summit and was planning on scheduling two more WebEx meetings (at 12 shifted times for multi-timezone friendliness) to discuss the GBP Be RP.





From: Brady Allen Johnson <brady.allen.johnson@...>
Organization: Ericsson AB
Date: Friday, July 24, 2015 at 5:30 AM
To: "Yang, Yi Y" <yi.y.yang@...>, Abhijit Kumbhare <abhijitkoss@...>
Cc: opendaylight sfc <sfc-dev@...>, "lacp-dev@..." <lacp-dev@...>, openflowplugin-dev <openflowplugin-dev@...>, Manohar SL <manohar.sl@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Gaurav Bhagwani <gaurav.bhagwani@...>, Prakash N N <prakash.n.n@...>, "Hariharan_Sethuraman@..." <Hariharan_Sethuraman@...>, Hema Gopalkrishnan <hema.gopalkrishnan@...>, "C_Venkataraghavan@..." <C_Venkataraghavan@...>, Prem sankar G <prem.sankar.g@...>, Thomas Bachman <bachman@...>, alagalah <alagalah@...>
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Brady Allen Johnson <brady.allen.johnson@...>
 

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 Beryllium, which wont work if SFC doesnt have the capability to render flows.

Regards,

Brady


On 07/24/2015 04:48 AM, Yang, Yi Y wrote:

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 



Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

Hi, all

 

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

 

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.

 

Regards,

Prem

 

From: Brady Allen Johnson
Sent: Thursday, July 23, 2015 9:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady


Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

Hi, all

 

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

 

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.

 

Regards,

Prem

 

From: Brady Allen Johnson
Sent: Thursday, July 23, 2015 9:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 



_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 


Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

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.

 

Regards,

Prem

 

From: Brady Allen Johnson
Sent: Thursday, July 23, 2015 9:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 



_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 


Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

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 of OVSDB netvirt openflow pipeline. Obviously GBP has some duplicate work with OVSDB netvirt, I think we should fix them.

 

From my view, I think we can move low layer of GBP ofoverlay into openflowplugin. That is its best home J

 

I’ll suggest two possible solutions later, we can discuss them here, and hope you can take them into Opendaylight Summit for more discussion.

 

From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 12:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 


Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Prem sankar G <prem.sankar.g@...>
 

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.

 

Regards,

Prem

 

From: Brady Allen Johnson
Sent: Thursday, July 23, 2015 9:46 AM
To: 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@...; Prem sankar G; Thomas Bachman; Keith Burns
Subject: Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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

Regards,

Brady

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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 




_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

 


Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Brady Allen Johnson <brady.allen.johnson@...>
 

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

Regards,

Brady


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; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; 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.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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 ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

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.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

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.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

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:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

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

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

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
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

 

 



_______________________________________________
sfc-dev mailing list
sfc-dev@...
https://lists.opendaylight.org/mailman/listinfo/sfc-dev


Re: Pre-announcement of pending NN YANG model revision

Ryan Moats <rmoats@...>
 

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 keep finding cruft that needs to be cleaned.

Thanks, and please stay tuned...

Ryan


Re: L2gw with ODL

daya k
 

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 level (via the neutron northbound) is sufficient for us to implement functionality across core as well as non-core resources.

thanks,
daya



From: "Kamat, Maruti Haridas" <maruti.kamat@...>
To: Dayavanti Gopal Kamath <dayavanti.gopal.kamath@...>; Hema Gopalkrishnan <hema.gopalkrishnan@...>; Vishal Thapar <vishal.thapar@...>; "Kenchappa, Ravindra" <ravindra.kenchappa@...>; "Suryanarayanan, Aswin" <aswin.suryanarayanan@...>; 'Anil Vishnoi' <vishnoianil@...>; 'Flavio Fernandes' <ffernand@...>; 'Sam Hague' <shague@...>; 'Chris Wright' <chrisw@...>; 'Kyle Mestery' <mestery@...>; Prem sankar G <prem.sankar.g@...>; Abhijit Kumbhare <abhijit.kumbhare@...>; Ravi Sundareswaran <ravi.sundareswaran@...>; "Vasudevan, Swaminathan (PNB Roseville)" <swaminathan.vasudevan@...>; "'afredette@...'" <afredette@...>; "Ravi_Sabapathy@..." <Ravi_Sabapathy@...>; "Yapeng.Wu@..." <Yapeng.Wu@...>; "sumit@..." <sumit@...>; "ovsdb-dev@..." <ovsdb-dev@...>
Sent: Wednesday, July 22, 2015 12:17 PM
Subject: [ovsdb-dev] L2gw with ODL

Hi Everyone,
 
  I would like to shed some light on why l2gw logic in OpenStack neutron cannot be a part of the ODL ML2 mechanism driver.
 
  1. The core plugin (today also called ML2 plugin) is designed to handle NB REST APIs only for the core resources (network, subnet and ports). Whenever a CUD operation is performed on these core resources, the core ML2 plugin  invokes the configured mechanism drivers (including the ODL mech driver).
  2. As the L2gw resources (logical l2-gateway and l2-gateway-connections) are not core resources, we introduced a new service plugin in Neutron in Kilo release. Neutron allows core plugin and service plugin to co-exist.
  3. The L2gw service plugin implements NB REST APIs for the logical l2-gateway and l2-gateway-connection resources. These calls do not land in the core plugin (the ODL ML2 plugin).
  4. Today, the L2gw service plugin is implemented (tight coupling) in such a way that it assumes that it has to communicate with an L2gw agent over the RabbitMQ message bus. I am trying to modularize this code to put it in a service plugin’s provider driver (like how LBaaS, or VPNaaS does). The reason: the user can configure the ODL provider driver for the l2gw service plugin so that this driver will proxy the NB calls into ODL REST calls (without needing RabbitMQ bus and the l2gw agent).
  5. The existing ODL mechanism driver for the ODL ML2 plugin will only handle port CUD operations to be sent to the ODL controller.
 
Please let me know if you have any questions, or need any further clarifications.
 
Thanks,
Maruti
 

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


3121 - 3140 of 4855