Date   

Re: Creation Review Request for FPC Agent Project proposal

Phil Robb
 

Hi Lyle, that's great to hear.

Note that the proposal needs to be in existence for 2 weeks to allow public review before you request a Creation Review with the TSC.

To avoid any additional delay, you can send me a tarball of the code you expect to contribute prior to the creation review.  I'll scan & review it for license information to ensure it adheres to our Inbound Code Policy [0].


Best,

Phil.

On Mon, Jan 9, 2017 at 2:52 PM, Bertz, Lyle T [CTO] <Lyle.T.Bertz@...> wrote:

All,

 

We would like to propose a new plugin implementing the IETF FPC Agent described in the following link:

 

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

 

We are in the final reviews of the initial code contribution and hope to upload them later this week.

 

Thank you.

 

Lyle




This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

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




--
Phil Robb
Sr. Director Of Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Creation Review Request for FPC Agent Project proposal

Bertz, Lyle T [CTO] <Lyle.T.Bertz@...>
 

All,

 

We would like to propose a new plugin implementing the IETF FPC Agent described in the following link:

 

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

 

We are in the final reviews of the initial code contribution and hope to upload them later this week.

 

Thank you.

 

Lyle




This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.


Re: Container Orchestration Engine Integration Project Proposal

Colin Dixon
 

So, this was approved, the next question is whether it can join Carbon. I'm honestly not sure if that makes sense, but for it to make any sense at all, some kind of release plan with integration points and acknowledgment from those projects would seem like a minimum.

--Colin


On Thu, Jan 5, 2017 at 5:38 PM, Colin Dixon <colin@...> wrote:
Just a reminder to all that this will be presented today.

--Colin


On Thu, Dec 15, 2016 at 5:39 PM, Colin Dixon <colin@...> wrote:
Sounds good. I'll schedule it.

--Colin


On Wed, Dec 14, 2016 at 6:47 PM, Prem sankar G <prem.sankar.g@...> wrote:

Hello,

  We would like to submit a new project proposal for Container Orchestration Engine Integration.  Project proposal page - https://wiki.opendaylight.org/view/Project_Proposals:COE_integration

  This would be an Offset-2 project.  We are ready to present to the TSC for review on Jan 5th (after 2 weeks for public comments).  Also, if needed we can provide technical overview in one of the TWS calls.

Thanks,

Prem

 


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





Re: Container Orchestration Engine Integration Project Proposal

Colin Dixon
 

Just a reminder to all that this will be presented today.

--Colin


On Thu, Dec 15, 2016 at 5:39 PM, Colin Dixon <colin@...> wrote:
Sounds good. I'll schedule it.

--Colin


On Wed, Dec 14, 2016 at 6:47 PM, Prem sankar G <prem.sankar.g@...> wrote:

Hello,

  We would like to submit a new project proposal for Container Orchestration Engine Integration.  Project proposal page - https://wiki.opendaylight.org/view/Project_Proposals:COE_integration

  This would be an Offset-2 project.  We are ready to present to the TSC for review on Jan 5th (after 2 weeks for public comments).  Also, if needed we can provide technical overview in one of the TWS calls.

Thanks,

Prem

 


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




Re: Container Orchestration Engine Integration Project Proposal

Colin Dixon
 

Sounds good. I'll schedule it.

--Colin


On Wed, Dec 14, 2016 at 6:47 PM, Prem sankar G <prem.sankar.g@...> wrote:

Hello,

  We would like to submit a new project proposal for Container Orchestration Engine Integration.  Project proposal page - https://wiki.opendaylight.org/view/Project_Proposals:COE_integration

  This would be an Offset-2 project.  We are ready to present to the TSC for review on Jan 5th (after 2 weeks for public comments).  Also, if needed we can provide technical overview in one of the TWS calls.

Thanks,

Prem

 


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



Container Orchestration Engine Integration Project Proposal

Prem sankar G <prem.sankar.g@...>
 

Hello,

  We would like to submit a new project proposal for Container Orchestration Engine Integration.  Project proposal page - https://wiki.opendaylight.org/view/Project_Proposals:COE_integration

  This would be an Offset-2 project.  We are ready to present to the TSC for review on Jan 5th (after 2 weeks for public comments).  Also, if needed we can provide technical overview in one of the TWS calls.

Thanks,

Prem

 


Re: Cluster Metrics project proposal

Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
 

We are thinking the same.

 

Our goal is to publish it, gather some feedback, make the apps better and then, if needed, split it to other projects.

 

dano

 

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 11. novembra 2016 15:39
To: Colin Dixon; Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco)
Cc: Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco); project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz)
Subject: RE: [Project-proposals] Cluster Metrics project proposal

 

System Metrics project consists of two components:

the backend (Stats Reflector) and the frontend (GUI).

The two components communicate using a protocol (Restconf RPCs),

 

When the project is young, I think it makes sense

to keep both parts in the same repo.

It makes it easier to alter the protocol (Yang modules).

 

Only when the protocol is finalized, it makes sense

to move the components to umbrella projects for maintenance.

GUI will obviously fit right into dluxapps project,

There would be several options for Stats Reflector home:

TSDR, Infrautils, Integration/Distribution, Controller.

 

Vratko.

 

From: project-proposals-bounces@... [mailto:project-proposals-bounces@...] On Behalf Of Colin Dixon
Sent: 10 November, 2016 20:11
To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...>
Cc: Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco) <sjamrich@...>; project-proposals@...; Jan Medved (jmedved) <jmedved@...>; Chris Metz (chmetz) <chmetz@...>
Subject: Re: [Project-proposals] Cluster Metrics project proposal

 

For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right.

My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions.

If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps.

Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should.

Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller.

Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.

 

--Colin

 

On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


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

 


Re: Cluster Metrics project proposal

Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES@Cisco) <vrpolak@...>
 

System Metrics project consists of two components:

the backend (Stats Reflector) and the frontend (GUI).

The two components communicate using a protocol (Restconf RPCs),

 

When the project is young, I think it makes sense

to keep both parts in the same repo.

It makes it easier to alter the protocol (Yang modules).

 

Only when the protocol is finalized, it makes sense

to move the components to umbrella projects for maintenance.

GUI will obviously fit right into dluxapps project,

There would be several options for Stats Reflector home:

TSDR, Infrautils, Integration/Distribution, Controller.

 

Vratko.

 

From: project-proposals-bounces@... [mailto:project-proposals-bounces@...] On Behalf Of Colin Dixon
Sent: 10 November, 2016 20:11
To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...>
Cc: Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco) <sjamrich@...>; project-proposals@...; Jan Medved (jmedved) <jmedved@...>; Chris Metz (chmetz) <chmetz@...>
Subject: Re: [Project-proposals] Cluster Metrics project proposal

 

For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right.

My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions.

If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps.

Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should.

Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller.

Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.

 

--Colin

 

On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


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

 


Re: Cluster Metrics project proposal

Colin Dixon
 

For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right.

My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions.

If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps.

Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should.

Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller.

Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.

--Colin


On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


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



Re: Cluster Metrics project proposal

Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
 

No problem, we’ll be there.

Thanks

 

dano

 

From: Colin Dixon [mailto:colin@...]
Sent: 27. októbra 2016 16:51
To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco)
Cc: project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz); Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco)
Subject: Re: [Project-proposals] Cluster Metrics project proposal

 

The 2-week public comment period is pretty much set in stone, sadly. However allowing the project to join the Carbon release is something the TSC has more authority to address and I don't think it will be an issue. Would you be able to do a review on 11/10?

--Colin

 

On Wed, Oct 26, 2016 at 12:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


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

 


Re: Cluster Metrics project proposal

Colin Dixon
 

The 2-week public comment period is pretty much set in stone, sadly. However allowing the project to join the Carbon release is something the TSC has more authority to address and I don't think it will be an issue. Would you be able to do a review on 11/10?

--Colin


On Wed, Oct 26, 2016 at 12:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


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



Re: Cluster Metrics project proposal

Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
 

HI Alexis,

 

This project is mainly about UI, but I think, we can make APIs consumable to everybody, why not?

 

dano

 

 

 

From: Alexis de Talhouët [mailto:adetalhouet@...]
Sent: 26. októbra 2016 23:01
To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco)
Cc: project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz); Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco)
Subject: Re: [Project-proposals] Cluster Metrics project proposal

 

This is reminding me what we have started in controller project with this patch: https://git.opendaylight.org/gerrit/#/c/36751/ adding CLI to gather info/stats about data broker and cluster, reading beans.

Wondering if this project is mostly about a DLUX app, or you intend to create APIs that will be consumable by the world. Also, wondering whether controller/md-sal projects should provide such APIs, or if those APIs should be provided in a separated project.

 

Anyway, the UI is appealing.

 

Thanks for putting this up Daniel, can’t wait for the TSC review, where we will certainly discuss some of the wonders I’m having :)

 

Alexis

On Oct 26, 2016, at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

 

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 

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

 


Re: Cluster Metrics project proposal

Alexis de Talhouët <adetalhouet@...>
 

This is reminding me what we have started in controller project with this patch: https://git.opendaylight.org/gerrit/#/c/36751/ adding CLI to gather info/stats about data broker and cluster, reading beans.
Wondering if this project is mostly about a DLUX app, or you intend to create APIs that will be consumable by the world. Also, wondering whether controller/md-sal projects should provide such APIs, or if those APIs should be provided in a separated project.

