z.archive.openflowjava-dev@lists.opendaylight.org | [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Home Messages Hashtags Subgroups

This group is locked. No changes can be made to the group while it is locked.

Date Date 1 - 14 of 14

[opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Robert Varga <nite@...> #655 On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote: I added a slide for the impact to the OpenFlow consumers (downstream projects) as well as some clarifications in the reorganization slide that we should keep the backward compatibility. Also added disclaimers that this is not in the present - but in the future. Also made it a google slide format for easier viewing/sharing: https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing I would like to clarify slide 5. The original intent between the two models worlds was not support for multiple SB protocols, but rather multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper layer' models were supposed to be version-agnostic and the OFP would perform translation to the appropriate version-specific (OFJ) model. Hence the idea was that the applications could transition between 1.0 and 1.3 devices without being modified. It may well be that this dream has failed, but that is really what needs to be called out. Bye, Robert signature.asc signature.asc
Anil Vishnoi #656 On Mon, May 9, 2016 at 9:17 AM, Robert Varga <nite@...> wrote: On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote: > I added a slide for the impact to the OpenFlow consumers (downstream > projects) as well as some clarifications in the reorganization slide > that we should keep the backward compatibility. Also added disclaimers > that this is not in the present - but in the future. > > Also made it a google slide format for easier viewing/sharing: > > https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing I would like to clarify slide 5. The original intent between the two models worlds was not support for multiple SB protocols, but rather multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper layer' models were supposed to be version-agnostic and the OFP would perform translation to the appropriate version-specific (OFJ) model. I think this is one of the reason as well, but the higher level goal was to use them as a controller wide model and that was the reason we added all these models in the controller projects. Hence the idea was that the applications could transition between 1.0 and 1.3 devices without being modified. It may well be that this dream has failed, but that is really what needs to be called out. Agree, I think Ed did try to simplify these models after we moved these model of openflowplugin, but that was not an easy job, probably that's the reason he gave up on it :). Bye, Robert -- Thanks Anil
Abhijit Kumbhare #657 In-line. On Mon, May 9, 2016 at 10:13 AM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 9:17 AM, Robert Varga <nite@...> wrote: On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote: > I added a slide for the impact to the OpenFlow consumers (downstream > projects) as well as some clarifications in the reorganization slide > that we should keep the backward compatibility. Also added disclaimers > that this is not in the present - but in the future. > > Also made it a google slide format for easier viewing/sharing: > > https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing I would like to clarify slide 5. The original intent between the two models worlds was not support for multiple SB protocols, but rather multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper layer' models were supposed to be version-agnostic and the OFP would perform translation to the appropriate version-specific (OFJ) model. I think this is one of the reason as well, but the higher level goal was to use them as a controller wide model and that was the reason we added all these models in the controller projects. That's my recollection as well - both the points (if it was only 1.0 & 1.3 the models would have been in the OpenFlow plugin right from the beginning, not in the controller first and then moved to OpenFlow plugin). I will add this second point regarding the 1.0 & 1.3 abstraction to the slide. Hence the idea was that the applications could transition between 1.0 and 1.3 devices without being modified. It may well be that this dream has failed, but that is really what needs to be called out. Agree, I think Ed did try to simplify these models after we moved these model of openflowplugin, but that was not an easy job, probably that's the reason he gave up on it :). Bye, Robert -- Thanks Anil
Robert Varga <nite@...> #658 On 05/09/2016 07:13 PM, Anil Vishnoi wrote: I think this is one of the reason as well, but the higher level goal was to use them as a controller wide model and that was the reason we added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... On a related note: does this mean that the OFJ models will be hooked onto the topology model? Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Bye, Robert signature.asc signature.asc
Abhijit Kumbhare #659 Inline. On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Abhijit>> If I remember right the key idea then was a model for "Flow Capable Devices" - via any protocol capable of providing flow like semantics to the flow capable devices. Of course - it never went that way as in OpenDaylight I believe the only flow capable protocol we have is OpenFlow. I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... Abhijit>> Yes - will not make sense for devices/protocols which are not flow capable. On a related note: does this mean that the OFJ models will be hooked onto the topology model? Abhijit>> I think we need to think through this a bit. (On a different note since I saw the mention about the topology model - I sent the following email about inventory model to topology model : https://lists.opendaylight.org/pipermail/discuss/2016-May/006460.html ) Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Abhijit>> Not sure what exactly you mean by some higher-level project - do you mean OpenFlow Plugin? Bye, Robert
Robert Varga <nite@...> #660 On 05/09/2016 11:20 PM, Abhijit Kumbhare wrote: On a related note: does this mean that the OFJ models will be hooked onto the topology model? Abhijit>> I think we need to think through this a bit. (On a different note since I saw the mention about the topology model - I sent the following email about inventory model to topology model : https://lists.opendaylight.org/pipermail/discuss/2016-May/006460.html ) Thanks for the pointer, I missed both that TWS and the thread. I will follow up on it. Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Abhijit>> Not sure what exactly you mean by some higher-level project - do you mean OpenFlow Plugin? I do not believe OFP should be the place -- it is technology specific, after all. NETCONF provides this naturally via mount point capabilities, I am not sure which project provides an equivalent abstraction which works for OpenFlow... Bye, Robert signature.asc signature.asc
Anil Vishnoi #661 On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil
Colin Dixon #666 So, did the TWS on this topic actually happen? I think it didn't, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. --Colin toggle quoted message Show quoted text On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev
Alexis de Talhouët <adetalhouet@...> #667 On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote: So, did the TWS on this topic actually happen? I think it didn’t Correct it didn’t, last TWS focused on phased release and semantic versioning. , but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. +1, absolutely. Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella. 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. I’m not sure to get the question here so I will at careful at further discussion. Thanks, Alexis --Colin On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
Colin Dixon #668 The last question is basically, should we merge openflowjava and openflowplugin into one project? leave them apart? or pick a different splitting point? That was basically the focus of the 3-5 mails before mine above. --Colin toggle quoted message Show quoted text On Thu, May 12, 2016 at 9:53 AM, Alexis de Talhouët <adetalhouet@...> wrote: On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote: So, did the TWS on this topic actually happen? I think it didn’t Correct it didn’t, last TWS focused on phased release and semantic versioning. , but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. +1, absolutely. Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella. 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. I’m not sure to get the question here so I will at careful at further discussion. Thanks, Alexis --Colin On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
Andrew Grimberg <agrimberg@...> #669 On 05/12/2016 06:43 AM, Colin Dixon wrote: So, did the TWS on this topic actually happen? I think it didn't, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. I'll point out a couple of things with a restructure: 1) Build history might potentially be lost if the projects change their final component name (which is unlikely). Just changing the logical parentage shouldn't be an issue though we would have to lock access to the repos during the transition. 2) We base the artifact namespacing upon the repo name. So, an example of foo/bar/baz.git in Gerrit would have a namespace of org.opendaylight.foo.bar.baz.* in Nexus. 3) With #2 in mind a reorg does mean that their merge jobs will fail until they update their groupID to the newly designated groupID. -Andy- -- Andrew J Grimberg Systems Administrator Release Engineering Team Lead The Linux Foundation signature.asc signature.asc
Abhijit Kumbhare #671 Yes - as Alex mentioned during the last meeting the topic was phased release & semantic versioning - but we could do it on the coming Monday. About the last point - I think we should: 1. Not get rid of the existing abstracted OpenDaylight forwarding model in the near future - may be for a long time - as the existing OpenDaylight applications are written toward this forwarding model. 2. Over period add an additional optimized non-abstract OpenFlow forwarding model for select cases where the performance would be critical (example flow programming). Over time applications could migrate toward this forwarding model & then could be deprecated. toggle quoted message Show quoted text On Thu, May 12, 2016 at 6:54 AM, Colin Dixon <colin@...> wrote: The last question is basically, should we merge openflowjava and openflowplugin into one project? leave them apart? or pick a different splitting point? That was basically the focus of the 3-5 mails before mine above. --Colin On Thu, May 12, 2016 at 9:53 AM, Alexis de Talhouët <adetalhouet@...> wrote: On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote: So, did the TWS on this topic actually happen? I think it didn’t Correct it didn’t, last TWS focused on phased release and semantic versioning. , but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. +1, absolutely. Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella. 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. I’m not sure to get the question here so I will at careful at further discussion. Thanks, Alexis --Colin On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
Anil Vishnoi #672 On Thu, May 12, 2016 at 6:53 AM, Alexis de Talhouët <adetalhouet@...> wrote: On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote: So, did the TWS on this topic actually happen? I think it didn’t Correct it didn’t, last TWS focused on phased release and semantic versioning. , but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. +1, absolutely. +1 Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella. +1 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. I’m not sure to get the question here so I will at careful at further discussion. Thanks, Alexis --Colin On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev -- Thanks Anil
Colin Dixon #680 After thinking about this for a bit, I think we have two real current problems: 1.) It's confusing for people to figure out what projects are related to OpenFlow and how. 2.) It's hard for people to bring new OpenFlow extensions to OpenDaylight because they have to start their own project. While I think that consolidating projects under a single openflow/ namespace probably makes sense in the long run, it might be overkill since it doesn't seem required to solve the first problem and it doesn't help the second problem. --Colin toggle quoted message Show quoted text On Fri, May 13, 2016 at 3:22 AM, Anil Vishnoi <vishnoianil@...> wrote: On Thu, May 12, 2016 at 6:53 AM, Alexis de Talhouët <adetalhouet@...> wrote: On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote: So, did the TWS on this topic actually happen? I think it didn’t Correct it didn’t, last TWS focused on phased release and semantic versioning. , but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have. +1, absolutely. +1 Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand. 2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella. +1 3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful. I’m not sure to get the question here so I will at careful at further discussion. Thanks, Alexis --Colin On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote: On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote: On 05/09/2016 07:13 PM, Anil Vishnoi wrote: > I think this is one of the reason as well, but the higher level goal > was to use them as a controller wide model and that was the reason we > added all these models in the controller projects. Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an 'OpenDaylight forwarding model'? Let me put it in this way-- this was the real intent, but the implementation was openflow influenced :) I am not quite sure how PCEP would map onto the OFP models, as there would have to be a way to communicate the fact that things like L2 matches simply make no sense (unless some new PCEP extensions get defined and are supported by the device)... ...and this is one of many reason we realize lets move it to openflowplugin project :) On a related note: does this mean that the OFJ models will be hooked onto the topology model? ..that's probably one way to go about it ... but it's open for thoughts Would that imply that version-agnostic applications should rather be using APIs defined by some higher-level project? Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not really version agnostic. And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). Bye, Robert -- Thanks Anil _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowjava-dev mailing list openflowjava-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev -- Thanks Anil

1 - 14 of 14

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms