|
Re: [OpenDaylight TSC] 答复: Re: New project proposal - telemetry
huan.linying@...
Hello folks, I think we prefer to do the creation review of Telemetry project with email. Could we start it right now, and schedule the voting 2 weeks later? 原始邮件 发件人：宦林英10042773 收件人： <ecelgp@...>; 抄送人： <tsc@...>; <project-proposals@...>; 日 期 ：2017年11月09日 13:46 主 题 ：[OpenDaylight TSC] 答复: Re: New project proposal - telemetry Yes, actually we hope GRPC could be a common library of ODL. It could be used as north-bound channel as well. 发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; 日 期 ：2017年11月09日 11:33 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?
发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; 日 期 ：2017年11月09日 11:14 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models. BR/Luis
|
|
|
|
Re: [OpenDaylight TSC] Start the creationreviewfor GNT
Vivek Srivastava V <vivek.v.srivastava@...>
Hi Sam, All,
I have checked GNT details again, and found that actually there is no overlap with GENIUS. It appears that the focus of GNT is mainly on monitoring and analytics, and it does not intend to perform any southbound rendering/data-plane programming for application services (NetVirt/SCF), which GENIUS does. GNT team can confirm this. With this understanding, from my side it would be a ‘go’ for GNT.
Regards, Vivek From: Sam Hague [mailto:shague@...]
Including Daya and Vivek S on this thread. I believe there were some questions regarding overlap with the Genius project. It would be good to wait until they confirm that.
On Wed, Nov 15, 2017 at 3:07 AM,
段凯元 <duankaiyuan@...> wrote:
Hi, everyone
Can we move forward to start a vote for the GNT project if no more question?
Thanks and BR, Kaiyuan
----邮件原文----
Hi, An Ho and everyone
I think we can move forward if no more discussion about the GNT project.
----邮件原文---- As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.
Best Regards, An Ho
From: Xingjun Chu
Thanks An.
To GNT team, I just quickly read through the GNT proposal. A few comments . If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology. But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also be extended if ODL users have other logical network models. “, Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree. Thanks “
From: An Ho
+Adding FAAS Mailing List
It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.
Best Regards, An Ho
From:
tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Sam Hague
Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.
Also would GNT use the TTP project or something similar?
On Sun, Sep 17, 2017 at 9:25 PM, 段凯元 <duankaiyuan@...> wrote: Hi, everyone
What is the result of your vote for the proposal and what's the next step?
Thanks, Kaiyuan
|
|
|
|
Re: [OpenDaylight TSC] Start the creationreviewfor GNT
Sam Hague
Including Daya and Vivek S on this thread. I believe there were some questions regarding overlap with the Genius project. It would be good to wait until they confirm that.
On Wed, Nov 15, 2017 at 3:07 AM, 段凯元 <duankaiyuan@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Start the creationreviewfor GNT
Kaiyuan Duan
Hi, everyone Can we move forward to start a vote for the GNT project if no more question? Thanks and BR, Kaiyuan
----邮件原文----
|
|
|
|
Re: 答复: Re: [OpenDaylight TSC] New project proposal - telemetry
huan.linying@...
Yes, actually we hope GRPC could be a common library of ODL. It could be used as north-bound channel as well. 原始邮件 发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; 日 期 ：2017年11月09日 11:33 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?
发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; 日 期 ：2017年11月09日 11:14 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models. BR/Luis
|
|
|
|
Re: [OpenDaylight TSC] New project proposal - telemetry
Luis Gomez
So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?
|
|
|
|
Re: 答复: Re: [OpenDaylight TSC] New project proposal - telemetry
huan.linying@...
We plan to take netconf protocol as configuration channel, GRPC just for data plane. 原始邮件 发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; 日 期 ：2017年11月09日 11:14 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models. BR/Luis
|
|
|
|
Re: [OpenDaylight TSC] New project proposal - telemetry
Luis Gomez
Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models. BR/Luis
|
|
|
|
Re: [OpenDaylight TSC] New project proposal - telemetry
huan.linying@...
Hi Michael, Thanks for your infomation about infrautils.metrics. which is a very helpful util. In my opinion, telemetry does not overlap with metrics. Metrics focus on how java code works, it gives an "inner sight" of java code, sucn as how many times the api has been called, how many time a func costs. It will be very helpful in sw performance optimization work. Telemetry has a much wider scope, You can report any data with any program language, for example cpu usage, memory useage, NIC statistics. User just need to define a data model. An example is you can even report a sepecific packet forwarding delay with P4 language. If the device could report metric data, I think it is good to have metrics as a channel of telemetry. As we know, the carriers are looking forward a new channel to collect system state from different kinds of devices, to support their new requirements, such as AI management. And we believe telemetry will be a good choice. Thanks. 原始邮件 发件人： <vorburger@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>; <tsc@...>; <afredette@...>; <vivek.v.srivastava@...>; 日 期 ：2017年11月08日 21:09 主 题 ：Re: [OpenDaylight TSC] New project proposal - telemetry Hello Huan Linying, On Mon, Nov 6, 2017 at 9:07 AM, <huan.linying@...> wrote: several people have pointed out to me that I should let you know about upcoming https://jira.opendaylight.org/browse/INFRAUTILS-19. This post is a pure FYI. I have no opinion pro or con your project proposal - best of luck! (Perhaps your Telemetry project, if it gets accepted, wants to later build on top of infrautils.metrics - that's up to you. FYI infrautils.metrics will stay very simple and low-level.) Tx, M. --
|
|
|
|
Re: [OpenDaylight TSC] Start the creationreview for GNT
Kaiyuan Duan
Hi, An Ho and everyone I think we can move forward if no more discussion about the GNT project.
----邮件原文----
|
|
|
|
Re: [OpenDaylight TSC] New project proposal - telemetry
Michael Vorburger <vorburger@...>
Hello Huan Linying, On Mon, Nov 6, 2017 at 9:07 AM, <huan.linying@...> wrote: several people have pointed out to me that I should let you know about upcoming https://jira.opendaylight.org/browse/INFRAUTILS-19. Tx, M. --
|
|
|
|
New project proposal - telemetry
huan.linying@...
Hi folks, I'd like to propose telemetry, a new device run-time information channel, as a new project of OpenDaylight. The proposal link is: https://wiki.opendaylight.org/view/Project_Proposals:Telemetry Please review the proposal and Look forward your feedback. Thanks.
|
|
|
|
Re: [OpenDaylight TSC] Start the creation review for GNT
an.ho@huawei.com
As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.
Best Regards, An Ho
From: Xingjun Chu
Thanks An.
To GNT team, I just quickly read through the GNT proposal. A few comments . If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology. But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also be extended if ODL users have other logical network models. “, Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree. Thanks “
From: An Ho
+Adding FAAS Mailing List
It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.
Best Regards, An Ho
From:
tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Sam Hague
Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.
Also would GNT use the TTP project or something similar?
On Sun, Sep 17, 2017 at 9:25 PM, 段凯元 <duankaiyuan@...>
wrote:
Hi, everyone
What is the result of your vote for the proposal and what's the next step?
Thanks, Kaiyuan
|
|
|
|
Re: [OpenDaylight TSC] Start the creationreview for GNT
xingjun chu
Hi Hongwei,
That’s awesome. Based on your explanation I think we are not conflicting each other, but also complementary. I am looking forward to cooperating between FaaS and GNT more on the future.
Thanks! Xingjun
From: yanghongwei [mailto:yanghongwei@...]
Xingjun，你好！
前段时间我们在ODL立一个项目：GNT，针对你提出的是否和FssS重复的疑问，我们做了下面分析，最终认为GNT和FssS是不同的，如有任何疑问，可邮件或电话联系，谢谢。
对比了FaaS和GNT的各自实现，差异总结： 1、GNT只关注整网拓扑，FaaS不只关注拓扑，还提供统一的北向配置接口； 2、GNT利用已有网络元素显示网络拓扑，包括overlay网络和underlay网络，并同步跟踪两种网络拓扑的变化，FaaS的拓扑中的网络单元是自定义的；
具体实现如下： FaaS： 目的： 因为没有对物理网络的抽象，像GBP、NIC这种以应用为中心的项目配置物理网络非常困难，造成应用程序的南向配置接口绑定，结构单一、容易出错、难以维护；
实现方案： FaaS将物理网络抽象为一个fabric，每个fabric提供公共网络服务，包括L2 / L3连接、QoS以及ACL控件，并向北向提供统一抽象接口，GBP这些应用程序直接配置fabric，不是直接配置物理网络，减少以应用为中心的应用（如GPB）和物理网络的耦合。
具体实现： FaaS定义了下面基本抽象网络模型以及对它们的北向操作（抽象的北向接口）
· * logical switch · * gateway · * logical router · * Tunnel between logical switch and logical router · * ACL
利用这些模型可以将物理网络抽象成一个或多个fabric网络模型，例如： 上面物理网络抽象成下面逻辑拓扑：
注：FaaS目前只支持GBP作为北向接口以及OVSDB / OPENFLOW / Openvswitch作为南向接口
GNT 目的： 针对有软件OVS、硬件交换机、第三方设备等多种南向设备混合部署场景，当南向资源有增加或删除变化时，业务应用要对每一类物理网络资源的拓扑变化分别监听和维护，逻辑复杂，占用过多资源。
实现方案： 提供南向设备统一网络拓扑，包括overlay网络拓扑和underlay网络拓扑，业务应用只需要监听GNT内容，就能得到南向设备的增删改查操作动态以及网络拓扑变化，applications只需要关注业务逻辑本身，不需要监听每类南向资源的变化，优化了数据监听流程。
具体实现： GNT定义新的yang模型，对多个不同类型的南向资源模型进行抽象，通过监听南向资源的配置数据展现网络整体的拓扑视图，跟踪拓扑变化。
注：GNT仅提供南向设备网络拓扑信息，applications如需对南向设备配置，仍需要直接对接各个设备的北向接口，GNT不像FaaS将拓扑进行抽象提供统一的北向配置接口。
杨红伟 中国移动通信研究院/China Mobile Research Institute Email: yanghongwei@... Tel: +86 15801642577 +86 15801696688-35027
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES@Cisco) <vrpolak@...>
The feature could be marked as a stable API [3].If triemap was in infrautils, could the feature itself be stableThe karaf feature could be marked as stable, But for being marked as Stable (with capital S) [2], (among other things) Infrautils would need to be Mature (as opposed to Incubation) project. Vratko. [2] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Stable_and_Extended_Features [3] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#APIs -----Original Message----- From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Robert Varga Sent: 21 September, 2017 16:22 To: Sam Hague <shague@...> Cc: tsc@...; project-proposals@... Subject: Re: [OpenDaylight TSC] A new project proposal: TrieMap On 21/09/17 15:21, Sam Hague wrote: The karaf feature could be marked as stable, but it would still have to branch and version bump with the rest of the project -- exactly the as it has to in yangtools. Avoiding that churn is at this moment key driver behind the proposal. https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#ScopeI am not convinced that actually was necessary. Examining current autorelease, the only beneficiary was daexim using the ready service. All other users already depend on genius, where most of the utilities existed -- hence there those utilities could have stayed in genius. https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project, answers 2 (and 3) give a good summary why Utils classes are not a good thing in the long term. Having that at project level is very much the same thing. This has been raised during discussions leading to infrautils proposal and creation review, at this point everything that looks like a semi-reusable piece of code is now considered to be in scope of infrautils. That actually brings about the question of what our governance is... which actually was reviewed and approved by the TSC. I do not believe such a thing happened with infrautils, or have I missed something? Regards, Robert
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Sam Hague
On Thu, Sep 21, 2017 at 10:22 AM, Robert Varga <nite@...> wrote: On 21/09/17 15:21, Sam Hague wrote: No, this has not been done. I was suggesting that if we did want to rescope then we have an example and don't need to create a process.
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Robert Varga
On 21/09/17 15:21, Sam Hague wrote:
The karaf feature could be marked as stable, but it would still have to branch and version bump with the rest of the project -- exactly the as it has to in yangtools. Avoiding that churn is at this moment key driver behind the proposal. https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#ScopeI am not convinced that actually was necessary. Examining current autorelease, the only beneficiary was daexim using the ready service. All other users already depend on genius, where most of the utilities existed -- hence there those utilities could have stayed in genius. https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project, answers 2 (and 3) give a good summary why Utils classes are not a good thing in the long term. Having that at project level is very much the same thing. This has been raised during discussions leading to infrautils proposal and creation review, at this point everything that looks like a semi-reusable piece of code is now considered to be in scope of infrautils. That actually brings about the question of what our governance is... which actually was reviewed and approved by the TSC. I do not believe such a thing happened with infrautils, or have I missed something? Regards, Robert
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Sam Hague
On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...> wrote: On 21/09/17 09:17, Anil Vishnoi wrote: If triemap was in infrautils, could the feature itself be stable independently of the other utils in the module?
Sadly, the original scope was too limited. It should have had a wider scope to cover what we really wanted - which is a place to put useful utilities that other projects can consume without the need to create a new project.
We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it was just a mini project proposal.
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Robert Varga
On 21/09/17 09:17, Anil Vishnoi wrote:
At a high level this is the same issue that we came across with lldpWe do have a precedent, where we split off a much smaller chunk of code into a separate project -- tcpmd5 -- and there was essentially zero overhead and no complications in doing that. Given that this code lived in yangtools till now and fairly stable code,Controller does use it too, and I suspect there are other places which could benefit from it. it seems reasonable to me to either keep it in yangtools orAs I mentioned, infrautils simply does not cut it, it is nowhere near in terms of stability. I am not sure what version bumping effort you are referring to -- the project will not participate in autorelease and given its API/ABI stability, downstreams can easily use ranged dependency, completely eliminating the need for version bumping procedures known from SR. I personally would like to move it to infrautils project, that wayhttps://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope does not cover it, and if that really is the current scope, infrautils is already greatly exceeding its scope. That actually brings about the question of what our governance is regarding re-scoping projects -- I do not believe we have the equivalent of IETF recharter process... Regards, Robert
|
|
|
|
Re: [OpenDaylight TSC] A new project proposal: TrieMap
Anil Vishnoi
At a high level this is the same issue that we came across with lldp library code and it end up moving to openflowplugin project. That probably was not ideal solution, but i believe comparing the trade-off of logistics cost of new project vs moving it to most relevant project made sense in that scenario. Given that this code lived in yangtools till now and fairly stable code, also assuming that there is no downstream consumer of this code except yantools, it seems reasonable to me to either keep it in yangtools or move it to infrautils (probably not ideal solution, but seems practical to me ). Given that there are only two pom.xml in this code base, not sure the effort spend in version bumping of this code really makes a strong reason for a new project (until and unless i missed something). I personally would like to move it to infrautils project, that way downstream projects also can leverage this implementation. If that is a possible option and the scope of the project is a problem then i think bringing that to discussion would be useful ( although looking at the scope of infrautils, i didn't find anything that's really blocker here).
On Wed, Sep 20, 2017 at 6:39 AM, Michael Vorburger <vorburger@...> wrote:
--
Thanks Anil
|
|
|
