Hi,

Sanity checking is indeed a great idea. But I think it would be important to clearly understand what needs to be sanity checked and what rather needs to be sanitized, or treated otherwise.

In my understanding the whole point of SAL (and MD-SAL in particular) is to provide an abstract interface to the user, hiding internals and low-level details of southbound protocols. So the user program the abstraction, and some ODL magic will turn that into an actual southbound implementation.

In this specific case we program a FlowCapable node, and not an OpenFlow 1.3 switch. If ODL is configured so, our FlowCapable flow entries will be routed to the OpenFlow plugin, which will transform them to OF 1.3 flows. I know this might sound awkward, as the current ODL abstractions tend to map 1:1 to southbound protocols. But it is quite important to understand the long term implications of forcing such a detail of a specific southbound protocol on the abstract model (especially w.r.t. expanding the scope of the abstraction later).

For example, considering the prerequisite rules of OF 1.3 (see the “IPv6 ND target but not matching on ICMPv6 type code of 135/136” example below), forcing the same prerequisite rules on the abstract FlowCapable nodes is only one possibility. But it is also possible not to enforce those, but rather have OpenFlow Plugin sanitize flow entries by adding the missing match fields.

All I wanted to point out (and perhaps I did this in an overtly long way) is that we have all the freedom of defining the semantics of the FlowCapable node abstraction. We don’t have to blindly copy those of OpenFlow 1.3 – as it might even hurt in the long run. All we need to consider is being able to transform from our abstract semantics to those of the southbounds’ in a sane way.

BR,

Zoltan