|
Re: [groupbasedpolicy-dev] A new project proposal vpp
Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES@Cisco) <vlavor@...>
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 questions. If I understand it correctly, you want to use current GBP Vpp renderer/classifier code into your new project. We spent several months of work on in so I don’t like the idea to move it away, but the main reason is that it would somehow break the main GBP concept. Current GBP implementation consists of two parts; the GBP core which creates a generic configuration from any northbound data provided and several renderers (including vpp) which “renders” the configuration to end devices. So my first question would be, what the Vpp project should actually do?
From your proposal, it’s not clear how you are intending to configure a vpp device. Are you going to use netconf + honeycomb? Because that’s the same approach GBP is currently using. Then what about models? I guess GBP would need to share models which are not a part of standard api (generic configuration, etc.) or even create a new ones. It would be just another dependency for the GBP because we are using netconf in other renderers anyway.
You have written that this new project will benefit all projects with vpp support. Unfortunately I have to ask you what are the benefits for GBP because I can’t see any. To cut the vpp renderer out and preserve compatibility within GBP + with an external vpp renderer is not an easy task and it’d definitely delay the development. Who will maintain the new project? The current GPB development it primary on vpp renderer, so with Honeycomb/VBD (controller app for bridge domains) it would be three projects to work with.
So as a GBP PTL I really can’t support this proposal in current form. I don’t think there is something that can be achieved in proposed Vpp project and not in GBP and I think there are no benefits for us. However you are more than welcome to create your own fork from GBP and change whatever you like if it would be good enough for you, but pull the code out of GBP does not make sense to me.
I also want to ask Michal Cmarada and Tomas Cechvala, the most active committers to vpp renderer, for their opinion. Guys if you have different point of view or have something to add, please do so.
With best regards, Vlado
From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...]
On Behalf Of Ed Warnicke
Sent: Thursday, June 22, 2017 3:07 PM To: Yang, Yi Y <yi.y.yang@...> Cc: netvirt-dev@...; project-proposals@...; sfc-dev@...; groupbasedpolicy-dev@... Subject: Re: [groupbasedpolicy-dev] [Project-proposals] A new project proposal vpp
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:
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
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:
|
|||||||||
|
|
|||||||||
|
Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
Colin Dixon
The meeting should be at 0330 UTC on Thursday this week and we should use the Zoom info here: Specifically:
We'll also take notes and maybe questions on IRC as stated on the TSC page. See you then, --Colin On Mon, Jun 19, 2017 at 10:37 PM <xiong.quan@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
Inline... On Tue, Jun 20, 2017 at 4:25 AM, Yang, Yi Y <yi.y.yang@...> wrote:
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 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?
Could you give an example?
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.
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
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.
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?
Ed
On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
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.
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?
:)
Ed
On Sun, Jun 18, 2017 at 6:41 PM, Yang, Yi Y <yi.y.yang@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
Robert Varga
On 19/06/17 03:41, Yang, Yi Y wrote:
Ed, vpp node needs to be registered first, once it is registered, weHello, 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 |
|||||||||
|
|
|||||||||
|
Re: 答复: Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
xiong.quan@...
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 the meeting on zoom with the number 423 359 597. Best Regards, Xiong 熊泉 xiongquan 软件工程师 Software Engineer
原始邮件 发件人： <colin@...>; 收件人：熊泉00091065; 抄送人： <project-proposals@...>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...>; 日 期 ：2017年06月13日 22:39 主 题 ：Re: 答复: Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review Thank you. --Colin On Sun, Jun 11, 2017 at 9:44 PM, <xiong.quan@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: 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? Ed On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <yi.y.yang@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: 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:
|
|||||||||
|
|
|||||||||
|
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:
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
Yang, Yi Y <yi.y.yang@...>
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.
Ed
>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 >> 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
|
|||||||||
|
|
|||||||||
|
Re: 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:
|
|||||||||
|
|
|||||||||
|
Re: 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. Ed >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 >> 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 |
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
On Fri, Jun 16, 2017 at 2:04 PM, Sam Hague <shague@...> wrote:
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
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
Sam Hague
On Jun 16, 2017 6:54 AM, "Robert Varga" <nite@...> wrote:
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.
|
|||||||||
|
|
|||||||||
|
Re: A new project proposal vpp
Robert Varga
On 16/06/17 03:56, Yang, Yi Y wrote:
Hi, TSC membersI 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 |
|||||||||
|
|
|||||||||
|
A new project proposal vpp
Yang, Yi Y <yi.y.yang@...>
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. |
|||||||||
|
|
|||||||||
|
Re: 答复: Re: Re: P4Plugin Proposal
ding.rui@...
Yes, I think the time is very suitable for me. Thanks. 原始邮件 发件人： <colin@...>; 收件人：丁瑞10106591; 抄送人： <project-proposals@...>;宦林英10042773; 日 期 ：2017年06月09日 23:44 主 题 ：Re: Re: [Project-proposals] P4Plugin Proposal Understood. The next regularly scheduled TSC meeting after the two-week public review period is 6/22, which is actually the Asia-friendly TSC call time too, which is probably good. Does that time work for you? It would be this: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=6&day=22&hour=3&min=30&sec=0&p1=771&p2=33&p3=248&p4=283&p5=263&p6=37 You can read through some advice on creation reviews here: --Colin On Thu, Jun 8, 2017 at 9:20 PM, <ding.rui@...> wrote:
|
|||||||||
|
|
|||||||||
|
Re: 答复: Re: 答复: Re: BIER_APP project requests for creation review
Colin Dixon
Thank you. --Colin On Sun, Jun 11, 2017 at 9:44 PM, <xiong.quan@...> wrote:
|
|||||||||
|
|
