Date   

Supported openflow versions ?

Benny Rochwerger <BennyR@...>
 

All,

 

I am not sure which is the right mailing list to post this question, so please forgive me for cross-posting or if these are not the right lists (in which case, I’ll appreciate if someone points to the right place).

 

We are building an application that leverages some of the features in OF 1.3. Our current prototype is built on NOX, but as we adopt ODP, we would like to be able to move all our applications to a single controller.  

 

What are the plans for supporting OF 1.3 ? I assume that by the time of the first official release, OF 1.3 will be included, but will it be available in the repository prior to that ?  

 

Thanks in advance,

 

Benny Rochwerger


Re: I won't be able to make the TSC call this week

David Meyer <dmm@...>
 

Thnx Tom. --dmm

On Tue, Jun 11, 2013 at 9:14 AM, Thomas Nadeau <tnadeau@...> wrote:

I will be in the air on Thursday during the call so I cannot make it
either. That reminds me that we have not sorted out the proxy situation
yet.

--Tom


On 6/10/13 8:26 AM, "David Meyer" <dmm@...> wrote:

Folks,

I'll be on an "interesting" trip to Japan so won't be able to make the
call. Chris Wright has graciously agreed to run the call.

Thanks,

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



Code Prep Suggestions for new Projects

Ed Warnicke (eaw) <eaw@...>
 

Guys,
I put together a preliminary page of 'code prep suggestions' for new projects… not binding things,
but rather 'so you are cleaning up your code to open source it… these are good things to think about' things.
I'd love to hear feedback from folks on what's there, and what changes folks think should be there:


Ed


Re: I won't be able to make the TSC call this week

Thomas Nadeau <tnadeau@...>
 

I will be in the air on Thursday during the call so I cannot make it
either. That reminds me that we have not sorted out the proxy situation
yet.

--Tom

On 6/10/13 8:26 AM, "David Meyer" <dmm@...> wrote:

Folks,

I'll be on an "interesting" trip to Japan so won't be able to make the
call. Chris Wright has graciously agreed to run the call.

Thanks,

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


I won't be able to make the TSC call this week

David Meyer <dmm@...>
 

Folks,

I'll be on an "interesting" trip to Japan so won't be able to make the
call. Chris Wright has graciously agreed to run the call.

Thanks,

--dmm


Proposal to discuss and vote on the Simultaneous Release Plan

Ed Warnicke (eaw) <eaw@...>
 

I would like to propose that we discuss and vote on the Simultaneous Release Plan:


at next Thursdays (June 13) TSC meeting.

I strongly encourage discussion of the plan on the list prior to that time :)

Ed


Proposal to vote to accept VTN project

Ed Warnicke (eaw) <eaw@...>
 

I would like to propose that we hold the VTN project creation review and vote to accept
it at the next TSC meeting (this coming Thursday June 13).  

The proposal is here:

I believe they are seeking to enter in bootstrap state.

Ed


Canceled Event: OpenDaylight TSC Meeting @ Thu Jun 6, 2013 11am - 1pm (probb@linuxfoundation.org)

Phil Robb
 

This event has been canceled and removed from your calendar.

OpenDaylight TSC Meeting

Meeting URL: https://meetings.webex.com/collabs/meetings/join?uuid=MA3SRND964PIX06V2LS3SXX3RE-9VIB

Access Information
Meeting number: 194 548 370
Meeting password: This meeting does not require a password.

Audio Connection
1-855-244-8681 Call-in toll-free number (US/Canada)
1-650-479-3207 Call-in toll number (US/Canada)
Access code: 194 548 370

When
Thu Jun 6, 2013 11am – 1pm Mountain Time
Where
+1 650-479-3207 - Additional connection information in event description (map)
Calendar
probb@...
Who
Philip Robb - organizer
tsc@...

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


Thoughts and request for guidance.

Sitaraman Vilayannur
 

Hi, 
  Hope this an appropriate group to broach this. 
  Is something along the below lines for the controller and management of SDN network and it open source implementation in the works...any pointers,  feedbacks/guidance is much appreciated.
 Thanks much.
Sitaraman


Exploiting SDN Capabilities:

Some thoughts on the controller considerations for exploiting programmable networks with information centric or content based routing. 

 I was listening in to Stanfords Courseera course on PGM and Expander Graphs..and chanced upon Feynmans lectures where he was talking about the relationship to Mathematics and Physics where though Feynman hadnt mentioned  explicitly seemed to touch upon convexity and duality.... ..and attempted to relate this to SDN networks....

Duality between the algorithmic approach and the nature of the optimization problem.

                One convex algorithmic approach could be to resort to viewing the entire problem as a graph and optimize on the nature of such graph.

                One non-convex algorithmic approach could be a  Newton gradient method.

Decomposition of an overall optimization problem into non-convex subcomponents which subcomponents can be treated jointly as a convex problem.  Such decomposition method could be by determining components (Exapander components?) that are well connected.

 

SDN:

Convexity could vary with the time window size of the problem.   At a given time instant or narrow time window, (routing) the problem is a convex one which one or a narrow set of optimum routing decisions, but due to changing traffic conditions, over a period of time individual routing decisions become a non-convex optimization problem. Therefore, an SDN control could possibly have non-convex (greedy?) approach component and a non-greedy component (viewing problem as a graph with expander subcomponets, each of which could in turn apply the greedy method).

When we bring time axis into the picture, the convexity of the problem changes from convex (short time window) to non-convex (large time window, to make decisions based on current and expected traffic pattern). Therefore the algorithmic approach to the control could change from  a non-convex (short time frame) to a convex (large time frame).  One way of doing this could be for the non-convex components to contribute weights (which determination could have a convex nature to it or at least partly determined by a convex component) to the elements of the convex components (a graph)

When one considers the Information based routing capability, ICN or advanced versions of the same. Here for a short time window, the placement of Information is a non-convex problem, and based on typical information demand, over a large time-window (placement and information content of caches ) could be considered a convex one.   Therefore, information superimposes an orthogonal nature on the convexity to the data component of the SDN-ICN combine.

Stochasticity and time window: While routing in any given network necessarily has to be deterministic, the optimal nature of the same introduces stochasticity amongst the possibly multiple options each of which individually yield deterministic routing. 

Here we would then need to consider the same issues as above wherein a general problem could be started off with a PGM and based on expander sections of this graph, now be decomposed into its non-convex (nature of the probabilistic problem) subcomponents.  It appears that information placement and routing could draw heavily on such PGM as semantic connectivity (again to be considered both across space and time as the vanilla version described above) could be probabilistic. Bringing in Content based Routing and Information Centric Routing therefore could be viewed as  bringing in a "placement" component to routing problem, eerily close but probably a lot more complex than what the VLSI folks deal with.  Therefore, the hardware folks probably have nothing to worry Software Defined Networks are going to use Hardware algorithms after all 


Re: Finalizing HackFest Dates Around OSCON

Thomas Nadeau <tnadeau@...>
 


I would agree with that approach Phil. I actually recommended that we do it a week earlier than that.  The concern is that the IETF is in Berlin starting the Sunday of that week.   For those that have to travel to California for the HackFest, flying all the way to Germany a two days later isn't going to be a good time so pushing that back as much as possible is welcomed.

--Tom


From: Phil Robb <probb@...>
Date: Friday, May 31, 2013 3:58 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Finalizing HackFest Dates Around OSCON

Hello TSC:

At the most recent meeting, the TSC decided to hold a HackFest coincident with OSCON on the 23rd and 24th of July (Tuesday/Wednesday) of that week.

After thinking about this, I want to raise an issue on having the Hackfest on the Tuesday/Wednesday during OSCON.

OSCON is partitioned into two activities that week.  On Monday and Tuesday, there are tutorial sessions on specific topics.  The cost of the Tutorial days is separate from the OSCON conference, and  the tutorials have a much smaller attendance than the regular conference.

Wednesday through Friday is the OSCON conference.  Starting Wednesday morning, Keynotes, and general OSCON sessions will begin.  As with many conferences, the first day is often the most well-attended, and content-rich.

I would suggest that we either do a two day HackFest on Monday/Tuesday (22/23), or do a single day HackFest on Tuesday the 23rd (to accommodate the desire for no weekend travel).  Since we are trying to get OSCON conference goers to attend the HackFest, I don't think we should create a conflict with the most important day of the event.

What are your thoughts?

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Finalizing HackFest Dates Around OSCON

Phil Robb
 

Hello TSC:

At the most recent meeting, the TSC decided to hold a HackFest coincident with OSCON on the 23rd and 24th of July (Tuesday/Wednesday) of that week.

After thinking about this, I want to raise an issue on having the Hackfest on the Tuesday/Wednesday during OSCON.

OSCON is partitioned into two activities that week.  On Monday and Tuesday, there are tutorial sessions on specific topics.  The cost of the Tutorial days is separate from the OSCON conference, and  the tutorials have a much smaller attendance than the regular conference.

Wednesday through Friday is the OSCON conference.  Starting Wednesday morning, Keynotes, and general OSCON sessions will begin.  As with many conferences, the first day is often the most well-attended, and content-rich.

I would suggest that we either do a two day HackFest on Monday/Tuesday (22/23), or do a single day HackFest on Tuesday the 23rd (to accommodate the desire for no weekend travel).  Since we are trying to get OSCON conference goers to attend the HackFest, I don't think we should create a conflict with the most important day of the event.

