Re: A new project proposal vpp
|
Yang, Yi Y <yi.y.yang@...>
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 NETCONF.
Please refer to sfc source code, that is more pervasive than written statements.
sfc/sfc-util/sfc-vpp-utils/src/main/java/org/opendaylight/sfc/util/vpp/SfcVppUtils.java sfc/sfc-renderers/sfc-vpp-renderer/src/main/java/org/opendaylight/sfc/sfc_vpp_renderer/ sfc/sfc-classifiers/sfc-scf-vpp/src/main/java/org/opendaylight/sfc/scfvpprenderer
From: project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:43 AM To: project-proposals@... Subject: Re: [Project-proposals] A new project proposal vpp
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:
|
|
|