For Colin's point #2, how about pulling up the GBP into the green rectangle and carving out a portion of the SAL to make it all fit?

With the devices in the bottom, how about changing it to these three categories instead?

1. OpenFlow-enabled devices

2. OVSDB-enabled devices

3. Devices with proprietary control plane

We already say Physical and Virtual on the legend in the right.

In the legend on top, how about removing standard ones like BGP, DDos, SNMP, ARP, LISP. That will give some room and make it less crowded. Also, it will be good to remove the word "project" from the legend for AAA.

On Tue, Sep 23, 2014 at 4:03 PM, Colin Dixon <colin@...> wrote:

A few questions/suggestions:

1.) can we remove the ARP Handler or move it into the l2switch where I think it resides now. That will actually save space.

2.) If anyone has a suggestion for how to make it seem less like the only way to access OpenFlow and OVSDB southbounds is via Group Based Policy, I'd like to hear it.

3.) I had to look up what we mean by "capability abstraction", do we have a better phrase for that?

--Colin

On Tue, Sep 23, 2014 at 5:50 PM, Phil Robb <probb@...> wrote:

Hello again TSC and members of the Helium Release:

Thanks to all for the great feedback on the Helium diagram.  It has all been incorporated into the pretty version of the diagram you see attached.

Please let me know what you think.

Phil.

On Tue, Sep 16, 2014 at 10:39 AM, Phil Robb <probb@...> wrote:

Hello TSC and members of the Helium Release:

Please find attached an architectural diagram describing the components that make up Helium.  This diagram is in the same format as the one we used to describe Hydrogen so users familiar with the former can have a frame of reference.  This diagram is not pretty and please spend no effort in trying to make it so.  Once the technical content is verified, I'll send if off to folks in the LF that are masters at making it look pretty.  For now, I'm just looking for accuracy and completeness.  So please review it with that in mind and provide me any feedback that you have by Friday (9/19).

Given that we are going out with a karaf-based, user-selectable set of features for Helium, the attached diagram is not sufficient in explaining to our users what is available (ie what they can select) and the features/functionality they get from each potential selection.  So I believe we need another diagram, or set of diagrams, and concise, descriptive text for each user visible feature.  What are your thoughts on this?  Are there other/better ways of representing the user-visible features within ODL?  If nothing better is proposed, I'll reach out to each project contact for that short, concise feature description.

Thanks,

Phil.

--

Phil Robb

Director - Networking Solutions

The Linux Foundation

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb

--

Phil Robb

Director - Networking Solutions

The Linux Foundation

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc