Date   

Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Yes, we have a new name OVIL (Opendaylight VPP Interface Layer) for it, Ed agreed with this name J So I think you can start formal creation review thread on the TSC mailing list.

 

Because of name change, I drafted a new page for this, https://wiki.opendaylight.org/view/Project_Proposals:OVIL, you can still use the old one https://wiki.opendaylight.org/view/Project_Proposals:Vpp for convenience.

 

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, July 13, 2017 11:58 PM
To: Ed Warnicke <hagbard@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

So, assuming the name is fixed, should we start a formal creation review thread on the TSC mailing list?

 

--Colin

 


Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Yes, we have a new name OVIL (Opendaylight VPP Interface Layer) for it, Ed agreed with this name J So I think you can start formal creation review thread on the TSC mailing list.

 

Because of name change, I drafted a new page for this, https://wiki.opendaylight.org/view/Project_Proposals:OVIL, you can still use the old one https://wiki.opendaylight.org/view/Project_Proposals:Vpp for convenience.

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, July 13, 2017 11:58 PM
To: Ed Warnicke <hagbard@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

So, assuming the name is fixed, should we start a formal creation review thread on the TSC mailing list?

 

--Colin

 

 

On Mon, Jul 10, 2017 at 6:00 PM, Ed Warnicke <hagbard@...> wrote:

Yi,

 

honeycomb/vbd is named that way :)

 

Ed

 

On Mon, Jul 10, 2017 at 5:26 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Can a project name contain “/”? NetVirt is just one of its consumers, we can’t name it as “netvirt”. Logically honeycombplugin is better, but obviously peope can’t think of vpp from such name J

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Monday, July 10, 2017 10:50 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Colin Dixon <colin@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

Yang,

 

The thing is, its talking to honeycomb, which is talking to vpp, but could also talk to other things as well.  My suggestion would be:

 

honeycomb/netvirt

 

Ed

 

On Fri, Jul 7, 2017 at 4:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 

 

 

 


Re: A new project proposal vpp

Colin Dixon
 

So, assuming the name is fixed, should we start a formal creation review thread on the TSC mailing list?

--Colin


On Mon, Jul 10, 2017 at 6:00 PM, Ed Warnicke <hagbard@...> wrote:
Yi,

honeycomb/vbd is named that way :)

Ed

On Mon, Jul 10, 2017 at 5:26 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Can a project name contain “/”? NetVirt is just one of its consumers, we can’t name it as “netvirt”. Logically honeycombplugin is better, but obviously peope can’t think of vpp from such name J

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Monday, July 10, 2017 10:50 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Colin Dixon <colin@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...ylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

Yang,

 

The thing is, its talking to honeycomb, which is talking to vpp, but could also talk to other things as well.  My suggestion would be:

 

honeycomb/netvirt

 

Ed

 

On Fri, Jul 7, 2017 at 4:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...ylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...ylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...ylight.org
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 

 




Re: A new project proposal vpp

Edward Warnicke
 

Yi,

honeycomb/vbd is named that way :)

Ed

On Mon, Jul 10, 2017 at 5:26 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Can a project name contain “/”? NetVirt is just one of its consumers, we can’t name it as “netvirt”. Logically honeycombplugin is better, but obviously peope can’t think of vpp from such name J

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Monday, July 10, 2017 10:50 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Colin Dixon <colin@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

Yang,

 

The thing is, its talking to honeycomb, which is talking to vpp, but could also talk to other things as well.  My suggestion would be:

 

honeycomb/netvirt

 

Ed

 

On Fri, Jul 7, 2017 at 4:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 

 



Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Can a project name contain “/”? NetVirt is just one of its consumers, we can’t name it as “netvirt”. Logically honeycombplugin is better, but obviously peope can’t think of vpp from such name J

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Monday, July 10, 2017 10:50 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Colin Dixon <colin@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

Yang,

 

The thing is, its talking to honeycomb, which is talking to vpp, but could also talk to other things as well.  My suggestion would be:

 

honeycomb/netvirt

 

Ed

 

On Fri, Jul 7, 2017 at 4:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 

 


Re: A new project proposal vpp

Edward Warnicke
 

Yang,

The thing is, its talking to honeycomb, which is talking to vpp, but could also talk to other things as well.  My suggestion would be:

honeycomb/netvirt