What are your thoughts?

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: [OpenDaylight Discuss] Proposed Simultaneous Release Plan

Ed Warnicke (eaw) <eaw@...>
 

One other thing to keep in mind, it's normal for a project to be responsible for it's own unit tests and 'local' integration tests
(by local I mean integration among the bundles it provides).

Clearly we will need to work something out for inter-project integration as a community.

Ed
On May 31, 2013, at 12:18 PM, David Erickson <daviderickson@...> wrote:

Alejandro-
There are existing unit tests within a project, and cross-project integration tests will have to be created prior to a release.  One existing project uses Maven and the other is being migrated from Ant to Maven.  I don't know that there are any dedicated QA people, but I consider every programmer a QA person :)

The included in-project unit and integration tests run with Maven would be a good place to start learning.

-David

On 5/30/2013 11:13 PM, Alejandro Avella wrote:
Hi Ed,

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

Regards,
Alejandro

On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed

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




_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Re: [OpenDaylight Discuss] Proposed Simultaneous Release Plan

Kalvin Hom (kahom) <kahom@...>
 

HI Alejandro,

 

The current tests in the controller project are using JUnit for the individual bundles, and separate integration tests are written in their own bundles using Pax-Exam.  Whenever a commit is checked-in, the Jenkins build also runs the tests, and if any of them fail, it leaves a -1 review in Gerrit saying the build is UNSTABLE.

 

There’s a wiki page on the integration tests here:  https://wiki.opendaylight.org/view/OpenDaylight_Controller:Integration_Tests

 

Kalvin

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of David Erickson
Sent: Friday, May 31, 2013 10:18 AM
To: Alejandro Avella
Cc: discuss@...; tsc@...
Subject: Re: [OpenDaylight Discuss] [OpenDaylight TSC] Proposed Simultaneous Release Plan

 

Alejandro-
There are existing unit tests within a project, and cross-project integration tests will have to be created prior to a release.  One existing project uses Maven and the other is being migrated from Ant to Maven.  I don't know that there are any dedicated QA people, but I consider every programmer a QA person :)

The included in-project unit and integration tests run with Maven would be a good place to start learning.

-David

On 5/30/2013 11:13 PM, Alejandro Avella wrote:

Hi Ed,

 

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

 

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

 

Regards,

Alejandro

On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:

I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed

in todays TSC call to the list.

 

You can find it here:

 

I have made the following edits in response to requests from the TSC since we discussed it:

1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 

'discuss'.

2)  I have added a 'String Freeze' to allow for internationalization to M5.

 

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,

but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 

to correctly incorporate that :)

 

Ed


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

 




_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 


Re: Proposed Simultaneous Release Plan

Alejandro Avella <robertico.gonzalez77@...>
 

Hi Ed,

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

Regards,
Alejandro


On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed

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



Proposed Simultaneous Release Plan

Ed Warnicke (eaw) <eaw@...>
 

I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed


OpenDaylight TSC Meeting Minutes from 5/23

Phil Robb
 

Hello TSC Members:

Please find the meeting minutes attached.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

So the action was for the TSC folks to review that bare text and comment
on how to modify it for our use. Please keep in mind that during our
discussion these points were raised as desirable goals:

1) quorum needed
2) simple majority for votes
3) 4 days notice for proposed votes (at least for major items)
4) All TSC members attend each meeting or their delegate
5) It seemed that we did not want email based voting based on #4 above.


--Tom

On 5/23/13 2:02 PM, "Chris Wright" <chrisw@...> wrote:


Here is the openstack TC wording

https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee


Re: motions and proxy voting proposals

Chris Wright <chrisw@...>
 


Re: motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

On 5/23/13 11:23 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:

A few thoughts inlineŠ

On May 16, 2013, at 12:11 PM, Thomas Nadeau <tnadeau@...> wrote:


Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be
counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
I am a little concerned with this provision. Consider for example a vote
raised
over the Christmas holidays, with only three TSC members voting at all.
The TSC charter is pretty clear currently that simple majority should be
used
for decisions of the TSC, and that feels right.
I think a simple majority is what that paragraph meant. We could just
say "Decisions require a simple majority"

--Tom





Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a
meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.







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


Re: motions and proxy voting proposals

Ed Warnicke (eaw) <eaw@...>
 

A few thoughts inline…

On May 16, 2013, at 12:11 PM, Thomas Nadeau <tnadeau@...> wrote:


Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
I am a little concerned with this provision. Consider for example a vote raised
over the Christmas holidays, with only three TSC members voting at all.
The TSC charter is pretty clear currently that simple majority should be used
for decisions of the TSC, and that feels right.


Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.







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

14141 - 14160 of 14349