1. Messages
  2. A new project proposal vpp

Re: A new project proposal vpp

Edward Warnicke
 

Inline...

On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...> wrote:

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 on ODL side is different from information model on VPP node side, especially for sfc, vpp renderer will also render RSP to bridge domain, vxlan-gpe, NSH entry and NSH map in every vpp node RSP spans. sfc vpp renderer is much more complicated than NetVirt needs, so we can use the existing code in sfc vpp renderer to achieve a vpp renderer NetVirt needs very easily.

 

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 rendering is the models mounted via netconf.  What precisely are the *from* models?  Are we writing new models in this project for bridge domains, vxlan, vxlan-gpe, etc.  It also sounds like you are taking a small fragment of the SFC model and creating a new model for a bunch of virtual bridging concepts (similar to what is done in VBD).  Are there existing models being rendered to the netconf mounted models?

 

For vpp classifier, it needs to renderer IETF ACLs and sfc classifier model to vpp classify tables, vpp classifier in sfc also handles vxlan-gpe in ingress classifier and the first SFF.


I thought we already had such a renderer in SFC... I could see it being useful elsewhere, but are there places other than SFC using the IETF ACL model currently?
 

 

Both vpp renderer and vpp classifier can use some common utils, VPP common APIs means those common utils.


Could you give an example?
 

 

Ed, you’re a technical guy, those sfc source code I pointed out in last email can tell you what they’re doing.\


I have gone and looked at the code you referenced above.  It renders the SFC model to the models mounted via netconf yang.  I still don't understand what is to be gained by moving it more distant from the SFC project, where it serves a purpose.
 

 

From: Ed Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 20, 2017 5:21 AM
To: Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...ylight.org


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

 

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 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 Sun, Jun 18, 2017 at 6:41 PM, Yang, Yi Y <yi.y.yang@...> wrote:

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@lists.opendaylight.org [mailto:project-proposals-bounces@...] On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:43 AM
To: project-proposals@...ylight.org
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:

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.