Related to this, we need to think about meeting our M2 deliverables [0]. The biggest one is the final release plan, but there are few other things we need to do:

a.) get sonar unit test coverage reporting

b.) dependencies on other projects which aren't offset 0

     * I think this is nothing currently, but might include: openflowjava, openflowplugin, and didm depending on what we decide to do

In terms of the release plan we need to decide what deliverables we want to focus on and in what priority. Beyond that there's details:

i.) enumerate APIs with short names

ii.) list the YANG files and/or Java interfaces defining the API contracts

iii.) call out the backing code for each one (if it's there)

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#M2:_Final_Release_Plan

On Thu, Aug 20, 2015 at 9:56 AM, Colin Dixon <colin@...> wrote:

(the previous version of this was prematurely sent)

I guess the first thing we need to figure is what resources we'll have. Honestly, it seems like we'll get ~2-4 hours/week from Curt, Colin and maybe Preetam at best. There's some chance that we'll get extra resources from Atrium and/or DIDM [0], but likely only in a glancing way.

There are two main threads of work that have been happening so far:

1.) Tools

2.) Actual TTP support

In Lithium, we did a pretty good job of working on tools except that we didn't really get any graphical tools, which is really what we want. There's Jasson's stuff, which never seemed to materialize. Curt has his Excel stuff, which could be developed. There's also the ODL YangUI stuff which Subhash show off recently. We might want to enhance some of this stuff, but it's likely not the critical emphasis.

The actual TTP support in ODL is essentially absent at the moment in the sense that you can load a TTP and associate with a switch, but that doesn't actually let you do anything interesting. The proposed focus for TTP in Beryllium should thus likely be around fixing this. The diagrams in the previous mail speak to how we might do that. The PDF is here:
https://lists.opendaylight.org/pipermail/ttp-dev/attachments/20150813/1542816d/attachment-0001.pdf

In essence, this would likely be some form of collaborating with DIDM (and maybe Atrium) to provide "drivers" that would translate from Application Layer (Area?) TTPs to device-specific TTPs. As I understand it (and actually have advised the Atrium effort), the first stab of Atrium on ODL is likely to ignore TTPs just to get something working faster.

In the long run, I think whatever we do with hardware-agnostic OpenFlow support will have to look like translators from application-layer TTPs to device-specific TTPs and so might as well admit it.

Concrete action items:

* Minimum deliverable for Beryllium:
   * applications can create application-layer flowmods

   * there is some function (service or library) to translate them into device-specific flowmods

   * this could be hand-coded per pair of application-layer TTP and device-specific TTP

* Stretch deliverable for Beryllium: provide the first deliverable, but as a driver for DIDM

* Stretch deliverable for Beryllium: provide (semi-)automated construction of TTP-to-TTP drivers

    * ideally this would be fully-automated and would generate a driver or throw and error saying it doesn't know how

    * more realistically, this could be done as heuristics suggesting table equivalences, flow-path equivalences or some other approach

 

Some random ideas about the (semi-)automated TTP-to-TTP driver creation:

1. The don't spit/merge tables automate TTP translation problem: Can you find a mapping for tables in A to tables in B such that for ever table pair t_Ai => t_Bi all matches/actions in t_Ai are possible in t_Bi (and as a consequence all paths between tables are also allowed by virtue of goto_table actions)?

2. There's another constrained version where you use flowpaths which are basically the complete set of flowmods that you would expect a packet to traverse. This might make splitting/joining flowmods (and thus being somewhat less tied to tables easier.

3. Maybe the first approach is to just assume application-layer TTPs are single-table and thus a flowmod is a flowpath.

4. The fully general problem here is really, really nasty and basically asks for every set of legal flowmods in TTP A is there a set TTP B that produces the same behavior. It might more tractable for simple application-layer TTPs. Even then, I think it gets really nasty if you are simultaneously provide more than one application-layer TTP upward.

 

--Colin

[0] https://lists.opendaylight.org/pipermail/didm-dev/2015-August/000146.html

 

On Thu, Aug 13, 2015 at 12:05 PM, Colin Dixon <colin@...> wrote:

Thanks to Curt, we have a draft release plan here:
https://wiki.opendaylight.org/view/Table_Type_Patterns/Beryllium/Release_Plan

I'm attaching a diagram (both PDF and OmniGraffle source) that Curt and I talked through a bit a while ago around how TTPs, flow programming, and DIDM might interact and what we might plan for.

We also might want to think about how TTPs can enable OpenFlow app composition.

 

--Colin