Ed

On Fri, Jul 7, 2017 at 4:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 



Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Ed, can you propose a better name for it? How about vppplugin?

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Friday, July 7, 2017 11:24 PM
To: Colin Dixon <colin@...>
Cc: Yang, Yi Y <yi.y.yang@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

Has the proposed project name and repo been changed to something other than 'vpp' ?

 

Ed

 

 

On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 

 


Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Thanks, Colin, email review is better to me, please help start this email review process.

 

From: Colin Dixon [mailto:colin@...]
Sent: Friday, July 7, 2017 11:23 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Ed Warnicke <hagbard@...>; Robert Varga <nite@...>; Tomas Cechvala -X (tcechval - PANTHEON TECHNOLOGIES at Cisco) <tcechval@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

 

--Colin

 

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 


Re: A new project proposal vpp

Edward Warnicke
 

Has the proposed project name and repo been changed to something other than 'vpp' ?

Ed


On Fri, Jul 7, 2017 at 8:22 AM, Colin Dixon <colin@...> wrote:
The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

--Colin

On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@lists.opendaylight.org


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 



Re: A new project proposal vpp

Colin Dixon
 

The next APAC-friendly TSC call is scheduled for July 27th. If you're willing to wait until then, that call is at 11:30a Beijing time. Otherwise, we can have the creation review happen over e-mail if it needs to be sooner. Changing the TSC schedule is... more complicated.

--Colin


On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y <yi.y.yang@...> wrote:

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 


Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Thanks Colin, good summary, I discussed it with Tomas and Ed privately, I think they have well understood why we need this project. it seems weekly TSC meeting time is Beijing Time 1:00 AM, can you schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?

 

From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

 

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

 

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

 

Cheers,

--Colin

 

 

On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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

 


Re: A new project proposal vpp

Colin Dixon
 

So, it sounds to me like the project proposal wanted to try to factor out the common elements of how SFC, NetVirt, and GBP would talk to VPP to do service chaining int one place so that (a) the code could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.

Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.

I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:

Cheers,
--Colin


On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
> On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
> <mailto:yi.y.yang@...>> wrote:
>
>     For vpp renderer, it needs to render bridge domain information
>     (neutron network, including VNI) and interfaces to bridge domain,
>     vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
>     model on ODL side is different from information model on VPP node
>     side, especially for sfc, vpp renderer will also render RSP to
>     bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
>     RSP spans. sfc vpp renderer is much more complicated than NetVirt
>     needs, so we can use the existing code in sfc vpp renderer to
>     achieve a vpp renderer NetVirt needs very easily.
>
>
>
> I'm still not clear on what models are being rendered to what models.
> The SFC renderer renders the SFC models to the models being mounted
> via netconf.  It sounds like the *to* side of rendering is the models
> mounted via netconf.  What precisely are the *from* models?  Are we
> writing new models in this project for bridge domains, vxlan,
> vxlan-gpe, etc.  It also sounds like you are taking a small fragment
> of the SFC model and creating a new model for a bunch of virtual
> bridging concepts (similar to what is done in VBD).  Are there
> existing models being rendered to the netconf mounted models?

I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert

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


Re: 答复: Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review

Colin Dixon
 

Cool! Thank you for your time and understanding. It seems like a really cool project and we look forward to seeing more.

For what it's worth, BIER is getting some broader attention:

Having robust support in ODL matters.

--Colin


On Sun, Jun 25, 2017 at 11:17 PM, <xiong.quan@...> wrote:



Hi Colin,


    Right ,the BIER-APP shares the release plan and repository and no need to use other resource.

    We will accomplish the BIER progress with BIER-APP as its sub-part dependent project together.


Thanks,

Xiong





熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@....org>;高陈强10202383;宦林英10042773; <project-proposals@lists.opendaylight.org>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月24日 01:54
主 题 :Re: 答复: Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


OK. So, the plan is that this won't be it's own project, but will just be part of the the existing BIER proejct in the same repository?
--Colin


On Fri, Jun 23, 2017 at 3:40 AM,  <xiong.quan@...> wrote:

Hi Colin,


Thank you for the support in BIER_APP creation review.

First, we agree with you and I will set the bier_app project as a sub-part of the bier project.

Second, we prefer the bierapp and it will work better for the following progress. I will change the name "BIER_APP" and add bierapp to BIER project.


