Projects: OCP Plugin & OCP Protocol Library


Richard Chien <m8809301@...>
 

Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien


Colin Dixon
 

Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Robert Varga
 

It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert

On 2016-01-06 15:29, Colin Dixon wrote:

Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals


Colin Dixon
 

+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Richard Chien <m8809301@...>
 

I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development.
 
BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time.
 
-Richard 
 

Date: Wed, 6 Jan 2016 15:42:00 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: nite@...
CC: m8809301@...; project-proposals@...

+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Colin Dixon
 

As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right?

https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets

--Colin


On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development.
 
BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time.
 
-Richard 
 

Date: Wed, 6 Jan 2016 15:42:00 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: nite@...
CC: m8809301@...; project-proposals@...


+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




Richard Chien <m8809301@...>
 

Right. It's great to be a part of the ODL distribution.
 
-Richard
 

Date: Thu, 10 Mar 2016 14:06:13 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: m8809301@...
CC: nite@...; project-proposals@...

As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right?

https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets

--Colin


On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development.
 
BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time.
 
-Richard 
 

Date: Wed, 6 Jan 2016 15:42:00 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: nite@...
CC: m8809301@...; project-proposals@...


+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




Colin Dixon
 

I that case, I encourage you to note that the M1 milestone readout is due Thursday by 11:59p UTC.

An will send out a mail like this for offset 1 projects:

The template will be the same though, so you could just use that.

Also, it probably makes sense to familiarize yourself with the Boron release plan:

On Friday, March 11, 2016, Richard Chien <m8809301@...> wrote:
Right. It's great to be a part of the ODL distribution.
 
-Richard
 

Date: Thu, 10 Mar 2016 14:06:13 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: m8809301@...
CC: nite@...; project-proposals@...

As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right?

https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets

--Colin


On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development.
 
BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time.
 
-Richard 
 

Date: Wed, 6 Jan 2016 15:42:00 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: nite@...
CC: m8809301@...; project-proposals@...


+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




Richard Chien <m8809301@...>
 

Okay, I will start working on the project release plan. Thanks.

-Richard

Sent from my ASUS


-------- 原始郵件 --------
寄件者:Colin Dixon
傳送日期:Mon, 14 Mar 2016 20:23:26 +0800
收件者:Richard Chien
副本:project-proposals@...
主旨:Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library

I that case, I encourage you to note that the M1 milestone readout is due Thursday by 11:59p UTC.

An will send out a mail like this for offset 1 projects:

The template will be the same though, so you could just use that.

Also, it probably makes sense to familiarize yourself with the Boron release plan:
https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan 

Cheers,
--Colin

On Friday, March 11, 2016, Richard Chien <m8809301@...> wrote:

Right. It's great to be a part of the ODL distribution.
 
-Richard
 

Date: Thu, 10 Mar 2016 14:06:13 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: m8809301@...
CC: nite@...; project-proposals@...

As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right?

https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets

--Colin


On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development.
 
BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time.
 
-Richard 
 

Date: Wed, 6 Jan 2016 15:42:00 -0500
Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@...
To: nite@...
CC: m8809301@...; project-proposals@...


+1 to what Robert said.

In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently.

--Colin


On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
It does seem it is inspired by what we have in OpenFlow world. The reasons for the split in OF are mostly due to the requirement to support multiple incompatible version (1.0 and 1.3 in OFJ), providing a single northbound interface and performing translation (OFP).

Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide.

From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB).

Bye,
Robert


On 2016-01-06 15:29, Colin Dixon wrote:
Out of curiosity, is there a reason you'd like to have two projects rather than one?

--Colin


On Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
Hi,
 
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you.
 
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin
https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library
 
Richard Chien

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals