Re: [openflowplugin-dev] sanity check of flows to OF1.3 Spec

Home Messages Hashtags Subgroups

#1172

Re: [openflowplugin-dev] sanity check of flows to OF1.3 Spec

Ed Warnicke (eaw) <eaw@...> #1172 OMG yes! This! This is an extension of ‘provide good defaults’. Currently the OpenFlow plugin provides defaults for many parameters (very open to discussion about what the correct defaults are). I would tend to say that in the event that the sanitization is protocol specific (for example, OF requiring certain L2 level matches as prerequisites to IP matches… I suspect your are favoring having the OpenFlow plugin add that if missing… which strikes me as reasonable and also ultra friendly to consumers). My tendency would be that we should only be doing sanitization/checking at the FRM level that are actually generically applicable to flow programming and handling the protocol specific sanitization down to the OpenFlow plugin. I think there’s a very interesting discussion to be had around which is which :) Ed On May 31, 2014, at 7:58 AM, Zoltán Lajos Kis <zoltan.lajos.kis@...> wrote: toggle quoted message Show quoted text 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 From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Brent Salisbury Sent: Saturday, May 31, 2014 1:15 AM To: Ed Henry; Christopher O'SHEA Cc: integration-dev@...; openflowplugin-dev@... Subject: Re: [integration-dev] [openflowplugin-dev] sanity check of flows to OF1.3 Spec Excellent, I feel a vHackfest coming on! Let’s get some content together and get rolling! -B From: Ed Henry <networkn3rd@...> Date: Friday, May 30, 2014 at 7:07 PM To: Christopher O'SHEA <christopher.o.shea@...> Cc: Abhijit Kumbhare <abhijitkoss@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, Brent Salisbury <brent.salisbury@...>, "integration-dev@..." <integration-dev@...> Subject: Re: [openflowplugin-dev] [integration-dev] sanity check of flows to OF1.3 Spec +1 as well. I'd love to tackle low hanging fruit like this as well. -Ed On May 30, 2014 6:18 PM, "Christopher O'SHEA" <christopher.o.shea@...> wrote: Yea Brent awesome idea. Would love to get my hands dirty, so +1 to the instructions. Chris From: Abhijit Kumbhare <abhijitkoss@...> Date: Friday, May 30, 2014 at 2:41 PM To: Brent Salisbury <brent.salisbury@...> Cc: Ericsson <christopher.o.shea@...>, "integration-dev@..." <integration-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...> Subject: Re: [integration-dev] [openflowplugin-dev] sanity check of flows to OF1.3 Spec Sounds a good idea Brent! On Fri, May 30, 2014 at 2:21 PM, Brent Salisbury <brent.salisbury@...> wrote: Hey Chris, I did a quick audit last weekend and started patching a couple of them. I will clean the list up tonight and reply with them this evening. Fwiw it's a good low hanging fruit for folks that are new to Java, ODL or dev in general to get their feet wet. Will include instructions if anyone is interested. Thanks Chris! Brent On May 30, 2014, at 4:57 PM, Christopher O'SHEA <christopher.o.shea@...> wrote: Hi, I’m just wonder if there any sanity check performed on the flows before they are pushed to the switch? Something like EtherType of IPv4 but having a match on IPv6 src address? IPv6 ND Target but not matching on ICMPv6 type code of 135/136 I only bring this up as I’m convert some the XML file in the test-script/xmls to be run in the CSIT via robot. I notice some of the flows don’t get pushed to OVS but when I check the flow they break the spec so OVS reject the flow. Chris _______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev _______________________________________________ integration-dev mailing list integration-dev@... https://lists.opendaylight.org/mailman/listinfo/integration-dev _______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@... https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev _______________________________________________ integration-dev mailing list integration-dev@... https://lists.opendaylight.org/mailman/listinfo/integration-dev
More All Messages By This Member

View All 13 Messages In Topic

#1172

Join {integration-dev@lists.opendaylight.org to automatically receive all group messages.

Home Hashtags Subgroups Terms