Re: A new project proposal vpp

Robert Varga

On 20/06/17 15:39, Ed Warnicke wrote:
On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...
<mailto: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?
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 input models (SFC, netvirt, GBP) being rendered
onto a target device (which happens to be VPP, but it's really about

What would be the models for "VPP data store"? Is this a mirror of the
SB device's model and are we talking about the proposed project
performing the equivalent of FRM?

I am sorry, but it is extremely hard to distill scope from the proposal
in its current form. I think it needs to be beefed up with details of
interactions and needs to be vetted by all of GBP, SFC and NetVirt to
make sure the proposal actually fits the use case.

Furthermore it would be very beneficial to understand how this plays
with netconf topology -- as I mentioned "VPP node" is in reality any SB
device implementing a specific set of models (either directly or through
an adaptor).


Join { to automatically receive all group messages.