Re: [OpenDaylight Discuss] TWS - call for topics
Hi Kieth:
Another topic to put on the list is for the user stories that have been started by Red Hat. Dave Neary can help you make contact with the right people for that.
Thanks!
Phil
toggle quoted message
Show quoted text
On Sunday, August 2, 2015, alagalah < alagalah@...> wrote: We are sans agenda for the TWS.
There were a lot of interesting topics at the Summit, so I would *think* there’d be a lot of follow on topics. I’ll try and add the relevant –dev lists to my suggestions, hoping it hits the right email filters.
Suggested topics for Aug3 (doesn’t have to be polished, can bounce around between content, just looking to spark conversation). - Overlay with LISP
- Overview of LISP components implemented, how they could be leveraged.
- OF Table Type Patterns (TTP) update
- where is the industry? Adoption?
- In-project documentation and format
- any readout from the session, overview from the session for those that missed it.
- Pipeline co-existance
- Recap of the issue
- Tentatively narrow scope to OVS?
- Clustering
- There were quite a few sessions, any concrete outcomes?
-- Phil Robb
Sr. Director Of Technical Operations OpenDaylight Project (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb
|
|
We are sans agenda for the TWS.
There were a lot of interesting topics at the Summit, so I would *think* there’d be a lot of follow on topics. I’ll try and add the relevant –dev lists to my suggestions, hoping it hits the right email filters.
Suggested topics for Aug3 (doesn’t have to be polished, can bounce around between content, just looking to spark conversation). - Overlay with LISP
- Overview of LISP components implemented, how they could be leveraged.
- OF Table Type Patterns (TTP) update
- where is the industry? Adoption?
- In-project documentation and format
- any readout from the session, overview from the session for those that missed it.
- Pipeline co-existance
- Recap of the issue
- Tentatively narrow scope to OVS?
- Clustering
- There were quite a few sessions, any concrete outcomes?
|
|
Migration of OVS ML2 to ODL ML2 for Neutron
Hi, I had conversations last week with a number of you about this topic, and just wanted to strike while the iron was hot to get it on the Be planning cycle (if any work needs doing). When someone is deciding to use ODL for OpenStack Neutron, my expectation would be that they're not starting from scratch - in all probability, either they are currently using nova-network or they're using the defail OVS ML2 plug-in. Migrating from nova-network to Neutron is already a hairy topic, but migrating an existing cloud from OVS to ODL easily would make it easier to adopt ODL. My understanding before last week was that you didn't have a choice - to migrate to ODL from OVSDB required deleting and reinitialising the ovsdb database on all of the Nova compute nodes, as documented here: https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylightBut in conversation last week, the following procedure was suggested. My question is, can we document and test this, and verify that it works? Migration procesure: 0. Install and start ODL 1. Stop neutron-service (doesn't affect dataplane for existing instances) 2. On each OVS instance: stop and disable neutron-openvswitch-agent 3. Update Neutron config to use ODL mechanism 4. On each OVS instance: set-manager to ODL It'll be important for Neutron to be connected to ODL before setting ODL as the manager for the vswitch, as once you do a set-manager, ODL will write flows to the switches. The contention is, since the compute instances are still connected to OVS, the set-manager will also kick off ovsdb events which will lead to everything converging on a consistent state - ODL will wipe any old flows from the switches, and will rewire instances to the appropriate network IDs, and set all the flows, vlan tags, etc as they should be. Will this work? I'm going to try it out when I get home (in a few days), but I wanted to get something written down & argued about ASAP. Thanks, Dave. -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.comPh: +1-978-399-2182 / Cell: +1-978-799-3338
|
|
Re: DevStack-opendaylight on a multi-node setup
Hi Michal, Thanks for the detailed explanation. The ODL_LOCAL_IP helped define interfaces as we needed. Thanks Badri
toggle quoted message
Show quoted text
From: Michał Skalski [mailto:michal@...] Sent: Friday, July 31, 2015 2:41 AM To: Venkataraghavan, C Cc: Sabapathy, Ravi; vishal.thapar@...; Viswanatha, Badrinath; openstack@...; <ovsdb-dev@...> Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup 2015-07-30 20:37 GMT+02:00 <C_Venkataraghavan@...>: Resending Ravi’s mail with watermark removed. Hi Vishal, (Resending the mail by removing “Internal use” tag) We forgot to mention a detail in our multi-node setup i.e., the overlay used is VxLan (Q_ML2_TENANT_NETWORK_TYPE=vxlan) . When I checked about ODL_PROVIDER_MAPPINGS, it works only with VLAN type of tenant network. How do we attach a physical interface for a vxlan type of tenant network? Regards, Ravi -----Original Message----- From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Vishal Thapar Sent: Thursday, July 30, 2015 1:54 AM To: Viswanatha, Badrinath; openstack@...; ovsdb-dev@... Cc: Venkataraghavan, C Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards, Vishal.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Badrinath_Viswanatha@... Sent: 29 July 2015 11:29 To: openstack@...; ovsdb-dev@... Cc: C_Venkataraghavan@... Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All, We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help 1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ? 2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks Badri
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev _______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Re: DevStack-opendaylight on a multi-node setup
Michał Skalski <michal@...>
toggle quoted message
Show quoted text
Resending Ravi’s mail with watermark removed.
Hi Vishal,
(Resending the mail by removing “Internal use” tag)
We forgot to mention a detail in our multi-node setup i.e., the overlay used is VxLan (Q_ML2_TENANT_NETWORK_TYPE=vxlan)
. When I checked about ODL_PROVIDER_MAPPINGS, it works only with VLAN type of tenant network.
How do we attach a physical interface for a vxlan type of tenant network?
Regards,
Ravi
-----Original Message-----
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Vishal Thapar
Sent: Thursday, July 30, 2015 1:54 AM
To: Viswanatha, Badrinath; openstack@...;
ovsdb-dev@...
Cc: Venkataraghavan, C
Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards,
Vishal.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of
Badrinath_Viswanatha@...
Sent: 29 July 2015 11:29
To: openstack@...;
ovsdb-dev@...
Cc: C_Venkataraghavan@...
Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All,
We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help
1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ?
2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks
Badri
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Re: DevStack-opendaylight on a multi-node setup
Resending Ravi’s mail with watermark removed.
Hi Vishal,
(Resending the mail by removing “Internal use” tag)
We forgot to mention a detail in our multi-node setup i.e., the overlay used is VxLan (Q_ML2_TENANT_NETWORK_TYPE=vxlan)
. When I checked about ODL_PROVIDER_MAPPINGS, it works only with VLAN type of tenant network.
How do we attach a physical interface for a vxlan type of tenant network?
Regards,
Ravi
toggle quoted message
Show quoted text
-----Original Message-----
From: ovsdb-dev-bounces@... [ mailto:ovsdb-dev-bounces@...] On Behalf Of Vishal Thapar
Sent: Thursday, July 30, 2015 1:54 AM
To: Viswanatha, Badrinath; openstack@...;
ovsdb-dev@...
Cc: Venkataraghavan, C
Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards,
Vishal.
From: ovsdb-dev-bounces@... [ mailto:ovsdb-dev-bounces@...] On Behalf Of
Badrinath_Viswanatha@...
Sent: 29 July 2015 11:29
To: openstack@...;
ovsdb-dev@...
Cc: C_Venkataraghavan@...
Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All,
We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help
1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ?
2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks
Badri
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Re: DevStack-opendaylight on a multi-node setup
Dell - Internal Use - Confidential Hi Vishal, (Resending the mail by removing “Internal use” tag) We forgot to mention a detail in our multi-node setup i.e., the overlay used is VxLan (Q_ML2_TENANT_NETWORK_TYPE=vxlan) . When I checked about ODL_PROVIDER_MAPPINGS, it works only with VLAN type of tenant network. How do we attach a physical interface for a vxlan type of tenant network? Regards, Ravi
toggle quoted message
Show quoted text
-----Original Message----- From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Vishal Thapar Sent: Thursday, July 30, 2015 1:54 AM To: Viswanatha, Badrinath; openstack@...; ovsdb-dev@... Cc: Venkataraghavan, C Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards, Vishal.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Badrinath_Viswanatha@... Sent: 29 July 2015 11:29 To: openstack@...; ovsdb-dev@... Cc: C_Venkataraghavan@... Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All, We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help 1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ? 2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks Badri
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Re: DevStack-opendaylight on a multi-node setup
Dell - Internal Use - Confidential Hi Vishal, We forgot to mention a detail in our multi-node setup i.e., the overlay used is VxLan (Q_ML2_TENANT_NETWORK_TYPE=vxlan) . When I checked about ODL_PROVIDER_MAPPINGS, it works only with VLAN type of tenant network. How do we attach a physical interface for a vxlan type of tenant network? Regards, Ravi
toggle quoted message
Show quoted text
-----Original Message----- From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Vishal Thapar Sent: Thursday, July 30, 2015 1:54 AM To: Viswanatha, Badrinath; openstack@...; ovsdb-dev@... Cc: Venkataraghavan, C Subject: Re: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards, Vishal.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Badrinath_Viswanatha@... Sent: 29 July 2015 11:29 To: openstack@...; ovsdb-dev@... Cc: C_Venkataraghavan@... Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All, We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help 1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ? 2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks Badri
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@... https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Re: DevStack-opendaylight on a multi-node setup
Vishal Thapar <vishal.thapar@...>
Hi Badri,
Try this: `ODL_PROVIDER_MAPPINGS=physnet1:eth1`
Regards, Vishal.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Badrinath_Viswanatha@... Sent: 29 July 2015 11:29 To: openstack@...; ovsdb-dev@... Cc: C_Venkataraghavan@... Subject: [ovsdb-dev] DevStack-opendaylight on a multi-node setup
Hi All, We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin.
The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ).
Can you please help 1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ? 2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces.
Thanks Badri
|
|
DevStack-opendaylight on a multi-node setup
Hi All, We are trying to setup a multi-node devstack setup with opendaylight ML2 plugin. The local.conf, we use with devstack does not have an option to specify the tenant physical interfaces. It only has options for specifying the management IP address ( and by extension the eth0 ) and the external network ( eth2 ). Can you please help 1) How to specify tenant network ( VM data network) to be setup only on eth1 of the compute nodes. ? 2) If possible, share the local.conf, that you might have used with your devstack on a similar topology, specifying the physical interfaces. Thanks Badri
|
|
No meeting today - 7/28/15
Hi all,
no meeting for today with many at the Summit.
Thanks, Sam
|
|
Re: Jenkins Build failing due to timeout.
Suryanarayanan, Aswin <aswin.suryanarayanan@...>
toggle quoted message
Show quoted text
From: Suryanarayanan, Aswin
Sent: Tuesday, July 28, 2015 4:50 PM
To: ovsdb-dev@...
Subject: Jenkins Build failing due to timeout.
Hi,
I see that Jenkins build is failing since git clone times out. Anybody else facing a similar issue? Is there a connectivity issue?
https://jenkins.opendaylight.org/releng/job/ovsdb-verify-master/jdk=openjdk7,nodes=dynamic_verify/1002/console
Cloning the remote Git repository
Cloning repository ssh://jenkins-releng@...:29418/ovsdb
> git init /opt/jenkins/workspace/ovsdb-verify-master/jdk/openjdk7/nodes/dynamic_verify # timeout=10
Fetching upstream changes from ssh://jenkins-releng@...:29418/ovsdb
> git --version # timeout=10
using GIT_SSH to set credentials Release Engineering Jenkins Key
> git fetch --tags --progress ssh://jenkins-releng@...:29418/ovsdb +refs/heads/*:refs/remotes/origin/*
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Thanks and Regards
Aswin
|
|
Jenkins Build failing due to timeout.
Suryanarayanan, Aswin <aswin.suryanarayanan@...>
Hi,
I see that Jenkins build is failing since git clone times out. Anybody else facing a similar issue? Is there a connectivity issue?
https://jenkins.opendaylight.org/releng/job/ovsdb-verify-master/jdk=openjdk7,nodes=dynamic_verify/1002/console
Cloning the remote Git repository
Cloning repository ssh://jenkins-releng@...:29418/ovsdb
> git init /opt/jenkins/workspace/ovsdb-verify-master/jdk/openjdk7/nodes/dynamic_verify # timeout=10
Fetching upstream changes from ssh://jenkins-releng@...:29418/ovsdb
> git --version # timeout=10
using GIT_SSH to set credentials Release Engineering Jenkins Key
> git fetch --tags --progress ssh://jenkins-releng@...:29418/ovsdb +refs/heads/*:refs/remotes/origin/*
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Thanks and Regards
Aswin
|
|
Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Yang, Yi Y <yi.y.yang@...>
It will be better if time is friendly for EU and China and India, please forward WebEx link to maillist when it is available.
toggle quoted message
Show quoted text
From: Manohar SL [mailto:manohar.sl@...]
Sent: Monday, July 27, 2015 11:53 AM
To: Abhijit Kumbhare; Yang, Yi Y; Philip Robb
Cc: Edward Warnicke; alagalah; Brady Allen Johnson; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N;
Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: RE: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Friday Morning would be really great
J
We can definitely join from BLR/India.
From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Monday, July 27, 2015 9:21 AM
To: Yang, Yi Y; Philip Robb
Cc: Edward Warnicke; alagalah; Brady Allen Johnson;
sfc-dev@...;
lacp-dev@...;
openflowplugin-dev@...; Manohar SL;
ovsdb-dev@...;
groupbasedpolicy-dev@...; Prakash N N;
Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Sounds good - but I have a scheduling request to Phil or whoever arranging the schedule. We have a clustering session continued at 2:15 pm on Thursday. Also Ed is hosting a session solving the same or a similar problem
with a different solution (Coexistence of multiple projects in the same pipeline - Ed Warnicke) between 3:30-4:15 pm on Thursday. It will be good to conclude that topic on Thursday and then tackle this on Friday morning (say the 9:45 am session). In that case
people from the India team may be able to join (as opposed to afternoon sessions).
On Sun, Jul 26, 2015 at 7:05 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Hi, Guys
I noticed I was drafted as leader for this discussion
https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution, but unfortunately I can’t make it because I won’t travel to US. Please
Abhijit can help host it.
I drafted a wiki page in
https://wiki.opendaylight.org/view/OF_pipeline which includes two implemention options I sugguest, you can take them into discussion. I can dial in if this event can provide WebEx
and time is ok to China.
From: Abhijit
Kumbhare [mailto:abhijitkoss@...]
Sent: Friday, July 24, 2015 11:18 PM
To: Edward Warnicke
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y;
sfc-dev@...;
lacp-dev@...;
openflowplugin-dev@...; Manohar SL;
ovsdb-dev@...;
groupbasedpolicy-dev@...; Prakash N N;
Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
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
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?
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
_______________________________________________
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?
Manohar SL <manohar.sl@...>
Friday Morning would be really great
J
We can definitely join from BLR/India.
toggle quoted message
Show quoted text
From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Monday, July 27, 2015 9:21 AM
To: Yang, Yi Y; Philip Robb
Cc: Edward Warnicke; alagalah; Brady Allen Johnson; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...;
Prakash N N; Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Sounds good - but I have a scheduling request to Phil or whoever arranging the schedule. We have a clustering session continued at 2:15 pm on Thursday. Also Ed is hosting a session solving the same or a similar problem with a different
solution (Coexistence of multiple projects in the same pipeline - Ed Warnicke) between 3:30-4:15 pm on Thursday. It will be good to conclude that topic on Thursday and then tackle this on Friday morning (say the 9:45 am session). In that case people from the
India team may be able to join (as opposed to afternoon sessions).
On Sun, Jul 26, 2015 at 7:05 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Hi, Guys
I noticed I was drafted as leader for this discussion
https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution, but unfortunately I can’t make it because I won’t travel to US. Please
Abhijit can help host it.
I drafted a wiki page in
https://wiki.opendaylight.org/view/OF_pipeline which includes two implemention options I sugguest, you can take them into discussion. I can dial in if this event can provide WebEx
and time is ok to China.
From:
Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Friday, July 24, 2015 11:18 PM
To: Edward Warnicke
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y;
sfc-dev@...;
lacp-dev@...;
openflowplugin-dev@...; Manohar SL;
ovsdb-dev@...;
groupbasedpolicy-dev@...; Prakash N N;
Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
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
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?
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
_______________________________________________
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?
Sounds good - but I have a scheduling request to Phil or whoever arranging the schedule. We have a clustering session continued at 2:15 pm on Thursday. Also Ed is hosting a session solving the same or a similar problem with a different solution (Coexistence of multiple projects in the same pipeline - Ed Warnicke) between 3:30-4:15 pm on Thursday. It will be good to conclude that topic on Thursday and then tackle this on Friday morning (say the 9:45 am session). In that case people from the India team may be able to join (as opposed to afternoon sessions).
toggle quoted message
Show quoted text
On Sun, Jul 26, 2015 at 7:05 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Hi, Guys
I noticed I was drafted as leader for this discussion
https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution, but unfortunately I can’t make it because I won’t travel to US. Please
Abhijit can help host it.
I drafted a wiki page in
https://wiki.opendaylight.org/view/OF_pipeline which includes two implemention options I sugguest, you can take them into discussion. I can dial in if this event can provide WebEx and time is ok to
China.
From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Friday, July 24, 2015 11:18 PM
To: Edward Warnicke
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash
N N; Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
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
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?
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
_______________________________________________
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?
Yang, Yi Y <yi.y.yang@...>
toggle quoted message
Show quoted text
From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Friday, July 24, 2015 11:18 PM
To: Edward Warnicke
Cc: alagalah; Brady Allen Johnson; Yang, Yi Y; sfc-dev@...; lacp-dev@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash
N N; Hariharan_Sethuraman@...; C_Venkataraghavan@...; Prem sankar G
Subject: Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
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
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?
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
_______________________________________________
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?
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
|
|
Re: [sfc-dev] [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?
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.
toggle quoted message
Show quoted text
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
|
|
Re: [openflowplugin-dev] [sfc-dev] [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Edward Warnicke <hagbard@...>
Again... I don't believe 'merging' flows with an 'arbiter' is the right solution... these problems are a symptom of choosing the 'arbiter' approach and go away when you make different choices about app coexistence (of course, I have no doubt we will see other interesting challenges with the 'stack' approach ;) ).
Ed
toggle quoted message
Show quoted text
On Sat, Jul 25, 2015 at 12:52 AM, <Hariharan_Sethuraman@...> wrote: 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@...]
That depends... I really *do* want a discussion to look at the 'stack' approach rather than the 'arbiter' approach. (as a matter of personal opinion, I think the 'arbiter' approach is a dead end) 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 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? 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
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
|
|