Date   

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:

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:

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

>> 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

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?

 

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.

 

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

 

 



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:


APAC Meeting (Held every 4th Thursday)


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:

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
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <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:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@...>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@...>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


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:
On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong


熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review
Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin

On Tue, Jun 6, 2017 at 10:19 PM,  xiong.quan@... wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn

_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals


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

 

 

 



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:

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

>> 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

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:

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:

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

 

 

 


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, 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


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
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <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:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting..


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


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:
Cheers,
--Colin

On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong






熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte..com.cn
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...aylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...rg>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review


Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin


On Tue, Jun 6, 2017 at 10:19 PM,  xiong.quan@... wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

https://wiki.opendaylight..org/view/Project_Proposals:BIER_APP

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn

_______________________________________________
project-proposals mailing list
project-proposals@...ylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals











Re: A new project proposal vpp

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.

 

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

 



Re: A new project proposal vpp

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.

 

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

 

 



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:

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

 

 


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

>> 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

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



Re: A new project proposal vpp

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


Re: A new project proposal vpp

Lori Jakab
 

On Fri, Jun 16, 2017 at 2:04 PM, Sam Hague <shague@...> wrote:


On Jun 16, 2017 6:54 AM, "Robert Varga" <nite@...> wrote:
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...
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.

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
 

Regards,
Robert


_______________________________________________
project-proposals mailing list
project-proposals@...ylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals



_______________________________________________
project-proposals mailing list
project-proposals@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Re: A new project proposal vpp

Sam Hague
 



On Jun 16, 2017 6:54 AM, "Robert Varga" <nite@...> wrote:
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...
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.

Regards,
Robert


_______________________________________________
project-proposals mailing list
project-proposals@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Re: A new project proposal vpp

Robert Varga
 

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


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:

On Thu, Jun 8, 2017 at 9:20 PM,  <ding.rui@...> wrote:

Thank you for your reply, we have discussed the release schedule of this project, considering the deadline of  Nitrogen release,

 we decide to participate in the Oxygen release, but we want the project to be formally approved by the TSC as soon as possible. 




原始邮件
发件人:colin@...>;
收件人:丁瑞10106591;
日 期 :2017年06月08日 22:18
主 题 :Re: [Project-proposals] P4Plugin Proposal


Thank you for the proposal. Is the intent for this to participate in the (short) Nitrogen release ending on 9/7/2017. See:
If so, this is going to be a pretty whirlwind tour of getting a release done. API freeze including support for Karaf 4 will be no later than 7/14 and code freeze will be no later than 8/14.

The alternative is to participate in the Oxygen release, which will target a 3/7/2018 release.

--Colin
 

On Sun, Jun 4, 2017 at 9:01 PM,  ding.rui@... wrote:

Hi, everyone,

    I creat a new project proposal which is about P4 technology. Please review it. Thanks.

https://wiki.opendaylight.org/view/Project_Proposals:P4_Plugin



_______________________________________________
project-proposals mailing list
project-proposals@...ylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals








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:


Hi Colin,


 Thank you for the schedule arrangement. The meeting time is good for us.

 I will finish and upload the presentation slides as soon as possible before the meeting.


Best Regards,

Xiong



熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人: <colin@...>;
收件人:熊泉00091065;
抄送人: <project-proposals@lists.opendaylight.org>; <an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383; <bier-dev@....org>;
日 期 :2017年06月09日 23:53
主 题 :Re: 答复: Re: [Project-proposals] BIER_APP project requests for creation review


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:

Cheers,
--Colin

On Thu, Jun 8, 2017 at 9:29 PM,  <xiong.quan@...> wrote:

Hi Colin,


  Thank you for the reply!

  The details are as follows.


) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.


Xiong RE: BIER_APP project still plans to participate in Nitrogen and there is no problem with the plan time, cause we have finished the work partly and I believe we can catch up with the shedule. 


2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.


Xiong RE: We still want to separate the BIER plugin and applications and do our best to guarantee the independence between the two projects.


Best Regards,

Xiong






熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn
原始邮件
发件人:colin@...>;
收件人:熊泉00091065;
抄送人:project-proposals@...aylight.org>;an.ho@...>;宦林英10042773;喻敬海10005643;高陈强10202383;bier-dev@...rg>;
日 期 :2017年06月08日 22:23
主 题 :Re: [Project-proposals] BIER_APP project requests for creation review


Thanks for the request. Two quick questions:
1.) Do you actually want to participate in Nitrogen, it will be a very fast release with API freeze (including support for Karaf 4) being 7/14 at the latest and code freeze being 8/14 at the latest? Alternately, you could wait and participate in Oxygen which is targeting at 3/7/2018 release.

2.) Does this actually need to be a a new project or does it make sense to have it as a part of the bier project. In general, I applaud the idea that the pure plugin and the applications that use that plugin should be kept separate, but we've found that often this results in tightly-linked changes between the two and it's easier (at least at first) to keep them separate. That being said, if you feel strongly about having two projects, we can have a creation review.

Cheers,
--Colin


On Tue, Jun 6, 2017 at 10:19 PM,  xiong.quan@... wrote:


Hi An Ho,


BIER_APP project requests for creation review and plans to participate in Nitrogen release.

Project proposal have been provided as follows and I have added the wiki link in the New Pending Creation Review list.

https://wiki.opendaylight.org/view/Project_Proposals:BIER_APP

Please reply to me about the review meeitng shedule and what I should prepare.


Best Regards,

Xiong

   




熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation



武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: xiong.quan@...
www.zte.com.cn

_______________________________________________
project-proposals mailing list
project-proposals@...ylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals








221 - 240 of 829