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