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

Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES@Cisco) <vlavor@...>

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,




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 <

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




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
Subject: Re: [Project-proposals] A new project proposal vpp


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




>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




Join to automatically receive all group messages.