Open Daylight Graphic for First Release
Phil Robb
Hello TSC Members: I'v been working on an updated graphic to depict OpenDaylight's first release (thanks to Anees for his willingness to review/sanity check it). If everyone is good with it, I'll give it to the marketing folks and it will go onto a variety of our collateral (data sheet, presentations, website, etc.). Let me know your thoughts via email and maybe we can have a quick discussion on it during this week's TSC call if there are questions or concerns.
Thanks, Phil. -- Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292
Skype: Phil.Robb
|
|
Colin Dixon <ckd@...>
Overall, it looks really good. Just a few comments. (Don't take the nits the wrong way.)
|
|
Looks nice! Supplements:1) All layers should be aligned of the same size, e.g., the south plugins should be distributed and occupy the same length row with the controller platform row.
2) Can we change to a more light color theme? Currently it looks not that attractive. 3) The word "First Release" is too large, basically, it should be less than the OpenDaylight, and uses more professional fonts.
4) Four boxes at the right column, should be re-aligned. The explanation of the dataplane element is not that necessary. 5) Boxes of Dove mgr, Affinity Service, DDos Stats should not touch the outside bound.
On Wed, Aug 21, 2013 at 12:07 PM, Colin Dixon <ckd@...> wrote:
Best wishes! Baohua
|
|
David Meyer <dmm@...>
Very nice work. I'll just add one thing (I think) to what Colin said:
toggle quoted messageShow quoted text
it looks like the "controller platform" and the "southbound interfaces & protocol plugins" aren't aligned. Thanks all for the fine work on this. --dmm
On Tue, Aug 20, 2013 at 7:19 PM, Phil Robb <probb@...> wrote:
Hello TSC Members:
|
|
Besides, there's no DOVE support at the release?
On Wed, Aug 21, 2013 at 9:58 PM, David Meyer <dmm@...> wrote: Very nice work. I'll just add one thing (I think) to what Colin said: Best wishes! Baohua
|
|
Benny Rochwerger <BennyR@...>
Phil,
I think that a better representation of the Defense4All contributions will be to separate the statistics and redirection services and do not to label them “DDoS” (we hope these services are generic and will be used in the future for other purposes). On the other hand I think the anomaly detection and mitigation management boxes should be a single box label Anti-DDoS or DDoS protection, the anomaly detection and mitigation management components are internal and will not be contributed as separate components (at least not now), hence I think it is better represented as a single box
Regards,
Benny
From: tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Phil Robb
Hello TSC Members:
I'v been working on an updated graphic to depict OpenDaylight's first release (thanks to Anees for his willingness to review/sanity check it).
If everyone is good with it, I'll give it to the marketing folks and it will go onto a variety of our collateral (data sheet, presentations, website, etc.).
Let me know your thoughts via email and maybe we can have a quick discussion on it during this week's TSC call if there are questions or concerns.
Thanks,
Phil. Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb
|
|
Phil Robb
Hi Baohua: I'm not sure what you mean by this. The OpenDOVE proposal was accepted into OpenDaylight and is part of the first Simultaneous Release (as an offset-1 project). Phil.
On Wed, Aug 21, 2013 at 9:12 PM, Baohua Yang <yangbaohua@...> wrote:
Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292
Skype: Phil.Robb
|
|
Phil Robb
Hi Benny: Thanks very much for the corrections. Your suggestions make sense to me, but here are a couple of follow-up questions so that I am totally clear: 1) If I understand you correctly, there will be a single application contributed that sits above the OpenDaylight REST APIs and the application will perform both Anomaly Detection and DDoS Mitigation Management functions. That application you would like to call "DDoS Protection", or "Anti-DDoS"?
2) If I generically label the Defense4All box as "Statistics Service", the first question we will get is "why is there a generic base service "Statistiics Mgr." and a separate "Statistics Service". If the Defense4All statistics service is generic, can we instead augment the existing statistics manager instead of having two? If not, does the Defense4All statistics service use the base-function statistics manager? What different and separate functions does the Defense4All Statistics Service provide?
Thanks Benny, Phil..
On Thu, Aug 22, 2013 at 6:41 AM, Benny Rochwerger <BennyR@...> wrote:
Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292
Skype: Phil.Robb
|
|
Ken Gray <kgray@...>
That's a great question and the crux of the "reuse/expand" philosophy. Every contributor can't have overlapping modules unless there's a real case for why that NEEDS to be that way. From a drawing perspective you can just take Stats our of the DDOS traffic
redirect. The question that even that modification would lead me to ask is where is the implied state management …and that comes from "how would the state managed by the DDOS traffic redirect service differ from that managed by another flow management service?"
From: Phil Robb <probb@...>
Date: Thu, 22 Aug 2013 08:19:03 -0600 To: Benny Rochwerger <BennyR@...> Cc: "tsc@..." <tsc@...>, Avi Chesla <AviCh@...> Subject: Re: [OpenDaylight TSC] Open Daylight Graphic for First Release Hi Benny:
Thanks very much for the corrections. Your suggestions make sense to me, but here are a couple of follow-up questions so that I am totally clear:
1) If I understand you correctly, there will be a single application contributed that sits above the OpenDaylight REST APIs and the application will perform both Anomaly Detection and DDoS Mitigation Management functions. That application you would like
to call "DDoS Protection", or "Anti-DDoS"?
2) If I generically label the Defense4All box as "Statistics Service", the first question we will get is "why is there a generic base service "Statistiics Mgr." and a separate "Statistics Service". If the Defense4All statistics service is generic, can
we instead augment the existing statistics manager instead of having two? If not, does the Defense4All statistics service use the base-function statistics manager? What different and separate functions does the Defense4All Statistics Service provide?
Thanks Benny,
Phil..
On Thu, Aug 22, 2013 at 6:41 AM, Benny Rochwerger
<BennyR@...> wrote:
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
|
|
Phil Robb
Hello Again TSC Members: Thanks again to everyone for your excellent feedback! Please take a look at the updated OpenDaylight Graphic for the first release. I have tried to incorporate everyone's comments and suggestions. Please take another look and let me know your thoughts. My apologies for putting a time crunch on this, but if we are going to hit our collateral deadline, I need all comments back before the close of business on Monday (8/26). That is when I will send it to the graphics professionals who will get everything just right as well as put it into the correct color scheme (ie the colors are going to change and be much closer to the first graphic).
Thanks for your help on this. Phil.
On Tue, Aug 20, 2013 at 8:19 PM, Phil Robb <probb@...> wrote:
Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292
Skype: Phil.Robb
|
|
David Meyer <dmm@...>
Phil,
First, nice work. On Thu, Aug 22, 2013 at 4:03 PM, Phil Robb <probb@...> wrote: Hello Again TSC Members:My sense is that it is pretty close. BTW, what I like most about the graphic is that It is not too complicated and at the same time gets the point across that there are a lot of interesting things happening the first release. --dmm
|
|
Thanks phil, much better now! An irrelevant question on the basic network service functions, why the host tracker is a "Tracker", while others are xx "Mgr". They provide similar functions on various elements though.
On Fri, Aug 23, 2013 at 7:03 AM, Phil Robb <probb@...> wrote:
Best wishes! Baohua
|
|
Benny Rochwerger <BennyR@...>
Ken,
Our intention is definitely to reuse, and only expand when there is a need for something new. As you probably notices, in the new diagram there is no DDoS statistics collection service anymore. We plan to leverage the stats-manager, and if only something is missing in it, then expand it.
Benny
From: Ken Gray [mailto:kgray@...]
That's a great question and the crux of the "reuse/expand" philosophy. Every contributor can't have overlapping modules unless there's a real case for why that NEEDS to be that way. From a drawing perspective you can just take Stats our of the DDOS traffic redirect. The question that even that modification would lead me to ask is where is the implied state management …and that comes from "how would the state managed by the DDOS traffic redirect service differ from that managed by another flow management service?"
From:
Phil Robb <probb@...>
Hi Benny:
Thanks very much for the corrections. Your suggestions make sense to me, but here are a couple of follow-up questions so that I am totally clear:
1) If I understand you correctly, there will be a single application contributed that sits above the OpenDaylight REST APIs and the application will perform both Anomaly Detection and DDoS Mitigation Management functions. That application you would like to call "DDoS Protection", or "Anti-DDoS"? 2) If I generically label the Defense4All box as "Statistics Service", the first question we will get is "why is there a generic base service "Statistiics Mgr." and a separate "Statistics Service". If the Defense4All statistics service is generic, can we instead augment the existing statistics manager instead of having two? If not, does the Defense4All statistics service use the base-function statistics manager? What different and separate functions does the Defense4All Statistics Service provide?
Thanks Benny,
Phil..
On Thu, Aug 22, 2013 at 6:41 AM, Benny Rochwerger <BennyR@...> wrote:
Phil,
I think that a better representation of the Defense4All contributions will be to separate the statistics and redirection services and do not to label them “DDoS” (we hope these services are generic and will be used in the future for other purposes). On the other hand I think the anomaly detection and mitigation management boxes should be a single box label Anti-DDoS or DDoS protection, the anomaly detection and mitigation management components are internal and will not be contributed as separate components (at least not now), hence I think it is better represented as a single box
Regards,
Benny
From:
tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Phil Robb
Hello TSC Members:
I'v been working on an updated graphic to depict OpenDaylight's first release (thanks to Anees for his willingness to review/sanity check it).
If everyone is good with it, I'll give it to the marketing folks and it will go onto a variety of our collateral (data sheet, presentations, website, etc.).
Let me know your thoughts via email and maybe we can have a quick discussion on it during this week's TSC call if there are questions or concerns.
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
|
|
Phil Robb
Thanks to everyone for your comments of approval on the updated architecture diagram. I have not received any suggested edits so I have sent it to the graphic designers for final touches.
I'll send out the final version once I receive it. Phil.
On Thu, Aug 22, 2013 at 5:03 PM, Phil Robb <probb@...> wrote:
Phil Robb Director - Networking Solutions The Linux Foundation (O) 970-229-5949 (M) 970-420-4292
Skype: Phil.Robb
|
|
Madhu Venugopal (vmadhu) <vmadhu@...>
Hi Phil,
With various discussions around the SAL and not all the south-bound plugins may adopt MD-SAL approach for the first release,
Should we change the graphic to reflect the eventual reality of having both Traditional SAL & MD-SAL co-existing during the first-release ?
Eventually, it will all be MD-SAL, but (at least to me) it seems overly aggressive to call it MD-SAL only for the first release.
Just my 2c.
Thanks,
Madhu
From: Phil Robb <probb@...>
Date: Tuesday, August 27, 2013 3:46 PM To: "tsc@..." <tsc@...> Subject: Re: [OpenDaylight TSC] Open Daylight Graphic for First Release Thanks to everyone for your comments of approval on the updated architecture diagram. I have not received any suggested edits so I have sent it to the graphic designers for final touches.
I'll send out the final version once I receive it.
Phil.
On Thu, Aug 22, 2013 at 5:03 PM, Phil Robb
<probb@...> wrote:
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
|
|
Madhu Venugopal (vmadhu) <vmadhu@...>
Essentially, my suggestion is to have both AD-SAL (API Driven SAL) - am just inventing this acronym here :-)
and MD-SAL (Model Driven SAL) in the picture which will give architecture space for the release.
Thanks,
Madhu
From: Madhu Venugopal <vmadhu@...>
Date: Thursday, August 29, 2013 8:02 AM To: Phil Robb <probb@...>, "tsc@..." <tsc@...> Subject: Re: [OpenDaylight TSC] Open Daylight Graphic for First Release Hi Phil,
With various discussions around the SAL and not all the south-bound plugins may adopt MD-SAL approach for the first release,
Should we change the graphic to reflect the eventual reality of having both Traditional SAL & MD-SAL co-existing during the first-release ?
Eventually, it will all be MD-SAL, but (at least to me) it seems overly aggressive to call it MD-SAL only for the first release.
Just my 2c.
Thanks,
Madhu
From: Phil Robb <probb@...>
Date: Tuesday, August 27, 2013 3:46 PM To: "tsc@..." <tsc@...> Subject: Re: [OpenDaylight TSC] Open Daylight Graphic for First Release Thanks to everyone for your comments of approval on the updated architecture diagram. I have not received any suggested edits so I have sent it to the graphic designers for final touches.
I'll send out the final version once I receive it.
Phil.
On Thu, Aug 22, 2013 at 5:03 PM, Phil Robb
<probb@...> wrote:
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
|
|
David Meyer <dmm@...>
On Thu, Aug 29, 2013 at 8:02 AM, Madhu Venugopal (vmadhu)
<vmadhu@...> wrote: Hi Phil,So here's a question: to what extent will code built for the non-MD-SAL have to be re{written,factored} in moving to the MD-SAL, and what are the issues one should consider in building code for the first release (non-MD-SAL) to make "conversion" to the MD-SAL as painless as possible? --dmm
|
|
Chris Wright <chrisw@...>
* Madhu Venugopal (vmadhu) (vmadhu@...) wrote:
Essentially, my suggestion is to have both AD-SAL (API Driven SAL) - am just inventing this acronym here :-)Or just call it SAL. I think it's hard to get that kind of subtlty across with a single graphic. From a user perspective...AD/MD... internel implementation detail. thanks, -chris
|
|
Madhu Venugopal (vmadhu) <vmadhu@...>
On 8/29/13 9:42 AM, "David Meyer" <dmm@...> wrote:
On Thu, Aug 29, 2013 at 8:02 AM, Madhu Venugopal (vmadhu) Can generate the exact SAL API Contract as AD-SAL. If this is achievedIf MD-SAL development is done with easy-migration in mind, then the the Functional Modules, NB-API modules and Plugin Modules has no change. But practically, it is extremely difficult to achieve and I will not even recommend that approach (fearing hacks in a potential clean MD-SAL approach). (which is almost all bundles) would need modifications. Also I hopeAssuming the Easy-migration is not considered, then every bit of code that MD-SAL will render some of the Redundant code auto-generated and hence the need for such modifications can be minimal. Again it is Difficult to answer until we have at least 1 working plugin to gauge the real impact. and what are the issues one should consider in building code for the approach. If we can pull in all the common set of issues inside theEd started with an Archetype to help with a template project for template, then the migration can be Made painless. With Modal-driven programming new to most (I take the liberty in calling it as most), It is just the inertia of change that is the biggest bottleneck. Tony, Ed & others are doing great in getting the community upto speed. If we continue on this we should be able to make the change. -Madhu
|
|
Madhu Venugopal (vmadhu) <vmadhu@...>
On 8/29/13 10:01 AM, "Chris Wright" <chrisw@...> wrote:
* Madhu Venugopal (vmadhu) (vmadhu@...) wrote:Essentially, my suggestion is to have both AD-SAL (API Driven SAL) - amOr just call it SAL. I think it's hard to get that kind of subtlty SAL (API Driven and Model Driven).Agreed. If others see a need to highlight these, we can do something Thanks, Madhu
|
|