Best Regards,

Xiong




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@...rg>;高陈强10202383;宦林英10042773; <project-proposals@...aylight.org>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月23日 01:29
主 题 :Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Following up from the TSC call, which has notes here:

There are two items. That we'd love your feedback on:

1.) It still seems like there's lots of people that think it might make sense to just keep the bier_app project as a sub-part of the bier project for a bunch of reasons including:
   * lower overhead in the form of milestone readouts, testing readouts, jenkins job maintenance, etc.
   * lower overhead for other people who do per-project work, e.g., integration/test, documentation
   * at least the short run, there tends to be patches that end up having to go both into the plugin and the app from our past experiences
   * you can still produce independent artifacts that could be re-used outside OpenDaylight without having a separate project

That all being said, if the two projects (and overlapping people) really agree that there should be two projects, we won't stand in the way.

2.) We need to figure out if there's any technical reason that we would rather not have bier_app as the git repository name. It will work fine for git, but it also gets re-used as an identifier in lots of places, e.g., maven groupIds, java package names. I _think_ underscores are fine in all those places, but it might be slightly safer to use bierapp if that works for you. Again, barring somebody telling me that this is technically infeasible, the call is yours.

Cheers,
--Colin


On Tue, Jun 20, 2017 at 10:25 AM, Colin Dixon <colin@...> wrote:
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here:

Specifically:


APAC Meeting (Held every 4th Thursday)


We'll also take notes and maybe questions on IRC as stated on the TSC page.

See you then,
--Colin

On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:

Hi Colin,


I have uploaded the presentation slides, the link is as follows.

https://wiki.opendaylight.org/view/File:Presentation-bierapp-proposal-review.pdf


I want to know  if  we should conduct  the meeting on zoom with the number 423 359 597.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月13日 22:39
主 题 :Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Thank you.
--Colin


On Sun, Jun 11, 2017 at 9:44 PM,  <xiong.quan@...> wrote:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Understood.. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...aylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...rg>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  <xiong.quan@...> wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R..China, 430022
T: +86 27 13871144372
E: xiong..quan@...
www.zte.com.cn

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









Re: 答复: Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review

xiong.quan@...
 



Hi Colin,


    Right ,the BIER-APP shares the release plan and repository and no need to use other resource.

    We will accomplish the BIER progress with BIER-APP as its sub-part dependent project together.


Thanks,

Xiong





熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@...>;高陈强10202383;宦林英10042773; <project-proposals@...>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月24日 01:54
主 题 :Re: 答复: Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


OK. So, the plan is that this won't be it's own project, but will just be part of the the existing BIER proejct in the same repository?
--Colin


On Fri, Jun 23, 2017 at 3:40 AM,  <xiong.quan@...> wrote:

Hi Colin,


Thank you for the support in BIER_APP creation review.

First, we agree with you and I will set the bier_app project as a sub-part of the bier project.

Second, we prefer the bierapp and it will work better for the following progress. I will change the name "BIER_APP" and add bierapp to BIER project.


Best Regards,

Xiong




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@....org>;高陈强10202383;宦林英10042773; <project-proposals@lists.opendaylight.org>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月23日 01:29
主 题 :Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Following up from the TSC call, which has notes here:

There are two items. That we'd love your feedback on:

1.) It still seems like there's lots of people that think it might make sense to just keep the bier_app project as a sub-part of the bier project for a bunch of reasons including:
   * lower overhead in the form of milestone readouts, testing readouts, jenkins job maintenance, etc.
   * lower overhead for other people who do per-project work, e.g., integration/test, documentation
   * at least the short run, there tends to be patches that end up having to go both into the plugin and the app from our past experiences
   * you can still produce independent artifacts that could be re-used outside OpenDaylight without having a separate project

That all being said, if the two projects (and overlapping people) really agree that there should be two projects, we won't stand in the way.

2.) We need to figure out if there's any technical reason that we would rather not have bier_app as the git repository name. It will work fine for git, but it also gets re-used as an identifier in lots of places, e.g., maven groupIds, java package names. I _think_ underscores are fine in all those places, but it might be slightly safer to use bierapp if that works for you. Again, barring somebody telling me that this is technically infeasible, the call is yours.

Cheers,
--Colin


On Tue, Jun 20, 2017 at 10:25 AM, Colin Dixon <colin@...> wrote:
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here:

