|
Yang, Yi Y <yi.y.yang@...>
|
|
|
On 16/06/17 03:56, Yang, Yi Y wrote: 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 well
as fix multiple applications coexistence for VPP, I send this out per
https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Schedule
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
|
|
|
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.
|
|
|
Lori Jakab
On Fri, Jun 16, 2017 at 2:04 PM, Sam Hague <shague@...> wrote:
|
|
|
Edward Warnicke
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
|
|
|
Edward Warnicke
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
|
|
|
Yang, Yi Y <yi.y.yang@...>
Ed, no problem, can you propose a better name?
toggle quoted message
Show quoted text
From: project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:34 AM
To: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
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
toggle quoted message
Show quoted text
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.
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?
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
Edward Warnicke
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@lists.opendaylight.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.
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?
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
Edward Warnicke
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 mounting and managing Honeycomb Agents. Those agents can certainly manage VPP, but they could also manage other things as well.
In the case of honeycomb/vdb the naming was around virtual bridge domain (VBD)... basically naming it after the global cross node model being translated to the particular per-node models being mounted by netconf. It might be useful to start thinking in that direction. What is the global cross node model we are wanting to map to the models provided by Honeycomb?
Ed
On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Ed, no problem, can you propose a better name?
From: project-proposals-bounces@lists.opendaylight.org [mailto:project-proposals-bounces@...]
On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:34 AM
To: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
On 19/06/17 03:41, Yang, Yi Y 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.
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 to netconf-topology there would be zero setup required ... Regards, Robert
|
|
|
Yang, Yi Y <yi.y.yang@...>
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.
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.
Both vpp renderer and vpp classifier can use some common utils, VPP common APIs means those common utils.
Ed, you’re a technical guy, those sfc source code I pointed out in last email can tell you what they’re doing.
toggle quoted message
Show quoted text
From: Ed Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 20, 2017 5:21 AM
To: Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
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?
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@... [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.
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?
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
Yang, Yi Y <yi.y.yang@...>
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, so I don’t think it is a good way to new a subproject under honeycomb/.
I know some ideas in vbd are good, we can borrow some code in vbd to implement similar things in this newly-proposed project. Again, the goal is to avoid unnecessary
duplicate effort, maybe you has different thoughts if you consider it from sfc view angle.
toggle quoted message
Show quoted text
From: Ed Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 20, 2017 5:24 AM
To: Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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 mounting and managing Honeycomb Agents. Those
agents can certainly manage VPP, but they could also manage other things as well.
In the case of honeycomb/vdb the naming was around virtual bridge domain (VBD)... basically naming it after the global cross node model being translated to the particular per-node models being mounted by netconf. It might be useful to
start thinking in that direction. What is the global cross node model we are wanting to map to the models provided by Honeycomb?
On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Ed, no problem, can you propose a better name?
From:
project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:34 AM
To:
project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
Edward Warnicke
|
|
|
Edward Warnicke
Looping in GBP, SFC, and netvirt, as they are all mentioned in the proposal.
Ed
On Tue, Jun 20, 2017 at 4:37 AM, Yang, Yi Y <yi.y.yang@...> wrote:
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, so I don’t think it is a good way to new a subproject under honeycomb/.
I know some ideas in vbd are good, we can borrow some code in vbd to implement similar things in this newly-proposed project. Again, the goal is to avoid unnecessary
duplicate effort, maybe you has different thoughts if you consider it from sfc view angle.
From: Ed Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 20, 2017 5:24 AM
To: Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp
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 mounting and managing Honeycomb Agents. Those
agents can certainly manage VPP, but they could also manage other things as well.
In the case of honeycomb/vdb the naming was around virtual bridge domain (VBD)... basically naming it after the global cross node model being translated to the particular per-node models being mounted by netconf. It might be useful to
start thinking in that direction. What is the global cross node model we are wanting to map to the models provided by Honeycomb?
On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:
Ed, no problem, can you propose a better name?
From:
project-proposals-bounces@lists.opendaylight.org [mailto:project-proposals-bounces@...]
On Behalf Of Ed Warnicke
Sent: Saturday, June 17, 2017 1:34 AM
To:
project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp
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.
>On 16/06/17 03:56, Yang, Yi Y wrote:
>> 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,
> 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...
|
|
|
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 models). 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). Regards, Robert
|
|
|
Yang, Yi Y <yi.y.yang@...>
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, I'll work out a PoC to show you what it looks like.
we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.
toggle quoted message
Show quoted text
-----Original Message----- From: Robert Varga [mailto:nite@...] Sent: Thursday, June 22, 2017 11:52 PM To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...> Cc: project-proposals@... Subject: Re: [Project-proposals] A new project proposal vpp 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 models). 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). Regards, Robert
|
|
|
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 could be shared and (b) we could reuse some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.
Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.
I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:
Cheers, --Colin
On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote: 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, I'll work out a PoC to show you what it looks like.
we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier, SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.
-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@lists.opendaylight.org
Subject: Re: [Project-proposals] A new project proposal vpp
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 models).
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).
Regards,
Robert
|
|
|
Yang, Yi Y <yi.y.yang@...>
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 schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?
toggle quoted message
Show quoted text
From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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 could be shared and (b) we could reuse
some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.
Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.
I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:
On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:
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, I'll work out a PoC to show you what it looks like.
we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier,
SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.
-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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 models).
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).
Regards,
Robert
|
|
|
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 it needs to be sooner. Changing the TSC schedule is... more complicated.
--Colin
On Thu, Jun 29, 2017 at 8:35 PM Yang, Yi Y < yi.y.yang@...> wrote:
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 schedule next meeting to Beijing Time 7:00 AM or 10:00 PM in order that I can join?
From: Colin Dixon [mailto:colin@...]
Sent: Thursday, June 29, 2017 10:35 PM
To: Yang, Yi Y <yi.y.yang@...>
Cc: Robert Varga <nite@...>; Ed Warnicke <hagbard@...>; project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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 could be shared and (b) we could reuse
some of the work that GBP has done. However, the tone of this thread makes it pretty clear that (i) GBP isn't really interested in the shared code and (ii) is pretty opposed to the idea of their code being used as the base even if it's a separate copy.
Give that, it seems like the right path forward is for SFC and NetVirt to decide if they still want to have a shared code bas for how they interact with VPP and if that should be a new project.
I'll let that discussion keep going here and tentative schedule a creation review for next week—July 6th:
On Thu, Jun 22, 2017 at 8:02 PM, Yang, Yi Y <yi.y.yang@...> wrote:
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, I'll work out a PoC to show you what it looks like.
we hope GBP guys can agree this, if you check Srikanthi's PoC and RPCs GBP vpp renderer provided, you can assume the vpp data store is just to save those parameters for those RPCs, for classifier, NetVirt defined its own classifier, GBP defined its own classifier,
SFC defined its own classifier, we hope they can have common classifier then augment it by itself, all the projects should use IETF ACLs and IETF interfaces, if so, the vpp data store can share these data in ODL.
-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Thursday, June 22, 2017 11:52 PM
To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...>
Cc: project-proposals@...
Subject: Re: [Project-proposals] A new project proposal vpp
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 models).
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).
Regards,
Robert
|
|
|
