|
Re: A new project proposal vpp
Yang, Yi Y <yi.y.yang@...>
toggle quoted message
Show quoted text
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?
|
|
|
Re: A new project proposal vpp
Yang, Yi Y <yi.y.yang@...>
toggle quoted message
Show quoted text
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?
On Mon, Jul 10, 2017 at 6:00 PM, Ed Warnicke <hagbard@...> wrote:
Yi,
honeycomb/vbd is named that way :)
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:
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' ?
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.
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:
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
|
|
|
Re: 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
|
|
|
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:
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' ?
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.
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:
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
|
|
|
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
toggle quoted message
Show quoted text
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:
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' ?
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.
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:
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
|
|
|
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' ?
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.
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:
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
|
|
|
Re: A new project proposal vpp
Yang, Yi Y <yi.y.yang@...>
Ed, can you propose a better name for it? How about vppplugin?
toggle quoted message
Show quoted text
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' ?
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.
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:
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
|
|
|
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.
toggle quoted message
Show quoted text
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.
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:
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
|
|
|
Re: A new project proposal vpp
Edward Warnicke
Has the proposed project name and repo been changed to something other than 'vpp' ?
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:
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
|
|
|
Re: 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:
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
|
|
|
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?
toggle quoted message
Show quoted text
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:
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
|
|
|
Re: 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
|
|
|
Re: 答复: Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
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 |
原始邮件
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
|
|
|
Re: 答复: Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
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 |
原始邮件
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 |
原始邮件
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
|
|
|
Re: 答复: Re: Re: 答复: Re: 答复: Re: 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 |
原始邮件
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
|
|
|
Re: 答复: Re: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
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 |
原始邮件
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 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 |
|
|
|
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.
toggle quoted message
Show quoted text
-----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
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)
- Meeting URL: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/423359597
- Access Information
- Meeting number: 423 359 597
- Meeting password: This meeting does not require a password.
- Audio Connection
We'll also take notes and maybe questions on IRC as stated on the TSC page.
See you then, --Colin 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 |
|
|
|
Re: 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: [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
toggle quoted message
Show quoted text
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.
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?
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