Specifically:


APAC Meeting (Held every 4th Thursday)


We'll also take notes and maybe questions on IRC as stated on the TSC page.

See you then,
--Colin

On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:

Hi Colin,


I have uploaded the presentation slides, the link is as follows.

https://wiki.opendaylight.org/view/File:Presentation-bierapp-proposal-review.pdf


I want to know  if  we should conduct  the meeting on zoom with the number 423 359 597.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月13日 22:39
主 题 :Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Thank you.
--Colin


On Sun, Jun 11, 2017 at 9:44 PM,  <xiong.quan@...> wrote:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Understood.. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...aylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...rg>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  <xiong.quan@...> wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R..China, 430022
T: +86 27 13871144372
E: xiong..quan@...
www.zte.com.cn

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








Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review

Colin Dixon
 

OK. So, the plan is that this won't be it's own project, but will just be part of the the existing BIER proejct in the same repository?

--Colin


On Fri, Jun 23, 2017 at 3:40 AM, <xiong.quan@...> wrote:

Hi Colin,


Thank you for the support in BIER_APP creation review.

First, we agree with you and I will set the bier_app project as a sub-part of the bier project.

Second, we prefer the bierapp and it will work better for the following progress. I will change the name "BIER_APP" and add bierapp to BIER project.


Best Regards,

Xiong




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@....org>;高陈强10202383;宦林英10042773; <project-proposals@lists.opendaylight.org>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月23日 01:29
主 题 :Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Following up from the TSC call, which has notes here:

There are two items. That we'd love your feedback on:

1.) It still seems like there's lots of people that think it might make sense to just keep the bier_app project as a sub-part of the bier project for a bunch of reasons including:
   * lower overhead in the form of milestone readouts, testing readouts, jenkins job maintenance, etc.
   * lower overhead for other people who do per-project work, e.g., integration/test, documentation
   * at least the short run, there tends to be patches that end up having to go both into the plugin and the app from our past experiences
   * you can still produce independent artifacts that could be re-used outside OpenDaylight without having a separate project

That all being said, if the two projects (and overlapping people) really agree that there should be two projects, we won't stand in the way.

2.) We need to figure out if there's any technical reason that we would rather not have bier_app as the git repository name. It will work fine for git, but it also gets re-used as an identifier in lots of places, e.g., maven groupIds, java package names. I _think_ underscores are fine in all those places, but it might be slightly safer to use bierapp if that works for you. Again, barring somebody telling me that this is technically infeasible, the call is yours.

Cheers,
--Colin


On Tue, Jun 20, 2017 at 10:25 AM, Colin Dixon <colin@...> wrote:
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here:

Specifically:


APAC Meeting (Held every 4th Thursday)


We'll also take notes and maybe questions on IRC as stated on the TSC page.

See you then,
--Colin

On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:

Hi Colin,


I have uploaded the presentation slides, the link is as follows.

https://wiki.opendaylight.org/view/File:Presentation-bierapp-proposal-review.pdf


I want to know  if  we should conduct  the meeting on zoom with the number 423 359 597.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月13日 22:39
主 题 :Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Thank you.
--Colin


On Sun, Jun 11, 2017 at 9:44 PM,  <xiong.quan@...> wrote:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...aylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...rg>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Understood.. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...aylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...rg>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  <xiong.quan@...> wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R..China, 430022
T: +86 27 13871144372
E: xiong..quan@...
www.zte.com.cn

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






Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review

xiong.quan@...
 

Hi Colin,


Thank you for the support in BIER_APP creation review.

First, we agree with you and I will set the bier_app project as a sub-part of the bier project.

Second, we prefer the bierapp and it will work better for the following progress. I will change the name "BIER_APP" and add bierapp to BIER project.


Best Regards,

Xiong




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <an.ho@...>; <bier-dev@...>;高陈强10202383;宦林英10042773; <project-proposals@...>;喻敬海10005643; <tsc@...>;
日 期 :2017年06月23日 01:29
主 题 :Re: Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Following up from the TSC call, which has notes here:
There are two items. That we'd love your feedback on:

1.) It still seems like there's lots of people that think it might make sense to just keep the bier_app project as a sub-part of the bier project for a bunch of reasons including:
   * lower overhead in the form of milestone readouts, testing readouts, jenkins job maintenance, etc.
   * lower overhead for other people who do per-project work, e.g., integration/test, documentation
   * at least the short run, there tends to be patches that end up having to go both into the plugin and the app from our past experiences
   * you can still produce independent artifacts that could be re-used outside OpenDaylight without having a separate project

That all being said, if the two projects (and overlapping people) really agree that there should be two projects, we won't stand in the way.

2.) We need to figure out if there's any technical reason that we would rather not have bier_app as the git repository name. It will work fine for git, but it also gets re-used as an identifier in lots of places, e.g., maven groupIds, java package names. I _think_ underscores are fine in all those places, but it might be slightly safer to use bierapp if that works for you. Again, barring somebody telling me that this is technically infeasible, the call is yours.

Cheers,
--Colin


On Tue, Jun 20, 2017 at 10:25 AM, Colin Dixon <colin@...> wrote:
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here:

Specifically:


APAC Meeting (Held every 4th Thursday)


We'll also take notes and maybe questions on IRC as stated on the TSC page.

See you then,
--Colin

On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:

Hi Colin,


I have uploaded the presentation slides, the link is as follows.

https://wiki.opendaylight.org/view/File:Presentation-bierapp-proposal-review.pdf


I want to know  if  we should conduct  the meeting on zoom with the number 423 359 597.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月13日 22:39
主 题 :Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Thank you.
--Colin


On Sun, Jun 11, 2017 at 9:44 PM,  <xiong.quan@...> wrote:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Understood.. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@lists.opendaylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@....org>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  <xiong.quan@...> wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R..China, 430022
T: +86 27 13871144372
E: xiong..quan@...
www.zte.com.cn

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





Re: A new project proposal vpp

Yang, Yi Y <yi.y.yang@...>
 

Hi, Robert

vpp data store isn't mirror of data store in honeycomb/vpp node, they are some intermediate data, vpp renderer and classifier will renderer them to real vpp data in honeycomb/vpp node, I'll work out a PoC to show you what it looks like.

we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.

-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

On 20/06/17 15:39, Ed Warnicke wrote:
On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
<mailto:yi.y.yang@...>> wrote:

For vpp renderer, it needs to render bridge domain information
(neutron network, including VNI) and interfaces to bridge domain,
vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
model on ODL side is different from information model on VPP node
side, especially for sfc, vpp renderer will also render RSP to
bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
RSP spans. sfc vpp renderer is much more complicated than NetVirt
needs, so we can use the existing code in sfc vpp renderer to
achieve a vpp renderer NetVirt needs very easily.



I'm still not clear on what models are being rendered to what models.
The SFC renderer renders the SFC models to the models being mounted
via netconf. It sounds like the *to* side of rendering is the models
mounted via netconf. What precisely are the *from* models? Are we
writing new models in this project for bridge domains, vxlan,
vxlan-gpe, etc. It also sounds like you are taking a small fragment
of the SFC model and creating a new model for a bunch of virtual
bridging concepts (similar to what is done in VBD). Are there
existing models being rendered to the netconf mounted models?
I tend to agree with Ed's point. I am probably missing something, as I am not too fluent in SFC/GBP information models nor how they align with NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered onto a target device (which happens to be VPP, but it's really about models).

What would be the models for "VPP data store"? Is this a mirror of the SB device's model and are we talking about the proposed project performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal in its current form. I think it needs to be beefed up with details of interactions and needs to be vetted by all of GBP, SFC and NetVirt to make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays with netconf topology -- as I mentioned "VPP node" is in reality any SB device implementing a specific set of models (either directly or through an adaptor).

Regards,
Robert


Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review

Colin Dixon
 

Following up from the TSC call, which has notes here:

There are two items. That we'd love your feedback on:

1.) It still seems like there's lots of people that think it might make sense to just keep the bier_app project as a sub-part of the bier project for a bunch of reasons including:
   * lower overhead in the form of milestone readouts, testing readouts, jenkins job maintenance, etc.
   * lower overhead for other people who do per-project work, e.g., integration/test, documentation
   * at least the short run, there tends to be patches that end up having to go both into the plugin and the app from our past experiences
   * you can still produce independent artifacts that could be re-used outside OpenDaylight without having a separate project

That all being said, if the two projects (and overlapping people) really agree that there should be two projects, we won't stand in the way.