Anyway, the UI is appealing.

Thanks for putting this up Daniel, can’t wait for the TSC review, where we will certainly discuss some of the wonders I’m having :)

Alexis

On Oct 26, 2016, at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:

Hi,
 
We would like to submit proposal for new project called Cluster Metrics.
 
 
If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.
 
We are planning this project to be Offset 2.
 
Thank You
 
Daniel Malachovsky
 
_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals


Cluster Metrics project proposal

Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
 

Hi,

 

We would like to submit proposal for new project called Cluster Metrics.

 

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

 

If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.

 

We are planning this project to be Offset 2.

 

Thank You

 

Daniel Malachovsky

 


Re: BIER Plugin project proposal for Carbon

Colin Dixon
 

Based on the proposal coming in today, it would be eligible for review in two weeks at the November 3rd TSC meeting. That's normally at 10a pacific. If that time works for you great. Otherwise, if it's a poor time, we can either see if we can schedule a special TSC meeting at a more friendly time or do the creation review over e-mail.

--Colin


On Tue, Oct 18, 2016 at 7:46 AM, 宦林英 <huan.linying@...> wrote:

Hi,

I'd like to request a commit for a new project proposal.the proposal link is:

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


regards,



宦林英 Huan Linying


南京协议开发三部/有线研究院/有线产品经营部 Nanjing Protocol Development Dept. III/Wireline Product Operation Division



南京市雨花台区紫荆花路68号 

Nanjing city Yuhuatai District Bauhinia Flower Road No.68

M: +86 13182845505
E: huan.linying@...
www.zte.com.cn
</div

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



Re: BIER Plugin project proposal for Carbon

宦林英 <huan.linying@...>
 

Hi Robert,

Glad you've reviewed the proposal:)

- would you mind the project to be called just 'bier'? It makes package
names and namespace allocations (org.opendaylight.bier) much more friendly.

A: I think it's OK. The doc could be edit later.

- the proposal mentions ingesting BGP data, would that mean the plugin
would integrate with current ODL BGP implementation and extend it with
https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions/ and
https://datatracker.ietf.org/doc/draft-chenvgovindan-bier-bgp-ls-bier-ext/?

A: When I mentioned ingesting BGP data, it means the BGP protocol running on devices, and controller fetch information with other SB protocol.We've considered BGP as SB protocl,but at current stage our choice will be netconf. 

- this is not mentioned in the proposal, but there seems to be PCEP
integration provided via
https://datatracker.ietf.org/doc/draft-chen-bier-pce-bier/ -- is that
something that would be in (future) scope of this project?

A: Yes, PECP will definitely be the coming feature of BIER project,we already have a plan for it. But this feature will not be implemented in Carbon. Actually,I think the BIER project will be evolved for a long time.The proposal is kind of hard to cover everything gonna happen. Our team will focus on IETF progress and keep the project move on.


宦林英 Huan Linying


南京协议开发三部/有线研究院/有线产品经营部 Nanjing Protocol Development Dept. III/Wireline Product Operation Division



南京市雨花台区紫荆花路68号 

Nanjing city Yuhuatai District Bauhinia Flower Road No.68

M: +86 13182845505
E: huan.linying@...
www.zte.com.cn
原始邮件
发件人:RobertVarga
收件人:宦林英10042773;<project-proposals@...>
抄送人:彭少富10053815;<fubr@...><dongzhp_bjy@...>王森枭10200860;顾敏00046059;喻敬海10005643;张征00007940;熊泉00091065;陈明羚10207659;鲁春怀00041716;
日 期 :2016年10月18日 23:55
主 题 :Re: [Project-proposals] BIER Plugin project proposal for Carbon


On 10/18/2016 01:46 PM, 宦林英  wrote:
> Hi,
> 
> I'd like to request a commit for a new project proposal.the proposal
> link is:
> 
> https://wiki.opendaylight.org/view/Project_Proposals:BIER_Plugin

Hello,

Nice proposal :) Couple of quick questions:

- would you mind the project to be called just 'bier'? It makes package
names and namespace allocations (org.opendaylight.bier) much more friendly.

- the proposal mentions ingesting BGP data, would that mean the plugin
would integrate with current ODL BGP implementation and extend it with
https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions/ and
https://datatracker.ietf.org/doc/draft-chenvgovindan-bier-bgp-ls-bier-ext/?

- this is not mentioned in the proposal, but there seems to be PCEP
integration provided via
https://datatracker.ietf.org/doc/draft-chen-bier-pce-bier/ -- is that
something that would be in (future) scope of this project?

