|
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.
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
Hema, good point, we need to fix
the conflict before a flow is written to MDSAL
data store, but this won’t impact we add this
middle layer into openflowplugin, the reason
to put it to openflowplugin is openflowplugin
is a good hosting place for such middle layer.
You can consider it is a component of
openflowplugin, all the projects will call
APIs from this component to program openflow
tables and flows.
I feel that the openflow plugin
may not the place to detect the flow / table
conflict. When the flow / table request
reaches the openflow plugin, the NSFs /
application would have already configured the
flows and tables in the Config datastore of
md-sal. So, taking any corrective action may
be difficult.
We had proposed that conflict
detection to be done even before the NSFs
/application write to the config datastore.
Any thoughts ?
I’m very glad to hear many guys
have realized this issue, Prem Sankar created
this wiki page https://wiki.opendaylight.org/view/OF_pipeline,
this is a start point, please add other
projects which used openflowplugin so that we
can know how urgent this issue is. As Abhijit
Kumbhare (openflowplugin project lead)
commented, I think openflowplugin is the best
place to implement this, I strongly suggest
Abhijit Kumbhare can help make this become
reality as early as possible, I want to work
on it, but I need to hear your ideas if you
have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the
ODL India forum on similar lines of Flow
Conflict Prevention. Here is the link to the presentation.
We are interested in any
discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
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
toggle quoted message
Show quoted text
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this
won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this
component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application
write to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page
https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that
we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want
to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict
Prevention. Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
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.
toggle quoted message
Show quoted text
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
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.
toggle quoted message
Show quoted text
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
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
Yang, Yi Y <yi.y.yang@...>
toggle quoted message
Show quoted text
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
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
Yang, Yi Y <yi.y.yang@...>
toggle quoted message
Show quoted text
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
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
|
|
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.
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.
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
Hema, good point, we need to
fix the conflict before a flow is written to
MDSAL data store, but this won’t impact we
add this middle layer into openflowplugin,
the reason to put it to openflowplugin is
openflowplugin is a good hosting place for
such middle layer. You can consider it is a
component of openflowplugin, all the
projects will call APIs from this component
to program openflow tables and flows.
I feel that the openflow plugin
may not the place to detect the flow / table
conflict. When the flow / table request
reaches the openflow plugin, the NSFs /
application would have already configured
the flows and tables in the Config datastore
of md-sal. So, taking any corrective action
may be difficult.
We had proposed that conflict
detection to be done even before the NSFs
/application write to the config datastore.
Any thoughts ?
I’m very glad to hear many guys
have realized this issue, Prem Sankar
created this wiki page https://wiki.opendaylight.org/view/OF_pipeline,
this is a start point, please add other
projects which used openflowplugin so that
we can know how urgent this issue is. As
Abhijit Kumbhare (openflowplugin project
lead) commented, I think openflowplugin is
the best place to implement this, I strongly
suggest Abhijit Kumbhare can help make this
become reality as early as possible, I want
to work on it, but I need to hear your ideas
if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in
the ODL India forum on similar lines of Flow
Conflict Prevention. Here is the link to the presentation.
We are interested in any
discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
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.
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.
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
Hema, good point, we need to
fix the conflict before a flow is written to
MDSAL data store, but this won’t impact we
add this middle layer into openflowplugin,
the reason to put it to openflowplugin is
openflowplugin is a good hosting place for
such middle layer. You can consider it is a
component of openflowplugin, all the
projects will call APIs from this component
to program openflow tables and flows.
I feel that the openflow plugin
may not the place to detect the flow / table
conflict. When the flow / table request
reaches the openflow plugin, the NSFs /
application would have already configured
the flows and tables in the Config datastore
of md-sal. So, taking any corrective action
may be difficult.
We had proposed that conflict
detection to be done even before the NSFs
/application write to the config datastore.
Any thoughts ?
I’m very glad to hear many guys
have realized this issue, Prem Sankar
created this wiki page https://wiki.opendaylight.org/view/OF_pipeline,
this is a start point, please add other
projects which used openflowplugin so that
we can know how urgent this issue is. As
Abhijit Kumbhare (openflowplugin project
lead) commented, I think openflowplugin is
the best place to implement this, I strongly
suggest Abhijit Kumbhare can help make this
become reality as early as possible, I want
to work on it, but I need to hear your ideas
if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in
the ODL India forum on similar lines of Flow
Conflict Prevention. Here is the link to the presentation.
We are interested in any
discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
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.
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.
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
Hema, good point, we need to
fix the conflict before a flow is written to
MDSAL data store, but this won’t impact we
add this middle layer into openflowplugin,
the reason to put it to openflowplugin is
openflowplugin is a good hosting place for
such middle layer. You can consider it is a
component of openflowplugin, all the
projects will call APIs from this component
to program openflow tables and flows.
I feel that the openflow plugin
may not the place to detect the flow / table
conflict. When the flow / table request
reaches the openflow plugin, the NSFs /
application would have already configured
the flows and tables in the Config datastore
of md-sal. So, taking any corrective action
may be difficult.
We had proposed that conflict
detection to be done even before the NSFs
/application write to the config datastore.
Any thoughts ?
I’m very glad to hear many guys
have realized this issue, Prem Sankar
created this wiki page https://wiki.opendaylight.org/view/OF_pipeline,
this is a start point, please add other
projects which used openflowplugin so that
we can know how urgent this issue is. As
Abhijit Kumbhare (openflowplugin project
lead) commented, I think openflowplugin is
the best place to implement this, I strongly
suggest Abhijit Kumbhare can help make this
become reality as early as possible, I want
to work on it, but I need to hear your ideas
if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in
the ODL India forum on similar lines of Flow
Conflict Prevention. Here is the link to the presentation.
We are interested in any
discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
Keith Burns <alagalah@...>
Yi,
Pity you can't make it. What is very cool is that between just Ed, Tony and I in separate conversations, all of those options, plus a couple more wrinkles on it to support h/w switches, have been discussed.
I'll make sure that discussions get captured and emailed to the list for follow-up.
My thoughts centre around a namespace type approach, and we need a generally co-ordinated table 0 solution. There are ideas others have I'll let them expand on.
We discussed two possible implementations. But flow conflict detection will be pain point, so far it is just under research, there isn’t a good enough
way to fix this. Option II can avaoid this pain point, but every related project must cooperate and coordinate with each other. Openflowplugin programmer is the layler I suggest, it should be only one entry to program openflow tables and rules, it should provide
high level APIs and uniformly manage all the resources, including table ID, flow ID, flow priority, etc. It can merge multiple flow entries from every projects into a flow entry if possible, welcome your comments and hope you can take them into Opendaylight
Summit for more discussion, I can’t make it.
From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Friday, July 24, 2015 2:07 AM
To: Brady Allen Johnson; Yang, Yi Y; Abhijit Kumbhare
Cc: sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; groupbasedpolicy-dev@...; ovsdb-dev@...; Gaurav Bhagwani; Prakash N N; Hariharan_Sethuraman@...;
Hema Gopalkrishnan; C_Venkataraghavan@...; Thomas Bachman; Keith Burns
Subject: RE: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?
I see other design discussion similar to this topic being proposed. –
-
Common Network Abstraction
-
Co-existence of multiple projects in the same pipeline via a “stack” approach
If there is an agreement, we can look to combine them and have a longer discussion.
Regards,
Prem
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
Yang, Yi Y <yi.y.yang@...>
Brady, for the case we don’t use GBP, we also need to use Openstack, we need to have VNF manager for SF deployment. If we use Openstack Neutron to
create subnet and port and VxLAN tunnel, OVSDB netvirt will handle them and create many Openflow tables, the table and flow conflicts are there, we have to fix them.
toggle quoted message
Show quoted text
From: Brady Allen Johnson [mailto:brady.allen.johnson@...]
Sent: Friday, July 24, 2015 8:30 PM
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,
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.
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.
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
Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store,
but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs
from this component to program openflow tables and flows.
I feel that the openflow plugin may not the place to detect the flow / table conflict.
When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.
We had proposed that conflict detection to be done even before the NSFs /application write
to the config datastore. Any thoughts ?
I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki
page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin
so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible,
I want to work on it, but I need to hear your ideas if you have better ideas.
Hi Yi / Abhijit,
We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention.
Here is the link
to the presentation.
We are interested in any discussion on this topic.
Regards,
Hema.
+ 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.
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
|
|
