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

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

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

Yi, honeycomb/vbd is named that way :) Ed

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

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

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

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

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

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

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

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

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

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

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

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

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,

Following up from the TSC call, which has notes here: https://meetings.opendaylight.org/opendaylight-meeting/2017/tsc/opendaylight-meeting-tsc.2017-06-22-03.30.html There are two items. That we'd love

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

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