2.) We need to figure out if there's any technical reason that we would rather not have bier_app as the git repository name. It will work fine for git, but it also gets re-used as an identifier in lots of places, e.g., maven groupIds, java package names. I _think_ underscores are fine in all those places, but it might be slightly safer to use bierapp if that works for you. Again, barring somebody telling me that this is technically infeasible, the call is yours.

Cheers,
--Colin


On Tue, Jun 20, 2017 at 10:25 AM, Colin Dixon <colin@...> wrote:
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here:

Specifically:


APAC Meeting (Held every 4th Thursday)


We'll also take notes and maybe questions on IRC as stated on the TSC page.

See you then,
--Colin

On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:

Hi Colin,


I have uploaded the presentation slides, the link is as follows.

https://wiki.opendaylight.org/view/File:Presentation-bierapp-proposal-review.pdf


I want to know  if  we should conduct  the meeting on zoom with the number 423 359 597.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月13日 22:39
主 题 :Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Thank you.
--Colin


On Sun, Jun 11, 2017 at 9:44 PM,  <xiong.quan@...> wrote:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


Understood.. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@lists.opendaylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@....org>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  xiong.quan@... wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn

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



Re: A new project proposal vpp

Robert Varga
 

On 20/06/17 15:39, Ed Warnicke wrote:
On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
<mailto:yi.y.yang@...>> wrote:

For vpp renderer, it needs to render bridge domain information
(neutron network, including VNI) and interfaces to bridge domain,
vxlan, vxlan-gpe, vhostuser etc in vpp node, you know information
model on ODL side is different from information model on VPP node
side, especially for sfc, vpp renderer will also render RSP to
bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node
RSP spans. sfc vpp renderer is much more complicated than NetVirt
needs, so we can use the existing code in sfc vpp renderer to
achieve a vpp renderer NetVirt needs very easily.



I'm still not clear on what models are being rendered to what models.
The SFC renderer renders the SFC models to the models being mounted via
netconf. It sounds like the *to* side of rendering is the models
mounted via netconf. What precisely are the *from* models? Are we
writing new models in this project for bridge domains, vxlan, vxlan-gpe,
etc. It also sounds like you are taking a small fragment of the SFC
model and creating a new model for a bunch of virtual bridging concepts
(similar to what is done in VBD). Are there existing models being
rendered to the netconf mounted models?
I tend to agree with Ed's point. I am probably missing something, as I
am not too fluent in SFC/GBP information models nor how they align with
NetVirt's view of the world.

I think we have multiple input models (SFC, netvirt, GBP) being rendered
onto a target device (which happens to be VPP, but it's really about
models).

What would be the models for "VPP data store"? Is this a mirror of the
SB device's model and are we talking about the proposed project
performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal
in its current form. I think it needs to be beefed up with details of
interactions and needs to be vetted by all of GBP, SFC and NetVirt to
make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays
with netconf topology -- as I mentioned "VPP node" is in reality any SB
device implementing a specific set of models (either directly or through
an adaptor).

Regards,
Robert


Re: [groupbasedpolicy-dev] A new project proposal vpp

Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES@Cisco) <mcmarada@...>
 

Hi,

 

I think that moving the VPP renderer outside of GBP will be just adding work for us and as you said It will break our concept of universal core that cooperates with renderers for different devices.

We also have some RPC that can be used to create configuration for VPP devices. Any project can benefit from them and even they can be extended in the future.

I have one question too. Currently GBP uses VBD to manage bridgedomains across VPP nodes. It also uses VBD to store yang models that we need to communicate with HC. Do you want the models to be moved to VPP project too. Otherwise it can create problems and conflicts between models in VBD and other projects that maintain their own copy of the same models. And as Vlado suggested we will need to maintain GBP, VBD and also the new VPP project which complicates things for us.

 

Michal

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, June 22, 2017 3:22 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: netvirt-dev@...; project-proposals@...; sfc-dev@...; groupbasedpolicy-dev@...
Subject: Re: [groupbasedpolicy-dev] [Project-proposals] A new project proposal vpp

 

Forwarded to the official thread:

----------------------------------------

 

Hello Yi Yang, Brady, Sam,

 