Thanks,
Robert




Re: BIER Plugin project proposal for Carbon

Robert Varga
 

On 10/18/2016 01:46 PM, 宦林英 wrote:
Hi,

I'd like to request a commit for a new project proposal.the proposal
link is:

https://wiki.opendaylight.org/view/Project_Proposals:BIER_Plugin
Hello,

Nice proposal :) Couple of quick questions:

- would you mind the project to be called just 'bier'? It makes package
names and namespace allocations (org.opendaylight.bier) much more friendly.

- the proposal mentions ingesting BGP data, would that mean the plugin
would integrate with current ODL BGP implementation and extend it with
https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions/ and
https://datatracker.ietf.org/doc/draft-chenvgovindan-bier-bgp-ls-bier-ext/?

- this is not mentioned in the proposal, but there seems to be PCEP
integration provided via
https://datatracker.ietf.org/doc/draft-chen-bier-pce-bier/ -- is that
something that would be in (future) scope of this project?

Thanks,
Robert


BIER Plugin project proposal for Carbon

宦林英 <huan.linying@...>
 

Hi,

I'd like to request a commit for a new project proposal.the proposal link is:

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


regards,



宦林英 Huan Linying


南京协议开发三部/有线研究院/有线产品经营部 Nanjing Protocol Development Dept. III/Wireline Product Operation Division



南京市雨花台区紫荆花路68号 

Nanjing city Yuhuatai District Bauhinia Flower Road No.68

M: +86 13182845505
E: huan.linying@...
www.zte.com.cn


Re: Federation Service project proposal for Carbon

Colin Dixon
 

Sounds good. Thanks!

--Colin


On Thu, Oct 13, 2016 at 4:26 PM, Kaempfer, Gideon <gidi@...> wrote:

Hi Colin,
The 27th will work. If my schedule allows it on the 20th I will let you know and if possible would probably prefer that date then.
Thank you and best regards,
  Gidi




On Thu, Oct 13, 2016 at 6:35 PM +0200, "Colin Dixon" <colin@...> wrote:

Thanks for letting us know. Would the 27th work better and solve the scheduling difficulties?

--Colin


On Thu, Oct 13, 2016 at 11:08 AM, Kaempfer, Gideon <gidi@...> wrote:

Hi Colin,
It's the holiday season over here in Israel. Thus the sluggish response...
Due to travel my schedule is not firm yet for the 20th which I may not be able to make. I will send you an update as soon as I know for sure.
Unfortunately I will also be unable to attend today's (10/13) TSC meeting.
Thank you and best regards,
  Gidi




On Wed, Oct 12, 2016 at 5:28 PM +0200, "Colin Dixon" <colin@...> wrote:

Cool! Should we schedule the creation review for the 10/20 meeting of the TSC?

--Colin


On Wed, Oct 5, 2016 at 8:02 AM, Kaempfer, Gideon <gidi@...> wrote:

Hi,

I would like to submit the above project proposal as described in the link below for consideration for the Carbon release.

 

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

 

Best regards,

  Gidi

 

Gideon Kaempfer

Senior Architect

ConteXtream, CSB, HPE

gidi@...

 


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





Re: Federation Service project proposal for Carbon

Kaempfer, Gideon <gidi@...>
 

Hi Colin,
The 27th will work. If my schedule allows it on the 20th I will let you know and if possible would probably prefer that date then.
Thank you and best regards,
  Gidi




On Thu, Oct 13, 2016 at 6:35 PM +0200, "Colin Dixon" <colin@...> wrote:

Thanks for letting us know. Would the 27th work better and solve the scheduling difficulties?

--Colin


On Thu, Oct 13, 2016 at 11:08 AM, Kaempfer, Gideon <gidi@...> wrote:

Hi Colin,
It's the holiday season over here in Israel. Thus the sluggish response...
Due to travel my schedule is not firm yet for the 20th which I may not be able to make. I will send you an update as soon as I know for sure.
Unfortunately I will also be unable to attend today's (10/13) TSC meeting.
Thank you and best regards,
  Gidi




On Wed, Oct 12, 2016 at 5:28 PM +0200, "Colin Dixon" <colin@...> wrote:

Cool! Should we schedule the creation review for the 10/20 meeting of the TSC?

--Colin


On Wed, Oct 5, 2016 at 8:02 AM, Kaempfer, Gideon <gidi@...> wrote:

Hi,

I would like to submit the above project proposal as described in the link below for consideration for the Carbon release.

 

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

 

Best regards,

  Gidi

 

Gideon Kaempfer

Senior Architect

ConteXtream, CSB, HPE

gidi@...

 


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



261 - 280 of 829