Re: A new project proposal vpp


Edward Warnicke
 

An observation:

We don't need a new protocol plugin for vpp.  Via the Honeycomb agent at fd.io, vpp is accessible via netconf, and so we get direct yang models via netconf.  So its not like Openflowplugin or OVS plugin.

And some questions:
1)  What will the VPP Node Manager be doing that the netconf plugin doesn't do in terms of managing the vpp nodes?  Why wouldn't it make more sense to close any gaps in the netconf plugin?
2)  Which models will the vpp renderer be rendering *from* and *to*?
3)  What does the VPP classifier do?
4)  What kinds of things do we expect in the VPP common APIs?

Ed

On Fri, Jun 16, 2017 at 10:34 AM, Ed Warnicke <hagbard@...> wrote:
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


Join project-proposals@lists.opendaylight.org to automatically receive all group messages.