I went through your project proposal for new Vpp project and I want to ask you several questions. If I understand it correctly, you want to use current GBP Vpp renderer/classifier code into your new project. We spent several months of work on in so I don’t like the idea to move it away, but the main reason is that it would somehow break the main GBP concept. Current GBP implementation consists of two parts; the GBP core which creates a generic configuration from any northbound data provided and several renderers  (including vpp) which “renders” the configuration to end devices. So my first question would be, what the Vpp project should actually do?

 

From your proposal, it’s not clear how you are intending to configure a vpp device. Are you going to use netconf + honeycomb?  Because that’s the same approach GBP is currently using. Then what about models? I guess GBP would need to share models which are not a part of standard api (generic configuration, etc.) or even create a new ones. It would be just another dependency for the GBP because we are using netconf in other renderers anyway.

 

You have written that this new project will benefit all projects with vpp support. Unfortunately I have to ask you what are the benefits for GBP because I can’t see any. To cut the vpp renderer out and preserve compatibility within GBP + with an external vpp renderer is not an easy task and it’d definitely delay the development. Who will maintain the new project? The current GPB development it primary on vpp renderer, so with Honeycomb/VBD (controller app for bridge domains) it would be three projects to work with.

 

So as a GBP PTL I really can’t support this proposal in current form. I don’t think there is something that can be achieved in proposed Vpp project and not in GBP and I think there are no benefits for us. However you are more than welcome to create your own fork from GBP and change whatever you like if it would be good enough for you, but pull the code out of GBP does not make sense to me.

 

I also want to ask Michal Cmarada and Tomas Cechvala, the most active committers to vpp renderer, for their opinion. Guys if you have different point of view or have something to add, please do so.

 

With best regards,

Vlado

 

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Ed Warnicke
Sent: Thursday, June 22, 2017 3:07 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: netvirt-dev@...; project-proposals@...; sfc-dev@...; groupbasedpolicy-dev@...
Subject: Re: [groupbasedpolicy-dev] [Project-proposals] A new project proposal vpp

 

Looping in GBP, SFC, and netvirt, as they are all mentioned in the proposal.

 

Ed

 

On Tue, Jun 20, 2017 at 4:37 AM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, I read vbd source code, what it does isn’t so much. But honeycomb isn’t ODL project, it isn’t in ODL integration release, as Abhijt said, vbd seems not to have active development activity, so I don’t think it is a good way to new a subproject under honeycomb/.

 

I know some ideas in vbd are good, we can borrow some code in vbd to implement similar things in this newly-proposed  project. Again, the goal is to avoid unnecessary duplicate effort, maybe you has different thoughts if you consider it from sfc view angle.

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 20, 2017 5:24 AM
To: Yang, Yi Y <
yi.y.yang@...>
Cc:
project-proposals@...


Subject: Re: [Project-proposals] A new project proposal vpp

 

Yi,

 

One thought that occurs to me is that VBD is actually honeycomb/vbd.  We may want to consider doing something under the honeycomb/* tree at ODL, especially since we are really talking about mounting and managing Honeycomb Agents.  Those agents can certainly manage VPP, but they could also manage other things as well.  

 

In the case of honeycomb/vdb the naming was around virtual bridge domain (VBD)... basically naming it after the global cross node model being translated to the particular per-node models being mounted by netconf.  It might be useful to start thinking in that direction.  What is the global cross node model we are wanting to map to the models provided by Honeycomb?

 

Ed

 

On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ed, no problem, can you propose a better name?

 

From: project-proposals-bounces@... [mailto:project-proposals-bounces@...] On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:34 AM
To:
project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp

 

With my fd.io TSC chair hat on, I would like to formally request that this project *not* be named 'vpp' due to potential for confusion with the fd.io vpp project.

 

Ed

 

>On 16/06/17 03:56, Yang, Yi Y wrote:

>> Hi, TSC members

>> 

>> 

>> 

>> I’d like to propose a new project vpp

>> avoid duplicate efforts for GBP, NetVirt and SFC vpp integration as well

>> as  fix multiple applications coexistence for VPP, I send this out per

>> in order that we can incubate it as a formal project in Nitrogen release

>> cycle or Oxygen, please schedule review process in next TSC meeting,

>> thank you in advance.

> I would suggest a different name, as it can end up being very confusing

> to talk about components when multiple projects have the same name...

> Regards,

> Robert

 

 

 

201 - 220 of 829