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

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

The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here: https://wiki.opendaylight.org/view/TSC:Main#Meeting_Schedule_and_Logistics Specifically: APAC Meeting

Inline... 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

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,

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

Hello, this is assuming normal NETCONF operations (ODL-initiated session). How will call-home/zero-touch (RFC8071) change this flow? I would assume that aside from a limited amount of changes

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

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

Yi, OK, so the VPP Node Manager is just a set of convenience methods to handle netconf register, connect, and mount in a single go then? This still leaves my questions: 2) Which models will the

Ed, vpp node needs to be registered first, once it is registered, we need to connect it by netconf connector, then we need to get mount point, that is the cornerstone we can operate vpp node by

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

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

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

Maybe vpp-plugin, like openflowplugin? I remember there was some discussion with Ben Pfaff about using simply ovsdb for the project name back in the day. -Lori

Within ODL or do you mean across the industry? vpp is similar to ovsdb so I like that vpp is very clear in what it does.

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

Hi, TSC members I’d like to propose a new project vpp https://wiki.opendaylight.org/view/Project_Proposals:Vpp, our goal is to avoid duplicate efforts for GBP, NetVirt and SFC vpp integration as

Yes, I think the time is very suitable for me. Thanks. 原始邮件 发件人： <colin@...>; 收件人：丁瑞10106591; 抄送人： <project-proposals@...>;宦林英10042773; 日 期

Thank you. --Colin