Hello,

i would like to summarize our thoughts behind OF Protocol Library architecture and react to given suggestions.

In the current architecture one of the main responsibility of southbound
protocol plugin is to handle connections with network devices.

I agree. But it is not defined how southbound protocol plugin has to implement this functionality - if it must be implemented directly or if the plugin can use other component (or library) to achieve this.

Other responsibilities of the protocol plugin ( discovery/inventory service, data
packet service, stats collection, SAL abstraction to protocol message
conversion etc) are kind of dependent on the connection handling service.

With right API design connection handling could be exposed to the plugin and the plugin could still control things like acceptance on session, capability negotiation and other funcionalities. However, base pieces of this functionality could be in library.

In the proposed design of protocol library, I think pipeline processing and
concept of facade is interesting and possibly required components from the
perspective that we will have multiple version of openflow spec (without
backward compatibility) or multiple implementation of protocol library.

IMHO component 1 to 5 & 7 of the pipeline processing (slide 13), can be part
of the southbound protocol plugin. Component 1 to 5 can help in building
comprehensive connection handling service that can support existing openflow
1.0 & 1.3 protocols connection mechanism, as well as future enhancement in
this area.

The location of code and functionality in OF protocol library vs. southbound plugin does not prevent creating comprehensive solution, but this functionality is not southbound protocol plugin specific. With right API design, the plugin could use or customize it to its specific needs.

Component 6 (OF 1.3 CoDec) can be a static library on the similar
line of current openflowj, or based on Yang as proposed in the design.
Component 7 (Facade) can be extended to support both the OF 1.0 & 1.3 CoDec
( or may be its a redundant component). In that way I think it will require
minimal changes in the existing architecture and will satisfy the
requirement of proposed design.

From the slide decks I didn't actually get very strong rationale or use case
for implementing this mechanism in the protocol library compared to the
southbound protocol plugin, until and unless I am missing something in this
context.

By implementing this architecture model in the protocol library it allows library to be used also outside of the controller without the need to extract logic from the southbound protocol plugin.



Michal Polkorab