Re: [openflowplugin-dev] sanity check of flows to OF1.3 Spec
|
Tony Tkacik -X (ttkacik - Pantheon Technologies SRO@Cisco) <ttkacik@...>
+1
FRM (configuration model) should be more abstract, high-level then plugin level definition of flow, Since capabilities and functionality may yeld different use-cases (e.g. FRM configuration model does not support cookies, bariers, openflowplugin level APIs Does support them).
Tony
From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...]
On Behalf Of Abhijit Kumbhare
Sent: Tuesday, June 03, 2014 12:38 AM To: Zoltán Lajos Kis Cc: integration-dev@...; openflowplugin-dev@... Subject: Re: [openflowplugin-dev] [integration-dev] sanity check of flows to OF1.3 Spec
Makes sense (FRM level having a more abstract rule - which is broken down into multiple specific rules in the plugin). At least theoretically - implementation wise how complicated this will be remains to be seen.
On Mon, Jun 2, 2014 at 10:00 AM, Zoltán Lajos Kis <zoltan.lajos.kis@...> wrote: I’m talking about a lot more than just setting defaults. To give a simple example, let’s say I want to match on all HTTP traffic.
With OpenFlow today I need to add two separate rules: one for IPv4 and one for IPv6 (thanks to the prerequisite stuff*). Which to me, as a developer, smells like SB details creeping into my control logic.
At the FlowCapable level however I could imagine that I install a single rule matching on “tcp_dst=80”, and have some *ODL magic* that cleverly installs two OF 1.3 for this. Of course if we start to look closer, we might find a lot of details here that might render the whole idea impossible (e.g., how do you estimate the table size); but I think this is something worth investigating before artificially limiting the FlowCapable scope to OF 1.3.
I haven’t delved into the code enough to have an opinion on where sanitization should be. I guess the top of FRM should still be on FlowCapable level, and the bottom of OpenFlowPlugin on the OpenFlow level. Then the rest is a long religious war between the strategy and dispatcher patterns :o)
Btw, I’m not sure how you can do sanitization at the FRM level. I would assume the same level of sanitization can already be done on the model level (i.e., by specifying constraints on the FlowCapable node yang model). Also, another interesting aspect is the operational state. Should it reflect the config state (so the user can see that the rules he wanted are installed), or should it reflect the actual SB state (which might come handy for debugging)?
Best, Zoltan
* I believe the OXM match syntax could have been a lot more descriptive then what it turned out to be. It could potentially describe arbitrary deep matches. For example in an MPLS L3VPN I could just say “eth_type=0x8847, mpls_bos=1, mpls_nibble=4, ipv4_dst=10.0.0.1”, et voila: I’m matching on the IPv4 fields of a packet below the MPLS layer. Of course this train is long gone, because the prerequisite rules break the possibility of chaining fields of the same layer. Also by now the ODL FlowCapable model assumes that there’s only one layer of a kind, so that can’t be retrofitted to this either.
From: Ed
Warnicke (eaw) [mailto:eaw@...]
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:
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
Excellent, I feel a vHackfest coming on! Let’s get some content together and get rolling! -B
From: Ed Henry <networkn3rd@...>
+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@...>
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
_______________________________________________
|
|
|